On 30.08.20 22:30, [email protected] wrote:
I'm a bit sceptic :) As you already noted, this would weaken the line between UI and core. What i like about the EventQueue at the moment is that it acts as a quite strict "protocol" between the UI and the core. Currently, i don't understand where the actual problem is. Do you think that too many events will clutter the eventqueue class? Or is it about adding many listeners to the UI?
Yeah, I like the current way too. And any approach would further increase the inconsistency of the code base because - regardless of the new concept - no one of us has time to port the existing code.
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 ).
Another thing for clarity: all events triggered by OSC and associated with the GUI should get pushed in it's UNDO/REDO stack, right?
Cheers, Phil _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
