SysEx MIDI Controller w/ analog multiplexer

I've got an old synthesizer that only accepts SysEx MIDI messages to change it's various tonal parameters, patch switching, modes, etc... I ran across an article by Jeffb42 at where he built a MIDI SysEx volume pedal with an Arduino.

I want to do basically the same thing, except on a much larger scale with anything from 20-30 analog controls and 10 or so switches (on/off).

Where my problem lies is this: I'd like to know the amount of time it would take to read values from all these controls and then send a message to the synth if a change is detected. I basically want to know if I can pull this off and have seemingly "instant / real-time" feedback from my synth.

So, does anyone have any experience with SysEx and can explain the timing limitations as pertaining to an Arduino based controller?


why use analog for everything? you can use rotary encoders instead of pots, would be more flexible anyway and give you absolute control of the values that the sysex commands recieve, which can be up to 3byte 24bit values, 10bit ADC on the arduino itself will kill resolution, as the lowest res on sysex is usually 2bytes, 16bit. how many bits is the ADC on the multiplexer?

You don’t have to spend time reading the encoders as they are inputs, don’t have to read the synth either as you are using +1 or -1 to set the values rather than an analog conversion and hoping the temperature hasn’t drifted too much since the last time you used it (unless thats an analog feel you are looking for?) and could all relatively easily be interrupt driven.

As long as you can save the patch/settings as a snapshot you’ll be laughing :slight_smile:

The midi is running at 32k baud rate, as such its realtime, so there shouldn’t be any issue there at all, it entirely depends how you handle your code. the sending of data might need thinning out a bit so it will be as accurate(realtime) as you need it without flooding the midi data :slight_smile: you’ve only got 2 hands and this is a synth controller but you might want to see how the sysex affects polyphony too.

I’m not knocking analog btw. just giving you options, the analog feel is something that some people desire, its just that the main point of sysex is to give finer resolution and control of all the synths functions, analog pots on the arduino itself are more suited to midi note on/off, CCs and some NRPNs (if used carefully) as they are usually 0-127 values. When you look at midi data its all hex, control bytes for the particular function and data, it all looks like sysex in the end, just a different length for each ‘packet’ :slight_smile:

hope that helps a bit :slight_smile:



Thanks so much for all the great info. The synth I want to control (a Juno 106) only accepts SysEx data to controlle it's filters, LFO, etc. My idea (however flawed it ends up being) was to do the following:

In one iteration of a loop, sample each control (be it potentiometer (analog) or switch (digital)) and if a change from the last value was detected (exceeding a certain threshold), I would build the appropriate SysEx packet for the control using the data that was just sampled as the "data" portion of the packet. The data portion has a range of 0-127 for an fader or just HIGH/LOW for a switch.

The faders would only need a 7-bit resolution (2^7 = 128) to produce the full range of possible "data" to be sent in the SysEx message.

As for the "analog" feel, wouldn't the fact that you are using a digital protocol to send finite resolution data (0-127) be considered non-analog feel??? I don't expect any more analog feel than the SysEx messages are capable of providing. I just want my controls to feel as "real-time" as playing with the faders on the actual synth (if that's possible).

I haven't thought of using rotary encoders (never used them, but familiar with their operation). Aren't they a little pricey? Do they make slide rather than rotary encoders? Also, would't I need at least 7 digital inputs per control to get the 0-127 resolution? How could that work with upwards of 20-30 controls?

Thanks again for your thoughts!

Is the sysex seriously only 7Bit? that's a real shame, I expected 2bytes at least. That's ok then the resolution on the ADC will be enough to cover that as long as you are sure there are no 2byte data values coming through the sysex. That doesn't deal with the possibility of NRPNs (Non-Registered Parameter Numbers) having 2 byte data values too.

As for the analog 'feel', well, its a 'feel' not true analog but you are mixing the 2 and getting the flakiness of analog, the resistance on that pot will change with the temperature, if there is a big enough shift it will change the behaviour of the pots and consequently the sound, remember its only digital after its been converted, so the conversion is only as accurate as the analog signal being read in.

I don't think you can get slider encoders, although you might be able to get digital sliders.

And you would only need 1 rotary encoder per control, not 7 :) all you are doing is sensing for a pulse in a directionl, so it doesn't matter really how many steps per revolution the encoder is as long as its 1 in either direction, if you get a clockwise pulse add 1 to the data value and send the sysex, if you get a counter clockwise pulse then minus 1 from the data value and send the sysex, and repeat as needed. so you are essentially treating it like a pair of buttons that increment or decrement the data value.

I think you are overcomplicating things 'scanning' everything looking for a change, sure, on the analog pots they are always going to have a reading on them and will need looking at, buttons and encoders though can be left to an interrupt, so that instead of scanning the system for changes constantly the system is 'made aware' that a button or encoder has sent a signal and only does something when its made aware.

BTW. looking at this page it would appear that we are both right :)

1 byte for your actual controls and 2 bytes for patch/bank changes. slightly odd that they did that, they could have used NRPNs for it instead, which would have made all of those functions available from a cheap simple midi controller keyboard :) Still, in the wonderful world of midi and synths you find a lot of strange things.

Thanks for clarifying what you meant by the "analog feel" thing. I think right now I just want to come up with something that will work (analog or digital).

