Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behringer Pro 800 discussion #304

Open
christofmuc opened this issue Feb 11, 2024 · 1 comment
Open

Behringer Pro 800 discussion #304

christofmuc opened this issue Feb 11, 2024 · 1 comment
Labels
New device On Hold On hold for now, waiting for other items to be done.

Comments

@christofmuc
Copy link
Owner

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)

@christofmuc
Copy link
Owner Author

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!

@christofmuc christofmuc added the On Hold On hold for now, waiting for other items to be done. label Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New device On Hold On hold for now, waiting for other items to be done.
Projects
None yet
Development

No branches or pull requests

1 participant