Cherry picking for commenting:
>So this would be rather a generic mechanism not tied to any specific part >or window. What seems closest is the "textMessage" in the TOPLEVEL controls, >which sets >control = 254 >part = 250 >miscmsg = msgNo > > >For our case, probably we'll also put the slot-number into the `miscmsc`; >this is the only information required at that stage, because all further >information for routing and data type is the index entry for this data slot. >We could however (and indeed we should) send a checksum alongside in another >data field, to be able to detect when the slot is outdated or was re-used >meanwhile (in which case the GUI would maybe print a warning to the log) We could probably use the two spare bytes in CommandBlock for a checksum. Currently only spare1 is used, and that only for finding the current Dynfilter preset when checking the default of two controls. It's most frustrating that I haven't (yet) found a better way to do that :( As an aside, using the combination of Control and Part to isolate a command, we can then abuse the remaining 8 bytes - effectively as a 64bit data block. >This brings me to another topic, which is the handling of connection-IDs. >In the design I'm pursuing at the moment, I assume that these connection-IDs >are somehow shared / established up front. In essence, these are arbitrary >numbers, which are allotted at first use, and both partners of a conversation >must know that number. I haven't spent too much thought about that aspect, >as I'm under the impression that we'll see how it works out when starting >to use the new system. Basically there would be several possibilities > >- most simple is to make it static, which works only if the source in the > Yoshimi core is unique and known statically. This can't be assumed. In standalone someone can start two completely independent instances from the desktop, and in LV2 they are supposed to be independent anyway. >- otherwise that could be something the part in the core (e.g. some OscilGen) > creates at construction, and when a GUI is attached to that part, this > information must be provided. In a similar manner as now the GUI control > gets the "synth" pointer in order to know the sampling rate. (yes, we want > to sort that out and abstract it rather from the "synth", but this doesn't > change the fact that the GUI control gets some setup information > dynamically. > >- in a more elaborate future version, we might consider to send some > initialisation message / configuration block for a new GUI part, and then > we'll probably somehow have to use the addressing scheme for CommandBlock > Definitely another Heffalump - I've no ideas on that at the moment :( -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
