Quoting David Henningsson <[email protected]>:
Quoting Rui Nuno Capela <[email protected]>:
I was thinking the same thing, in regards to notification callbacks.
I'm not saying my way of thinking is the one and only right way forward,
but given state-machine and voice-renderer thinking, the notification
callback way is the wrong way. The right way for system reset would be to
immediately reset the state machine, and then send an "all voices off" (or
similar) to the voice renderer. Then a call to retrieve current program
would succeed correctly.
So the state machine would be mutex protected in that case? I'm
beginning to agree, that the current architecture of FluidSynth, while
an improvement, isn't ideal. I don't really have the interest at this
current time to look into it though, since I'm focusing on Swami. I'd
be open to kicking around some ideas though.
So its a go then! :)
Moving things in and out of synth context (as recently said on the list
for reverb/chorus) always raises the question of reordering. Is that
something that can be a regression of 1.1.1, that given a certain timing,
reverb/chorus changes can fail?
No, they should never fail. I just put it back the way it was before.
The chorus/reverb changes take effect immediately, no queuing or
anything. I had originally queued it because I suspected there could
be multi-thread issues. Looking over the code though, I realized that
there probably aren't any crash issues. There are synthesis related
issues though, but that is already obvious, from previous versions.
// David
Josh
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
