fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Re: Last QSynth issues committed


From: josh
Subject: Re: [fluid-dev] Re: Last QSynth issues committed
Date: Sat, 19 Dec 2009 19:45:39 -0800
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:

Quoting Rui Nuno Capela <address@hidden>:

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]