Okay… so I have this home built midi cc controller that runs on arduino pro micro and works as a midi device and it doesn’t have any problems working in different environments and also in cubase as a normal midi device it doesn’t cause any problems.
I did however note that on startup if I have the controller plugged in it causes a error message from cubase telling me it froze but cubase still boots normally after hitting okay and it works as a normal midi device just fine.
The problem arises when I try creating a midi remote out of it. At first it might work for a second but then sooner or later cubase just freezes and won’t function until I disconnect the midi controller. It especially happens often when I have the midi remote bound to some funtion and then try to move the slider.
So my question really is that… has anyone else had this same kind of experience working with the new midi remote system? Or is the cause of the problem only on my end and possibly in the home built midi controller.
That’s so cool that you built your own controller. Are you using the GUI Surface creator or a JS script?
It could be in the JS when you handle callbacks, the functor members that start with mOn.
It could also be the amount of information that is being sent to Cubase. Often when you create a MIDI controller, like with USB-MIDI and the like, the potentiometer you use to attenuate the knob or fader is going to send continuous data. This may work ok in some situations. But the reality is that more information than is necessary is being sent. What you need to do (if that is the case) is only send the data when the CC value has changed.
Since you only get 128 discreet values, sending a continuous stream normalized to 0-127 results in an abundance of duplicate messages.
The issue I take with this code (other than style) is that Gustavo determines the CC value, and then does a lot of computation before checking if the CC value has changed before buffering the change and flushing. Instead he could check if the CC value is any different and only proceed from there if it is. In fact, I’m not even sure that most of that code is even necessary. Still he IS checking to make sure the CC value has changed before sending the MIDI message.
The problem could also be in your JS. Even with the dampening described above, it is still possible to overload Cubase in the callback as it is in-line with the thread in Cubase.
Yeah I did think about this and the way it is programmed right now is that it always checks if the potentiometer’s voltage changes a certain thresholds amount it will trigger a midi event.
But one thing that could be causing some kind of continuous midi messages could be the library that I send those messages. I used the MIDIUSB library and I don’t exactly know how and how often does it send those messages.
Only when you flush does it send the message, but it sends all of them you have put in the buffer. So when you call controlChange or sendControlChange that puts the message in the buffer.
When you call flush it send everything in the buffer.
Instead of using the threshold, (or in addition to as in the video). You need to make sure you aren’t ever sending the same message twice.
I don’t know why all the threshold stuff is in everyone’s code.
Or actually I do. see below
A while back I had a board and I made a controller with it, and I only ensured that the midi value I was sending had changed and didn’t worry about any threshold. I did check the time though, as in the video. And it worked just fine.
You absolutely need to ensure that you aren’t sending the same midi value over and over.
About the threshold. The reason that you might want to check the threshold in hardware is that sometimes even when you don’t move anything, it can fluctuate back and forth. This can be fixed with the right circuit, but you still need to check in the software. However, this doesn’t tend to happen between two midi values, but it could… so checking the threshold difference is probably a good idea too. I would just swap the order of operations, and only check on the threshold condition when the midi values are different.
Okay yeah I think I have found the cause of the problem…
So after reading that I tested this out by assigning a midi track’s output to be the midi controller and then causing some midi event… and it does loop the midi messages. So the root of the cause is in the midi controller’s way of forwarding all the incoming messages back to machine and causing a never ending loop that freezes Cubase.
I further tried stuff out and when creating the midi remote surface if I set the output midi to something else other than the home built one it doesn’t freeze.
For now I have just fixed with that but when I get the chance I’ll look in to the arduino code and make it so that it doesn’t echo those messages.
glad you were able to confirm that it was an endless feedback loop - I haven’t programmed my own midi controller (although it’s somewhere on my bucket list), but having worked with more midi devices than I can count, there’s the concept of a “soft-thru”, which makes all messages at the midi input get passed on to the midi output and effectively being merged with midi messages from the device itself.
So I’m wondering if your midi library has maybe a simple preference or configuration setting or global constant to disable soft-thru?
p.s. Many older midi devices have a separate hardware “thru” port (5pin DIN), which was originally intended for chaining several midi input devices in series. The soft-thru emulates that idea.
Yeah I’m not entirely sure I might need to do little digging. If I remember correctly I think the library had pretty poor documentation. I might end up using an entirely different library but the one I’m currently using is MIDIUSB.