Quoting Rui Nuno Capela <[email protected]>:
On 12/15/2009 07:41 PM, [email protected] 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
[email protected]
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
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
