Hi Will,
since the data structures are more or less clear by now (in my head, that is,
and partially also in the code...), the question arises how to make use of
the *codes for the CommandBlock*
After looking into the Yoshimi Control Numbers (nice to have them as HTML btw!),
I get the impression that I'll need some guidance how to make our new system
best fit in with the existing structure.
To summarise what we'll do:
- whenever "someone" publishes an update
- then the GuiDataExchange will post a CommandBlock into the toGui ringbuffer
- the dispatch in "main thread" will consume those...
- and when it recognises that this is a message from GuiDataExchange
- it will invoke GuiDataExchange::dispatchUpdates(CommandBlock)
- the rest is managed internally, i.e. GuiDataExchange knows the receiver.
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)
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.
- 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
But those are rather details to settle further down the road.
For the moment, what we'll have to decide is how to encode the ongoing
notifications into CommandBlock, as described above, which fields to use,
which codes to set.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
