You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It took me a while to find this thread again. AFAIK, Behringer still haven't released any more documentation on the sysex implementation of the Pro 800, and there doesn't seem to be any correlation to the DeepMind sysex.
They documented the patch structure, and sysex commands to dump or store a single patch to a numbered location. We also have a command to retrieve some global settings, but no details of how they're structured. It seems the number of the currently selected patch is in there, which could be useful if it's possible to make the Orm adaptation do a two stage process - retrieve the globals, to get the current patch number, then retrieve that patch to simulate getting the edit buffer from the synth - though with no way to send it back.
One option to simulate sending to the edit buffer would be to send a long series of CCs, because all, or almost all parameters have one. That wouldn't send the name though. Possibly there would need to be short delays between CCs, to avoid overwhelming the synth.
I'm not sure how much of this an adaptation could currently do, but it seems like something that could maybe be done, one day, but possibly some changes to how adaptations work would be needed.
I've mentioned part of the problem in #234 - I'd need either the adaptation or the user to be able to say what happens when a patch in the Library grid gets clicked. If patches are stored in Flash, routinely sending them to the synth could wear it out quite quickly, and without manual or adaptation control, I wouldn't be confident that wasn't happening.
Interesting! I had implemented the "CC-flood" mechanism for the Rev2 at some point, not because it would be better or faster, but because that way you could keep playing while patches are switched (because the synth would just stop playing when it received a sysex). So this is not terribly hard to do, just that we need to have patch parameter information (many synths already have that).
I'll open a new ticket just for the sake of the CC-flood, which is a fun feature in itself!
It took me a while to find this thread again. AFAIK, Behringer still haven't released any more documentation on the sysex implementation of the Pro 800, and there doesn't seem to be any correlation to the DeepMind sysex.
They documented the patch structure, and sysex commands to dump or store a single patch to a numbered location. We also have a command to retrieve some global settings, but no details of how they're structured. It seems the number of the currently selected patch is in there, which could be useful if it's possible to make the Orm adaptation do a two stage process - retrieve the globals, to get the current patch number, then retrieve that patch to simulate getting the edit buffer from the synth - though with no way to send it back.
One option to simulate sending to the edit buffer would be to send a long series of CCs, because all, or almost all parameters have one. That wouldn't send the name though. Possibly there would need to be short delays between CCs, to avoid overwhelming the synth.
I'm not sure how much of this an adaptation could currently do, but it seems like something that could maybe be done, one day, but possibly some changes to how adaptations work would be needed.
I've mentioned part of the problem in #234 - I'd need either the adaptation or the user to be able to say what happens when a patch in the Library grid gets clicked. If patches are stored in Flash, routinely sending them to the synth could wear it out quite quickly, and without manual or adaptation control, I wouldn't be confident that wasn't happening.
Originally posted by @Andy2No in #268 (comment)
The text was updated successfully, but these errors were encountered: