...and that is excellent news, as the good thing in question is the development work for firmware version 2.0, which I am now officially declaring as done and ready! \o/

So after nearly three years of virtually nothing, I am happy to announce that the 4chord MIDI project is finally moving forward, and apart from having implemented every feature that I set as goal a little too long ago, a few additional developments have occurred.

Certified Open Source Hardware

The 4chord MIDI Piano has been officially certified as open source hardware by the Open Source Hardware Association (OSHWA) with certification ID FI000001.

Finland Number One!

Tindie - And This Time I Mean It! Almost...

Still not completely there, but the point of no return turning-around-now-would-be-utterly-idiotic has been definitely reached, as is best shown with a picture:

That's the first batch of pianos almost ready, but as you can see, most of them are still missing their display - and that's where I ran into a bit of a problem that will cause some further delays. Again, a picture tells it probably best, so here's the "good to use" pile on the left vs the "crap, those are all scratched / seem to have taken a bath in seawater" pile on the right:

They do seem to work in general, at least most of them, but the thought of mounting a shoddy display like that on this fine looking piano simply sparks no joy. I've decided I'll be further exploring some options here for the time being. In the end, after close to three years, what's a few more weeks, right?

So Firmware Version 2.0 You Say?

Yep. And looking back at the Firmware roadmap log, I'm actually amazed how close to those initial plans the actual firmware version 2.0 ended up to be. Here's me quoting myself of what I had in mind:

All this being said, the plans for the version 2.0 firmware release are:

• changing quarter note based playback to eighth note playback
• adjust the playback modes to make use of eighth notes, and add some new playback modes
• adding metre choices for 4/4 and 3/4, and possibly more to come later
• displaying the tonic (I), dominant (V), submediant (vi) and subdominant (IV) of the currently selected key
• highlighting currently played chord on button press
• redesigning the UI to include all these new features
• implementing a bootloader to update future firmware releases without any need for programmers or development environments
• adding long button press to the menu keys
• cleanup the V-USB MIDI descriptors

All of that has happened and is implemented now, and the main deviation from the plan are a few additional features and changes:

• a metronome is displayed in arpeggiated playback modes
• basic EEPROM support for storing hardware information and menu presets (key, mode and such), which was initially planned for version 2.1, but here we are
• settings currently selected menu values as default by long-pressing the Select button (this will be later replaced by a settings menu as of firmware version 2.1 plans)
• LCD content is not kept around in memory as there's no real use for it
• XBM and general image handling was improved, supporting now automated arrangements of graphics without any need of manual rotation and flipping to match what the LCD wants, as well as size optimized animations that only update the pixels that actually change

So I guess it's time to make some new introduction video to show around all these shiny new features and how to make use of them. Until then, here's another picture showing the updated UI during playback:

When I put together the firmware roadmap, it became clear to me that having an easy and convenient way to update the board with any future versions will be one of the most important features. With such a feature, I don't have to worry too much about missing features and can go ahead and offer 4chord MIDI to the world. Sure, there's the ISP connector, so updating the firmware has always been possible, but like I wrote in the previous log, I want that everyone can fully enjoy 4chord MIDI, regardless of their programming or electronics background.

Well, today I finalized the first proof of concept implementation of a bootloader that will be able to do just that: updating the firmware.

Thanks to the ATmega328's built-in bootloader support, it was surprisingly easy (almost disappointing) to have separated application and bootloader code. But of course, the main focus was the self programming and transferring the firmware data, so good to not have to worry about the linker along the way.

Like I said, this is a first proof of concept, but it has full support to

• receive new firmware data one memory page at a time - a Python script takes care of that
• write the firmware data chunks to the flash
• read the freshly written data back and send it back to the Python script which is then either moving on to the next memory page or sending the last one again, until the data matches
• displaying some progress information (okay that one needs still some work)

Here's a little video showing the firmware upgrade in action:

Pressing the "Select" menu button while powering up the board will enter the bootloader mode. It has a simple UART interface to reset / handoff to application, but pressing the "I" chord and "IV" chord button at the same time will also reset the board.

Next step is to fully integrate it into the Makefile and push some code to the Github repo.
Coming soon. Development branch for bootloader is now here: https://github.com/sgreg/4chord-midi/tree/feature/bootloader

Every time an idea pops into my mind, I tell myself to finally get a notebook and start collecting them in there, yet every time I end up scribbling them on whatever random piece of paper I find lying around me that doesn't have a shopping list or any other thought on it yet. Well, now I finally made a scrap book of shreds of papers, old envelopes and Post-it notes related to 4chord MIDI, and turned all plans and ideas about the firmware future into Github milestones.

I'll add issues for each individual feature to the Github repository as the milestones progress, but to give everyone else an idea what will come in the near and distant future, I thought this is a good place to tell about them.

If you check the project's history, you'll see that the current state was mainly developed back in 2015, and at this point, moving from a credit card shaped PCB to a piano shaped one is the only real change that happened since. For me, this sounds like a good moment to increase the firmware's major version number and go for a 2.x path for any new feature. Keeping in mind that I want to take this project to @Tindie as soon as possible, yet have a long list of features I'd love to add, it made sense to already plan for different releases to separate need-to-have, want-to-have and nice-to-have features. These features are now planned to be implemented in firmware version 2.0, 2.1 and 2.2 respectively. Obviously that separation was done at my own discretion and may leave some definition a bit blurry.

Version 2.0

The current firmware has on the one hand everything you need - chords and arpeggios in every key at "any" tempo - but is on the other hand too limited to have full-blown fun with it. For instance, the arpeggio playback is limited to quarter notes in 4/4 metre, and you need to know all keys by heart if you're interested to know what the submediant (vi chord) of, say, F# would be. A nice rhythm using eighth notes in either 3/4 or 4/4 (and more later on) metre as a playback mode, displaying the I-V-vi-IV chords for each key and highlighting the one that's currently played, now that's a whole different story. So is the ability to update future firmware versions without the need of any external components or even any knowledge of programming a microcontroller.

I've been looking for a reason to play around with the ATmega's bootloader memory area ever since I learned it existed. And while I should probably focus on other things in this phase, I'd still prefer being able to hand out 4chord MIDI hardware to an average person without any previous background in programming or electronics, so they can enjoy my creation.

All this being said, the plans for the version 2.0 firmware release are:

• changing quarter note based playback to eighth note playback
• adjust the playback modes to make use of eighth notes, and add some new playback modes
• adding metre choices for 4/4 and 3/4, and possibly more to come later
• displaying the tonic (I), dominant (V), submediant (vi) and subdominant (IV) of the currently selected key
• highlighting currently played chord on button press
• redesigning the UI to include all these new features
• implementing a bootloader to update future firmware releases without any need for programmers or development environments
• adding long button press to the menu keys
• cleanup the V-USB MIDI descriptors

Version 2.1

In theory, those 2.0 changes should add a bit more flexibility and comfort, but things are still a bit generic. If I've learned anything in my life, it's that people most certainly have different preferences over very much everything, Being generic will therefore cater equally bad to most, which can be considered fair in a way, but customizing to your own taste is probably the better choice. The next firmware iteration is therefore focusing on user configurable settings.

In the big picture, this means there will be a new text based configuration menu introduced, separated from the main user interface. With long button press implemented in version 2.0, the "Select" button will be utilized to open it. This adds a few implications, such as adding support for text with a generic font, and obviously the menu handling itself. Other than that, adding a way to make the playback feel a bit less robotic by adding some timing variations int he playback is one other topic.

Features in the version 2.1 will therefore include:

• adding a generic font and functionality to display any arbitrary text
• displaying the configuration menu on long press of the "Select" button
• implementing a general configuration menu structure and its handing
• storing the configuration choices on EEPROM and reading back from it
• adding configuration for
  • default key, playback mode, metre and tempo
  • back light brightness
  • name for the keys between A and C (A#/Bb/B and B/H)
  • UART debug interface baud rate
• adding (also configurable) playback variation by deliberate timing variations to add a more human feel to it

Version 2.2

By now, the firmware should be adjustable to make pretty much everyone happy with the amount of configurability of it.
But...

Being able to configure "everything" might make changes from one choice to the other more complex, and is therefore potentially hurting the user experience. So while version 2.1 was adding options for customization, version 2.2 will aim to optimize these customizations by combining them into presets everyone can define for themselves.

Let's say you want to play a song in G# in 4/4 metre with 128 bpm in whatever playback mode that exists by now, and then want to continue with a different song in E at 94 bpm. Even with the same metre and playback mode, there's a lot of button pressing involved. I saw two choices to make this go smoother:

1. limit the selection of available keys/modes/metre/tempo
2. add presets of fixed defined key/mode/metre/tempo combinations

Only one answer seemed appropriate here: yes. Both options will be available.

In addition to this, the plan is to add a whole different way to play the chords in the first place. Instead of playing the selected playback mode while each button is pressed, a second option will be introduced to just trigger the playback on button press. Meaning a single press to the "I" chord button will play the currently selected key's tonic in the currently selected playback mode for as long as any other chord button is pressed. Pressing any other chord button will switch to the next chord - and pressing the same button again will stop the playback. Add a configuration choice to change/stop playback only at the end of the current metre and it's almost too easy to have a background track for recording your real instrument playing.

So here's the summary of new version 2.2 features:

• adding configuration options to select the available keys, playback modes, metre and tempo
• adding the concept of presets and option to the user to create their own presets of key, playback mode, metre and tempo
• adding high level playback mode to choose from:
  • playback mode is executed as long as key is pressed (old)
  • playback mode is executed on key press and either changed to new chord or stopped on next button press (new)

Version 2.x

Yeah.. right. Let me get all this done first..

But yeah. as final note: these are the plans, and naturally, other things will come up along the way. Either new ideas I get, requests other people state, or unavoidable needs for bug fixes. That's just life. Either ones will get their own Github issue and assigned to the milestones accordingly.

So if something comes to your mind that's in your opinion missing from my plans, let me know.

The revised PCBs arrived earlier this week and later the same night, I was holding another fully assembled 4chord MIDI piano prototype in my hand. Moment of truth has come: will this finally be the revision I'm happy enough to share it with the world and start offering to strangers?

Initial situation looked good, I attached an USBasp programmer and checked if avrdude could recognize and communicate with the controller. No smoke, no short circuit, ATmega328p recognized - all good. Flashed the firmware, remembered to burn the fuses to use the external oscillator right away this time, and excitedly watched the syslog output as I plugged in the USB cable for the first time.

New USB device found, idVendor=1209, idProduct=deaf

What beautiful words.

The LCD back light went on and the 4chord MIDI logo appeared on the LCD itself. It was one of those Disney moments you just want to burst into song. So I started up fluidsynth.

Long story short, latest revised Piano shaped 4chord MIDI keyboard PCB seems to work all well and nicely, the toppling problem is solved, and the back light works.

Time for some pictures and show the (admittedly minor) differences between the two PCB iterations.

On the left is the initial version, on the right the revised one. Ignore the buttons on the right, I'm currently on the (seemingly futile) mission to find the perfect tactile switch.

Main change is the fourth rubber foot on the top, slightly lowered silk screen on the buttons and the voltage selector for the UART connector.

The bottom side, has mostly re-arranging some components and re-routing the tracks accordingly and some silk screen related changes, and of course fixing the back light transistor arrangement (which is also a MOSFET now).

Again, left side the initial PCB, right side the revised, latest version.

So, yeah, I'm happy enough with all of it, so this will be the version that is going to be shared on the OSH Park website. The KiCad and Gerber files have been merged to the Github master branch and tagged as release.

Next steps are finalizing my preparations for a first small batch that will eventually make it to Tindie. But as I mentioned, I'm currently on some quest for buttons. Some year ago or so I ended with a random eBay order of tactile switches (the ones used for the chords), which are like no other switch I ever met. They are simply smooth and silent with a nice pressure point and feeling to it (Omron B3S series as it turned out). Would be great to find the same type of switch for the menu buttons - preferably in black (ebony would be perfect since those Omron ones are actually ivory), but so far no luck.

So I'll keep up the quest for a little while longer and little by little set up everything else - including some new firmware features.

Yes.

Finished all items on my TODO list, and threw in some extra changes to - hopefully - end up with a slightly less amateurish PCB design. I'm still working on finding some better buttons than the cheap ones I have lying around for the menu navigation. They simply need a bit too much force and I'm just not happy with their feel. Especially in comparison with the chord buttons that are just so damn smooth. But knowing what to look for now, will make this a smaller issue.

Apart from that, latest changes are in the Github repo in the feature/hardware-revision-b branch (once I get the latest iteration and am happy with it, it will be merged in the master branch), and I just sent the design to OSH Park (which will have the PCB as shared project the same time the feature branch gets merged to master).

Thanks to the folks at http://pid.codes/, 4chord MIDI has now its own unique USB vendor/product ID pair! In practice this means that one could add a udev rule specific to 4chord MIDI, and for example automatically execute a shell script whenever a device gets plugged in, which could then start fluidsynth and automatically connect it via aconnect. Or start jackd and a2jmidid to get Ardour ready for MIDI recording.

Well, I guess those two example udev rules just made it on my TODO list..

Earlier this week, the fully re-designed revision B PCBs have arrived from @oshpark, and they are even more beautiful than I imagined. You simply cannot emulate this shininess in KiCad's 3D Viewer ..or capture it on a picture, but here is one nonetheless:

The main change is obviously the PCB shape. I honestly don't know why I thought a MIDI keyboard had to be credit card sized in the first place, it's not like you'd carry it around in your wallet along with a battery powered computer to actually use it. So I figured, why not give it a more musicy look.

Also there were a few issues I didn't like in my initial design and wanted to change regarding the crystal oscillator (too high frequency for 3.3V supply voltage and a form factor which wasn't that easy to source) and the LCD (also sourcing situation, couldn't fit the back light, and they kinda kept on dying on me). Also the horizontal button arrangement for the chords playback didn't feel very ergonomic or natural.

So with the new boards designed, manufactured, and right in front of me, last night was the time to turn one of them into a functional prototype:

I emphasize prototype here, because I realized a few things along the way:

• There's really no need to have zero Ohm links in the power supply paths, this is a USB powered device. While analyzing and optimizing current consumption is fun and interesting, there simply is no reason to be able to do that in the final design.
• Real pianos may be nicely balanced with three legs, but they don't have a huge USB connector in their upper end either. Pressing the "<" button will topple the board with the current mechanical arrangements, so that will need some adjustments.
• On very first try, the LCD back light didn't turn on, and I haven't had time to look into it yet, so there is a possible issue that needs some re-work. Maybe I should just stop using BJTs and finally get more familiar with FETs.
  • Edit: turns out I used the wrong generic NPN transistor in the schematic, and base and emitter ended up swapped. Removed the SOT-23 transistor, bent some legs on a TO-92 to replace it, and back light turned on just fine.
• Santa is coming early this year and he's so gonna bring some hot air soldering equipment.

So there will be another iteration in the near future taking care of all these things, and once I'm satisfied with the results, the PCB will be available from OSH Park's shared project section, and some assembled ones will make their way to Tindie. And in the mean time, I have a whole list of new feature ideas for the firmware to work on, so I won't get bored.

(Side note on Tindie, if you'd be interested to get a 4chord MIDI keyboard, drop me a message so I could get a rough picture)