Incremental program change foot switch for ns2EX et al.

[KeyFrog2]

I was looking for a comfortable (= hands-free) solution to change the programs on my nord stage2EX. If I use different programs during one song, I usually put all the required programs on one page in the sequence of occurrence and then would like to “scroll” through the programs by a foot switch.

As I couldn’t find a device satisfying my needs, I decided to make one on my own. I decided to use the Arduino IDE, as I wanted to have a stand-alone device w/o any laptop or computer needed to run. As this is my very first Arduino project at all (and one of my first C-style programming works), I’m happy to learn, if some of you matured programmers and experts see ways to improve the software or hardware. But at the end, my solution does its job robustly (at least by now ).
For all who don't know the Arduino world: it turned out to be a fascinating and easy way to start with micro controllers. Try it, it's an open source project and the hardware isn't very expensive.

I also included a bank change functionality and a main volume control into the device. Main volume control allows to control the volume of the ns2EX completely (like the "MASTER LEVEL" turning knob on the left of the ns2EX-panel), not only those instruments, that are assigned to an expression / control pedal explicitly. This can be helpful if you need to level your volume during playing at a live perfomance with other musicians.

Sending PC-commands to the ns2EX-MIDI-IN and listening to ns2EX-program changes via the ns2EX-MIDI-OUT occupies both MIDI sockets on the ns2EX. To have their functionality still available I also included a MIDI THRU socket and a MIDI MERGE socket to my device. MIDI THRU (this is hardware only) sends a copy of the ns2EX-MIDI-OUT to any other external MIDI device. MIDI MERGE allows wiring to the MIDI-OUT of any other external MIDI device, these MIDI commands will be merged with any MIDI-commands created by the bank / program or volume control of my device and then sent (via the MIDI OUT) to the ns2EX. So full MIDI connectivity is still available.

Please find the relevant information in the attached files.

As said before, this is my first arduino project, so if you find bugs, please let me know. I'll try to solve them.

NOTE: I tested this on my ns2EX only. It should (!) also work on many other keyboards using (=sending and receiving) MIDI Progam change / bank change commands, e.g. ns2 and others, but I didn't check that.
Please post your experiences to help other users.

[KeyFrog2]

Sorry, something went wrong when uploading the files:
Here is the souce code (change extension to .ino to load and compile it in Arduino)

[Hobster]

Fascinatng stuff! Nice to see someone else getting down'n'dirty with a hardware/software project!
I'm currently building a project (using an ATmega328/P circuit for production and an Arduino clone for development) that will allow me use the Stage 3 to control my GSi Gemini over MIDI the way I want to.
I tried contacting Nord about their external MIDI control functionality (see post post106403.html) but they never replied.
I also contacted Guido at GSi and although he didn't feel that changing the way the Gemini worked was appropriate, he did suggest I try buiding my own solution - I'm an embedded systems software engineer by profession so this did indeed seem the obvious way to go!

The software and hardware are both working and I've now to decide whether to put it all in an external box (as you have) or bite the bullet and just put the microcontroller and MIDI transmit buffer chip (a 74LS04 Hex Inverter used the same way as you've used your Schmitt-Trigger version) inside my Stage 3 (just before the MIDI output)...!
When it's all up & running, I'll do a similar post to yours with full details in case anyone else is interested.
In the meantime, here's the software if you'd like to see a slightly different approach (I use a tab size of 4 which you can set in the Arduino IDE preferences)

