RAc

From my understanding (I may legally call myself an embedded rt developer w/ close to 30 years of experience in the field), there is no "hard" limit that separates rt from non rt. The only limitation required by real time systems is that there is a ("small") guaranteed cap on turnaround time for real time components. Nevertheless, we probably agree that midi messages *should* in theory easily be handled using the computing power of even smaller computing devices available in 2024. We also agree, I am sure, that the delta between theory and practice exists exclusively in practice, never in theory (adage courtesy of @JimLucas).

spot on, Peter. Tanzbär is the literal translation of "dancing bear." Well observed!

Btw, here is a tidbit about the sensor I found out the hard way: The vl6180 has a resolution of 1mm, but not the accuracy. That means that if you statically and immovably put a constant distance (say, 25mm) between sensor and the next obstacle, subsequent readings (at least in single shot mode which I use) will yield oscillating results by a margin of around 3 mms. Others have observed this as well, even in total darkness. Those inaccuracies are apparently inevitable. Now, 3mms are not a very bid deal when measuring bellows, but it makes the sampling algorithm much harder to realize as one has to distinguish between those oscillating samplings and true deltas in subsequent readings. In effect, one would have to constantly read the sensor, then create a median over time and observe the travel of the median - possibly the contiguous you can set the sensor to mode already does that - and from that make an educated guess about the velocity. There is no rocket science in any of that, but to choose a good compromise for the median period between accurate reading and introducing too much latency sounds like a lot of fine tuning. That is why I wrote that there is a lot of room for imprvement on the software side. For the time being, I am not going to follow up on that as I need practice time more than nerding time, but if anyone feels like spending a lot of time in mapping very smooth and differentiated bellows movement to software, that sounds like a yielding project... 😉

yes, actually, that appears to be a fairly hot track to follow up on as the problem is definitely related to a rapid succession of messages being sent out. Also, I added the code that adds the very short microdelay directly after transmitting each message, and I have not seen those packet losses since, so it may be related to back-to-back messages. I have also realized that the problem aggrevates when I sample the key board less frequently. This also hints at the possibility that too narrow a spacing between outbound messages may be part of the problem, as then there are more messages to be pumped out in a single loop invocation. As you correctly observe, The Arduino does not have to do a whole lot; in the loop, I basically scan the sensor, then the keyboard, and as I have all of the information about velocity and keys to send, I pump out all resulting messages in a loop. It looks as if that is a contributing factor to the issue. Thanks again for the input!

Hi there Alex, please define "too far." From my understanding of bellows geometry, you can at maximum open them (theoretically) until the cardboard folds flatten to a perfect plane, then they will stop by themselves (of course, if you keep pulling hard after that, the cardboard will give in, but the prospective of rebuilding the bellows stops me from pulling that hard, and in my case, the length of the LH key board cable stretches to full extent before the bellows do).

I would expect those pistons to be audible when they release, also, I do not think they would respond quickly enough for fast playing. Finally, the overall weight with a fully equipped concertina may be rather taxing. But hey, experimenting with stuff like that keeps you off the bad side of the road, so why not give it a try?

are you talking about a MIDI controller or a device? I am designing a device, not a controller, so READING frames never occurs in my code, I only output frames.

So here is the making of video: Thanks to everybody who contributed to the project with help and encouragement. The video is not very well made (I am not a good photographer nor camera operator, and I hate documentation). Looking forward to your questions and remarks.

Thanks for the suggestion, SqueezyC - however I am not sure in how far a ring buffer on the app level would help as the timing problems are deeper down below. Do you mean not output the MIDI commands as they are detected but queue them and work off the queue asynchronously? I do not think that would be feasible with respect to latency. What would help is collating several MIDI commands into a single message, but that is much harder and more error prone to code. I have already considered in case of a further code iteration. Or were you getting at something else with respect to ring buffers?

