second Arduino project! My first was a 13 key organ pedalboard I play at the same time as playing Bass Guitar. learned all sorts of things getting back in to code. I stopped learning Java (any Minecraft fans?) in middle school when gaming addiction took over. But, that unfinished foundation in another language is better than bare earth starting out now!
I am trying to decide between hardware speeds of the Mega and Due boards and the implications of reading differently taxing multiplexers for a DIY MIDI organ setup that is portable(4 keyboards and a pedalboard, toggles for pull-stops, a few analog inputs etc. I understand I could buy both and swap them on a breadboard, but the Arduino is actually the only financial investment in the project so far! I am building my organ from two FREE old electric organs from the 70s and 80s that ive fully gutted. All the wiring(from the newer one) and switches I could need!
There is a five minute video from someone's senior recital where he used what appears to be an UNO with 28 multiplexers(4051, 8 way) titled "converting an old organ to digital" if you wish to seek it, here is a link as well.
He says that the arduino is fast enough for his 2 keyboards
So, my questions are simple as I have spent hours researching
inferences: the Arduino can process 8 way multiplexing faster than 16, the Mega is similar in speed to the Uno used in the video, The Due will(?) have no problem with ~54 8 way multiplexers but will be close to running out of space on the board with some being analog inputs(expression pedals and master faders) and needing separate selector pins.
Can the Mega support this many multiplexers and check their state arrays without the player noticing latency? If so is it also fast enough to cycle through 27 16 way multiplexers for the application of midi? Or would the Due more suited to handle the 4057s? Should I just get the due to be safe whether I use 4051 OR 4057 for this many button states?
Thank You!
EDIT 1: VPO is just a very large midi controller utilizing different channels for the keyboards, so that reaper or hauptwerk or similar DAW can differentiate them. Most of the heavy lifting on interpreting that midi data or coupling manuals is all handled on the computer-side software
12+ analog inputs(8 faders, 3 expression pedals) possibly adding more because my VPO will be able to run software synths on each channel in a typical digital audio workstation like reaper, which have a lot of functions attached to potentiometers.
It appears to me you need some processing speed, take a look at the ESP devices, some have more then one core. A large amount depends on the amount of processing you want to do. You could use shift registers in series /parallel configuration, much easier then calculating mux selection.
I forgot to mention someone on the hauptwerk forums uses a single due for their full setup that is similar in scale to mine with a bigger pedalboard. He doesn't define if he uses shift registers or multiplexers
Hello!! Thank you for your reply! Are you suggesting I use wifi and Bluetooth boards with less inputs?
Im not worried about the repetitive nature of coding multiplexers, but I'm completely unfamiliar with shift registers.
But, will the due be fast enough to read 16 way multiplexers without too much latency on playing keys?
Sorry I was misleading. I recommended the ESP because of there processing speed and low cost. That would allow you to use several if you want. No hint to use the radio portion. Check this link: https://techexplorations.com/guides/esp32/begin/esp32ard/ The faster processor will make your project less critical to code as it can do more in the same time.
Check this link out, it will explain a lot and hopefully make it easier. I built a board that has two sections, each section has two 74HC165s in series with two per sections board or 4 shift registers. They can be extended to any length wanted. I used 4 in parallel and two in series then I would read 8 bits each clock pulse. 16 clocks gave me 128 inputs. I can post a schematic if you want. They were all clocked together.
I saved the values in RAM and ran the shift registers in the background.
The ESP32 I believe has DMA (Direct Memory Access), which can be used to move data without using the CPU (Central Processing Unit). I have no experience with it on this processor.
Yes that was what I was saying but I do not know which pins are on what port. In a quick search I could not find that. With some of the old custom processors we could DMA the port into RAM. The logic gets very involved if you do not have a relative background.
I would also getting a USB logic analyzer, the '24 MHz' are less then $10 us from china. They look like this>
I think latency is the least of your problems. A humble Uno can in theory read a million switches per second from SPI shift registers. But maybe SPI port expanders with interrupt could be a better option. I think @PieterP is the MiDi expert here. Maybe he can chime in.
Leo..
Thank you everybody for sharing any relative info as individuals with more experience than myself!! I'm excited to join this community and contribute as I become more fluent!
I'll definitely be researching more about shift registers and port expanders
I will make a detailed build post documenting the challenges and successes of organ harvesting four 61 note keyboards and a shitload of toggle tabs and momentary pistons next month likely after ironing out these last few details
@audaciousastrid Regardless of processor, and almost regardless of programming approach, you need to map out your hardware needs, and hopefully describe them concisely for further consultations on this forum. Something like(numbers and descriptions pulled from a hat for illustration):
254 digital inputs monitor simple on/off keys (i.e. something that would be expected to change swiftly, randomly)
75 digital inputs monitor simple on/off stops(i.e. something you set and forget)
45 digital inputs monitor 3-position pedals (if such exist)
94 analog inputs monitor sliders(or whatever analog signal class you come up with)
This would significantly reduce the to-and-fro about how to best approach the whole build, reducing the chances you'll go down a blind hole. Once we have that, the nuances of monitoring each of the above, and any other class of input you come up with, can be discussed more thoroughly.
My apologies @camsysca ! I should have realized that the inputs of a VPO can vary wildly and to get the best help I have to ask in the best way! Thank you for correcting me!
My initial estimate is based off of the following metrics, which should allow me to play most very large sample sets.
The manuals are on 5 midi channels, and a 6th for the stops which send midi noteOn and noteOff code but channel 6 will be assigned to stops on software and interpreted appropriately. Pistons can use general cc channel of the manual they are attached to(thumb buttons) or of the 6th channel.
12+ analog inputs(8 faders, 3 expression pedals) possibly adding more because my VPO will be able to run software synths on each channel in a typical digital audio workstation like reaper, which have a lot of functions attached to potentiometers.
These metrics should give a much better idea of my project. It's about twice as big as the one in the video I attached from YouTube.
I'll make sure to capitalize on the most important details on the future.
EDIT: I think it is important to note that most of the heavy lifting of the VPO is done in computer-side software, so the Arduino only has to handle sending midi messages. So a very valid simplification of my project is: Very large midi controller. So if the Arduino can scan all of these states hundreds of times a second as stated above am I safe to assume it would it have no problem with me potentially doubling what little latency there is by using 74HC4067(16x mux) instead of 4051(8x mux)?
EDIT: wrong part number
Here is a code example for 64 switches with four 74HC4067 mux chips. But multiplexing is not the only way. 16-channel SPI expanders with built-in pull up resistors could simlify the hardware.
Leo..
const byte controlPin[] {4, 5, 6, 7}; // control pins s0-s3
const byte muxPin[] {A0, A1, A2, A3};
bool switchState[64]; // 0-63
void setup() {
for (byte i = 0; i < 4; i++) pinMode(controlPin[i], OUTPUT);
}
void loop() {
for (byte i = 0; i < 16; i++) { // channels
for (byte s = 0; s < 4; s++) digitalWrite (controlPin[s], bitRead(i, s)); // control pins
for (byte x = 0; x < 4; x++) switchState[i + (x * 16)] = digitalRead(muxPin[i]); // mux outputs
}
}
