On 10.09.24 20:37, Kristian Amlie wrote:
Hey, guys! Sorry, I've had an extremely busy day, and it's not over yet.
I won't be able to test your branches until tomorrow, but I'm replying
to your questions below.
Just take your time. We're glad you can assist with this testing effort.
For context: we are pondering how to proceed with this branch.
The next release was intended to be soon; so one option would be to
delay it until after the release. But that's somewhat tricky, because
right now this feature is half-way landed; the first part was merged
this spring, and this causes some problems for launching a standalone
yoshimi with several SynthEngine instances.
On 10.09.24 20:37, Kristian Amlie wrote:
Oh and it's also going to 6 different channels at the same time! I know,
it's a mess. I'm using a digital guitar, and each "string"
has its own channel.
precisely that kind of stress test we need, that sort that's hard to imagine
and make up off the top of one's head...
If a lot of effect commands are processed, we could end up with producing
more than 64 push updates before a GUI thread did consume anything.
In that case, newer updates could overwrite older ones.
Hmm, possibly. This is per block length, or? I don't think *that* many
would make it through in one single block length, but I can't say for sure.
Not even that. The UI event thread has a typical duty cycle of 30 milliseconds,
which is really a lot of time. And when the GUI was never opened, then there
will be no consumer at all, so the ringbuffer and the cyclic data buffer
will just happily flooded with updates.
Being more selective here would be quite difficult in the current configuration
of Synth threads and the communication system. In the LV2 case, we could
probably suppress all push updates when the GUI has not even be instantiated,
but that would not help either for a GUI that has been hidden or for the
stand-alone situation, where the GUI is always created at start-up.
In theory it would also be possible to offload the generation of push-updates
to the background thread, but if you think through the details, it becomes clear
that getting that correct is anything but simple.
For that reason, I went for the simplest thing that could possibly work,
which is just to flood the communication system; populating a data block
with some values locally available in the current thread is typically
much faster than any "clever" system which requires thread coordination.
However, how all of this plays out on average and in border cases / worst cases
and how to strike the right balance is something we have to find out, its a new
approach we're trying out after all.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