A couple of points about your hardware...
I'd be tempted to put a 10K resistor from 5V to pin 1 of the ATmega chip just to make sure it's tied High (and so the chip doesn't accidentally reset).
Also I'd tie the four unused inputs on the Hex Inverter chip (74LS14) to 0V; best not to leave them 'floating'.
In fact, I'm surprised you haven't used a further two of the remaining inverters to buffer the MIDI out as well; it's recommended in the MIDI hardware spec though I'm aware you can usually get away without the buffer if, as is the case with the ATMega outputs, they don't mind sourcing a small amount of current.

[weremole]

Thats pretty cool

[KeyFrog2]

@ Hobster
Many thanks for your valuable hints!
I wasn't aware that MIDI spec recommends buffering the out by inverters. And it is so easy to include in my circuit as they are already available
And to tie down open ends is always a good idea. Floating free ends aren't a good idea at all ... By the way, what about the free pins of the ATMega328P: did you ever make bad experince leaving them unconnected?
I included your proposals to my circuit diagram and the board layout and uploaded both as review 1 (R01).
Maybe you wanna check if this is what you suggested.
I'll change my hardware accordingly and test.

[Hobster]

You can leave the Port pins of the ATmega unconnected without any problem as long as you enable any unused Port pins as inputs with the internal pull-up resistors enabled.
That way they're not floating and are effectively 'tied' to the 5V rail.
If you look at my code, you'll see that I do that in my design with the 'DDRx &= ~XXX' (sets bits to 0) and 'PORTx |= XXX' (sets bits to 1) instructions at the start of 'setup()'.
There are other ways to do it, but using 'bit-masks' and the above two types of instructions is far and away the most efficient.
Each C instruction generates only 3 assembler/machine code instructions!
No need to modify any hardware for the ATmega Port pins stuff; all done in software.

Had a look at your new schematic - looks pretty spot on to me for the new additions (I'm assuming all the MIDI in/thru hardware is fine as I'm not familiar with the Optocoupler you're using).
The 1Meg resistor across the 16MHz crystal isn't really necessary but certainly shouldn't do any harm.
And if you include any other IC's at any point in the future, popping a 100nF cap as close as possible across pins 7 & 8 of the Atmega (digital 5V & 0V) and a same size cap, for each extra IC, across their supply inputs helps with decoupling (keeping the power supply smooth by supplying bits of current when the IC's 'do their thang').
You could still pop one in anyway. It does smooth the 5V rail a tiny bit more (you'll see the difference with a 'scope) but it won't make any real difference to the overall operation of your circuit

One thing though: I'm not sure about how you've connected the filter network (cap & inductor) around the analog supply pins...
In the ATmega datasheet that I have (2018 version), it recommends connecting the inductor across the digital 5V (VCC pin 7) and the analog 5V (AVCC pin 20) with a cap across AVCC and GND - not the AREF (pin 21) as you have done...
This is done to REALLY smooth the analog 5V supply and make it as flat as possible for any analog conversions that are needed.
You'd then leave the AREF pin unconnected and use analogReference(DEFAULT) in the software as you have done.
As your circuit stands, you're suppling unfiltered 5V to the AVCC and the connections to AREF are irrelevant as you're using the main 5V as a reference by using DEFAULT.
i.e. it will still work, but not quite in the way I believe you intended...
AREF is only connected if you're using an external reference (and then you use EXTERNAL in the call to analogReference() in the software).
To be honest though, most circuits (which use the ADC) that I've encountered don't even bother with the filter and just run AVCC off the main 5V rail as the ATmega ADC isn't exactly the highest precision...!
Having said all that, I've not used analog inputs in my project, so you might want to verify elsewhere what I've just outlined...

[KeyFrog2]

OK, I updated the source code to reflect Hobster's proposals regarding the unconnected pins on the ATMega328: They are now set up with the internal pullup resistors, so it should be even more robust against "electrical dirt".

Additionally I made a minor change to the behaviour of the volume pedal: when switchingon both devices, the ns2 and the foot controller, the foot controller will be ready first. Changing the volume to something less than 127 (toe down) while ns2 is still booting will not be reflected in the ns2EX. After booting the ns2 is usually at volume 127, so if you then touch the poedal which is far below will give you a suprising step of volume. As I hate surprises during live performance I coded such that:
- Volume pedal is inactive until foot controller received first valid bank change / program change from ns2EX (same as up / down switches), so I know that ns2EX is on. Inactive status is indicated by fast flashing Volume-LED
- As ns2EX should be at volume 127 now you have to push down the pedal (toe down) to "pick up" the volume there and get synchronized with the ns2EX volume. Such you won't experience an excessive volume change.
A good sequence to start therefore is:
1. switch both devices on
2. wait until foot controller and ns2EX have booted ready
3. send a program change command from the ns2 by changing the program or bank (MIDI LED should stop flashing fast)
4. push volume pedal fuly toe down (Volume LED should stop flashing fast and will show the volume status)
5. ready to play

@ Hobster: as a newbie I'm not used to this bit-mask type of code, so I used the global constants for the pullup resistor. In the next project I'll try to improve
Regarding details of the circuit: I took information from many sources, e.g. here (incl. the 1M resistor at the oscillator):
https://rheingoldheavy.com/build-an-ard ... ch-part-1/
not sure where I got the ARef-circuit from. To be prepared Ihad set it up but didn't really use it at the end. Using 10bit resolution A/D to feed a 7bit resolution MIDI command probably doesn't need too much accuracy ...

[Hobster]

@KeyFrog2: Yeah, the fact that your project is working fine as it is indicates that you can simply remove that cap/inductor filter completely.
As you said, getting 7 bits from a 10 bit ADC certainly doesn't require a super-smooth 5V AVCC!
Regarding the pull-ups; as I said, there are several ways to get the job done and all are perfectly valid
Bit-handling isn't used very often in general software code nowadays simply because memory is so plentiful (back when I started in the late seventies, every memory bit counted! lol), but stuff like bit-masking is still a really useful tool to have when dealing with setting/resetting individual bits in this sort of microcontroller code where physical pins are memory-mapped to software ports.
Actually, I have to admit that some of the code in my project can look a bit odd to someone reasonably new to programming in C anyway
Anyway, glad my suggestions were of some use

[Hobster]

Oops! Ignore this comment.Somehow my previous one got sent twice and I can't delete it so...!

[KeyFrog2]

@ Hobster
These were very helpful and valuable suggestions, many thanks again!

Regarding the optocouplers: I chose these as I had them here and tested them successfully on my prototype board. As they are not the official recommendation and a little slower than e.g. a 6N138, it might be a good idea to use those instead, when starting a new project. Might be of interest for longer MIDI chains and cables.

Regarding your project: Will you bite the bullet to build in your circuit into the nord stage itself? I guess I’d never be that brave …, but obviously you’re an expert. Respect!

Now I’m gonna clean up my little workshop and soon start my next project: Simple (=cheap) MIDI bass pedals for my nord stage. I’m not willing to pay for the original nord stuff. There is a cheap solution by DOEPFER with one or two FATAR pedal mechanic(s), but it is w/o any dynamics. Let’s see if I can find a way to pimp it in a way that I can play it with different velocities. It should be easy to read the MIDI, impress a new velocity value to it and forward it to the nord, but how will I get a reasonable velocity value? I’ll look if I can generate something within the pedal contacts, mechanics or elsewhere… If not, I could at least install an expression pedal or similar to choose something like a “general velocity”. Otherwise, e.g. piano sounds would be played at 127, which is very hard.

Anyone interested in the outcome? Then I will post it