On Tue, 15 Dec 2009 15:36:31 -0800, [email protected] wrote: > 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().
hmm. it is the "panic" button that is supposed to call fluid_synth_system_reset(). the "reset" button does call fluid_synth_program_reset() alright (you can see that on the messages window for evidence). or am i seeing things? :) > 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). > that is true and that is so by design. fluid_synth_unset_program() is being called on channel presets that were seen as unassigned when previously saved. this is part of configuration persistence. maybe not really necessary but it wouldn't hurt if fluid_synth_unset_program() and fluid_synth_get_channel_info() would agree in their effect :) byee -- rncbc aka Rui Nuno Capela [email protected] _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
