Am 31.08.2020 23:06, schrieb Philipp Mueller via Hydrogen-devel:
The problem I see is the following: When e.g. toggling the metronome via GUI and OSC I would assume both ways trigger the same function (to avoid code redundancy). This function could e.g. be part of the `CoreActionController` and both the OSC Client and the GUI could call it. But when changing the state via OSC the metronome button of the GUI needs to reflect it. AFAIK this can be done either by 1. a dedicated `Event` via the `EventQueue` or 2. a shared state - e.g. a variable in the Preferences - the GUI check on every update. I'm far more in favor for approach 1. since it draws a clean line between GUI and core. But, yes, I think it will clutter the EventQueue badly. Just the couple of OSC commands I want to introduce right now would require five more Event types. As I recall from a talk at LAC Will Godfrey stated Yoshimi uses some >10000 OSC events to manage the communication between GUI and backend (but I may be mistaken here). The EventQueue would properly not scale well enough to support such a degree of scripting capabilities (although I do not intend to write an OSC command covering every single button :D ).
But if the UI has to poll a shared object (via a lock..) with a high frequency, then we will be bound to have new problems. The event eliminates the polling. As i see it, the problem of the event queue is just the code size, whereas the problem with the shared state is an architectural problem which might bring up other issues. What if we add a little bit more structure to the event queue by adding a "buttonPressed" action where the parameter is interpreted as a bitfield? Should we discuss this topic in person via jitsi or sth. similiar? I'm still not sure if i'm missing or misunderstanding
something :)
Another thing for clarity: all events triggered by OSC and associated with the GUI should get pushed in it's UNDO/REDO stack, right?
Hm, yes, that would be just consistent. Best regards, Sebastian _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
