Hi Will,
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.
On 17.01.24 14:27, Will Godfrey wrote:
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.
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.
So do I understand you correctly that we should go into the TOPLEVEL section
and somehow combine Control and Part?
TOPLEVEL::control currently starts at 251 and is all allocated up to 255
So I see two options here:
(1) either we use also the control=254 ("textMessage")
(2) or we let the controls start with control=250 and
use that new value 250 ("dataBlockExchange")
Depending on that we must than either use a differentiation on the part
(for Option-1) or we use Option-2 and can then also use part=250 ("Message")?
What do you think? Or is there another namespace where it would fit better?
We could probably use the two spare bytes in CommandBlock for a checksum.
I am aware that the checksum is a bit of a stretch, and maybe we do not
need actually to send it; the receiver seems to have enough information
to do a plausibility check anyway.
This brings me to another topic, which is the handling of connection-IDs.
....
as I'm under the impression that we'll see how it works out when starting
to use the new system.
Definitely another Heffalump - I've no ideas on that at the moment :(
As said, I'm rather confident on that one, since the GUI controls do get
connected to the right part in the core, and we'll basically just have to
follow the existing scheme, and probably we're bound to slightly abstract
or extend it. If this isn't sufficient, we'll do an initial handshake once
a new GUI control comes up.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