I'm not sure how much you know about the Juno 106 (I just got it not too long ago myself), but from the website I referenced, it appears that I'd need 14 digital pins to read on/off switch controls, and 16 "analog" (potentiometer / encoder) controls.

How could I hook all these controls up to trigger interrupts and know which control to change?

I also wanted to implement calling up different preset patches (2 banks of 64 patches a piece). If you pull up a specific patch, all of the controls are logically set to the different settings that make up that patch. There is also a "manual" button that, when pressed, takes the synth to a configuration defined by the positions of all the controls at that time.

From looking at the website, it looks like if I were to call up a specific preset patch from my yet to be designed/built controller, I'd also have to send the data for all the various control positions that make up that patch ?!?! I don't know how I would do this without having some sort of 2-way communication between my controller and the synth so that the controller can "re-learn" what defines a specific preset if I happen to edit it and save it on the synth. I'll have to do some more investigating on how this part of the system would need to be implemented.

Back to encoders: I did a little reading on encoders last night, and I don't quite understand entirely, but wouldn't you need 2 pins per encoder to determine if the encoder changed and in what direction?

Also, on the actual Juno, I can't remember if a pot control parameter "snaps" to the current position when a change is detected, or if it waits until the control is moved up/down to the current setting before it starts to change based upon your manual input. (I hope that made sense). In any event, I'd want my controller to operate in the same manner. I guess this goes along with how I can or can't handle the changing preset issue I talked about 2 paragraphs ago.

Thanks again... this is good stuff!

BTW... do you know any way to determine if/how my original pot-based design could work (timing/delay-wise).

hmmmn, now you're starting to get into a little more than just a controller, the specific presets would be something that you would 'save' on the controller and re-call from eeprom or external memory. It would of course be valid to 'learn' from the synth, but this is where the rotary encoders would be the perfect solution, I'll explain why :)

here's the scenario using pots, you've just been editing a patch using the controller, the pot for volume is set at 127, you save your patch and decide to recall a patch you we're editing earlier, hit a note on your keyboard and its a bit quiet (its set at 64 for instance), so you go to move the volume pot and the first value it sends is 126 which sends your speakers flying across the room :D If you use a rotary encoder it will just increment or decrement by 1. the volume is a bit of an extreme situation, but you can see the jump whatever the setting is to the first value the pot sends out doesn't really gel well, especially in a live performance. this way you can load your patches into the juno and the controller is already 'set' at the correct values without having to read any of the settings information. the only thing you might have to deal with are the button states.

I don't know the juno 106 at all, only what i've seen on the site I linked to, but you could do all of the buttons and encoders on an arduino mega without a multiplexer, you'd also have some pins left over for analog pots if you really wanted them too. but yes, 2 pins for the encoders, they really don't have to be expensive either, I've seen them for £1.50 each for 10 over here so its not too bad :)

it will be a midi (serial) stream that you are recieving, so its just a question of being able to buffer the data into the unit, for that you would need to work out how many bytes it will take for all the data values for each parameter and then provide enough storage on the arduino for the number of patches that you want, looking down the list its about 30-40bytes per patch, + the length of a name for you to recognise the patch. use something like midi-ox/midi-yoke/loop-be virutal midi loopback device to monitor the incoming and outgoing midi data, it will make your job way way easier :)

Well... instead of trying to reinvent the wheel here, I think I've come up with a "solution"... of course I won't know if I can make it work until I actually own and make what I'm about to explain:

I plan to get a Behringer BCR2000 MIDI controller (basically a panel full of encoders and a few buttons). I believe I may be able to use Apple Logic Pro 9 to read the CC data from the BCR2000 and convert it to SysEx using Transformer objects within Logic. Yes, this would require me to be running Logic any time I wanted 'remotely' control the Juno, but I doubt I'd ever need to control it outside of a studio type environment. If (and this is a big IF) I ever did, I believe MIDI Solutions makes a box ($150) called the Event Processor Plus that will read in 32 different MIDI "events" and "translate" them into a MIDI event of your choosing (SysEx Juno 106 commands in my case).

I'm not totally abandoning building a sweet (maybe pointless) piece of gear... I still would need to come up with something to change patches and flip the various switches on the Juno...

To do this I've "designed" an 8x2 button matrix using the SparkFun 2x2 button pads and breakout boards. Using an Arduino Mega, I can connect the 16 buttons to a single interrupt pin as well as their own separate digital input. When the interrupt happens, I'll poll the 16 inputs to see which buttons were pressed, and take the appropriate action (send a SysEx message to the Juno telling it which patch to change to).

While the Arduino waits for an interrupt, the RGB LEDs under the buttons can be doing their thing (I haven't yet figured out what I want their thing to be). I'll at least have them indicate which patch is selected on the Juno (1 button from the top row and 1 button from the bottom row).

I'll also need 13 or so toggle switches above the 8x2 button array that will go to their own inputs and also connect to the 2nd interrupt. They will be polled and dealt with in the same manner as the button presses.

Well, that's it... gonna be a whole lot of wires but, I think the Mega can handle it. I'm currently figuring out how exactly I want to put it together. Right now it's mostly in my head, but I think I have some good ideas... more to come.

Let me know if I've totally screwed something up and/or my design doesn't sound like it would work.