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

[josh]

Quoting Rui Nuno Capela <address@hidden>:
> On 12/15/2009 07:41 PM, address@hidden wrote:
> > Ahh, and I thought that was going to be the golden commit.
>
> aha, ya know, all that glitters ain't gold :)


We'll see about that ;)


> and that will get you to qsynth 0.3.4.11, the one i fuss with ;)


Ok, now using that.


> you can select but it won't stay that way for long, at least on my lab.
> pressing reset button, which implies fluid_synth_program_reset() will
> just put all channels back to default bank/program and not the assigned
> ones.


This time it looks like a QSynth issue.  First off,  
fluid_synth_system_reset() is getting called when you press the Reset  
button, not fluid_synth_program_reset().  Second, it looks like  
fluid_synth_unset_program() is getting called when it shouldn't be  
from qsynthOptions::loadPreset (gets called after initial startup and  
also when pressing the reset button).

Hope that helps ;)


> right, but that's not what it is doing, at least when probed with
> fluid_synth_get_channel_info(). nb. older qsynth 0.3.4 is probably
> reading channel information via fluid_synth_get_channel_preset(),
> instead of fluid_synth_get_channel_info(), remember?


Yes, but my qsynth 0.3.4 had been modified to use the new function,  
the patch I sent you.


> qsynth 0.3.4.11 as in svn trunk has this new "unset" option on the
> channels' context menu, so you can try that too.


Cool.


> cheers
> --
> rncbc aka Rui Nuno Capela
> address@hidden


I think I should probably do something about the Chorus effect.  Its  
now thread safe, but terribly inefficient when changing parameters and  
causes Jack drop outs.  Not sure what kind of quick fix could be done  
though.  Perhaps I should just return it to its previous thread unsafe  
state of doing the chorus processing outside of the synthesis thread.   
Long term, it should just be replaced.

Josh