Am 08.04.22 um 09:59 schrieb Will Godfrey:
This whole structure was built up over a very long time
...
The ControlModel.pdf in dev_notes is *supposed* to describe the overall
structure, and mostly shows what you are saying - although it doesn't include
the loopback behaviour, nor the most recent undo stuff of course.
...
Also if there's general agreement, after this work is completed I think we
should pause further new development and see if we can clean up what we
already have.
Hi Will,
I really shouldn't work late... and tired.
same goes for me, I poked around in the code and was overwhelmed by the details.
I have overlooked the elephant in the room: we are doing something completely
new here. Up to now, external sources sent command messages. But now, several
internal sources are sending status messages. That is the reason why we don't
get a clean fit with the existing structures.
There is something I'd like to add: I am in full support of and favour the
/intended structure/. The basic idea of yoshimi's command processing is headed
in the right direction: we do not just grab in and /do/ something, rather we
send an instruction, which is routed and dispatched. This is in fact the only
sane way to build a real-time processing system.
What we might want to improve are some aspects of the actual implementation.
- we are mixing the MIDI processing (which must be low-latency) with general
command processing. This forces command processing into being very low-level
and optimised, which causes the use of hard-to maintain code patterns.
Like passing one single fixed-sized command block by reference through
a system of switch-case-statements. And overloading the limited number
of fields in that single block with several meanings.
- there should be really one single high-level entrance point to command
processing. Right now, GUI, CLI and MIDI each have their own pathway.
- command routing and dispatching should be separated completely from
command processing. Right now, both are interwoven at times.
Most notably, we are doing command routing and dispatching from
within the real-time thread (mediate() is driven by SynthEngine).
Btw, many modern real-time processing systems go even one step further:
they do prepare not only the commands, but even the real-time work in the
form of work jobs, and this preparation of work-jobs does happen outside
of the real-time thread(s), but in one central scheduling thread.
A transition towards such an architecture could be a long-term goal
for Yoshimi too, since it would enable to scale horizontally.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