fwiw, I did now evaluate the piano box as the sound generating end for my practice concertina. It simply does not work, manufacturer support claims that the power consumption of the Arduino is too high. The box is actually being developed in Taiwan and rebranded as miditech for the Western market, so apologies for writing earlier that the midiengine was a "chinese clone." Next thing I will look at is a Raspberry Pi 5 running Fluidsynth. It has a similar form factor and is even a little cheaper than the Pianobox. It runs RaspianOS which is a Debian distro, so fluidsynth should not be an issue there.

yes, you are absolutely right, the spacing is the big show stopper. On a Crane, the average vertical row spacing is eleven mms, but Gaterons will get you 18mms min which is a significant difference. Consequently, the end plates have ugly pan handles to make space for the hands, and I need a moveable hand rail to reach all buttons. Fortunately, the end plates containing the button bearings are completly decoupled from everything else, so I cn redesign and replace them without changing anything else once I have a better solution. Pics and a video hopefully later today.

Hi Don, thanks for your thoughts, but I may not have made myself clear... debouncing is not an issue, this is way behind. The problem is that I generate MIDI messages (whereever they come from, I might as well generate them programatically, forget about keyboards and switches for good for this discussion), but as soon as those messages arrive in a certain density (more than a single message in fast succession), they get lost somewhere in the call chain down to the wire. I (and the others who experience the problem) can guarantee 100% that the messages are generated on the application level, they just never reach the wire. And yes, I am aware lf the article that some celebrate as if it was the ultimate computer wisdom. More like computing 101, but irrelevant to the problem at hand. Interestingly enough, adding a delay in this case relieves the problem significantly, and I believe I know why. It's more of a workaround than a solution, though, and I much prefer solutions over workarounds (one of the results of 30+ years in system software dev). Thanks again for your input, I will get back to your bellows inquiry soon. And btw, I had to shelve the reed switches and now use plain old gaterons...

Hi there to all of you who use an Arduino to drive your MIDI concertinas (everybody else please igonre): I am facing the issue that has been raised here: need delay to send messages reliably · Issue #44 · arduino-libraries/MIDIUSB · GitHub (the last contrib in the thread is not by me but summarizes completly what I have tried so far). in short, my Due based concertina works fine, but every once in a while a note off message is generated in the software but never makes it onto the wire, causing "sticky notes." I am absolutely sure that the midi send command is executed, so it must get lost somewhere in the Arduino libs. Very likely this also affects note on messages, but it is only the missing off notes that are audible. Stepping through the code, I found that USB_send() has a hardcoded timeout of 250ms which will unconditionally drop the frame upon expiration. I may be running into that issue here. In this here thread: Hardcoded timeout in USB_Send · Issue #478 · arduino/ArduinoCore-avr an attempt has been made to make the timeout configurable, but the proposed change has never made it to the master branch. Thus my questions: - Have you run into the same issue during your development? - If so, have you found a definite root cause, a workaround or even a solution? - Has anyone experience in rebuilding Arduino libs (I would not mind experimenting with a custom usb driver)? I would be grateful for any input, pm would be fine if needed. Thanks so much! This is currently the only showstopper that prevents me from putting a lid on my midi crane project. btw: Whoever now believes that this is witchcraft or rocket science - no. it isn't. The project pretty much looks like the out of the box sample presented here: Create a MIDI Device | Arduino Documentation only a wee little bit tailored to concertinas. Everybody can do that, truly...

yes, give me a few days, I am about to finish the Gizmo anyways and will then make a docu bash including a video.

I have now had a chance to experiment with the VL6180x ToF sensor. It appears to work like a charm, covers exactly the range needed for my bellows, reads reliably and fast enough. I will receive the last mounting components in a few days' time frame and will present the final assembly then. For the mechanical part I simply built a gussetless bellows which has the additional advantage of a concertina like look and feel. The only issue then is the software. For my experiments, all I do is sample the current time stamp and sensor reading in every loop traversal, then compute the deltas for both between the current and last reading, then map the quotient to the permitted volume range of 1-127 and use that as the global velocity byte for the midi transmission. Lots of room for improvement and fine tuning, but probabaly I will leave it at that. For the time being, thanks for all the input and feedback, stay tuned!