[Top][All Lists]

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

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

From: Rui Nuno Capela
Subject: Re: [fluid-dev] Re: Last QSynth issues committed
Date: Wed, 16 Dec 2009 22:59:16 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20091130 SUSE/3.0.0-1.1.1 Thunderbird/3.0

On 12/16/2009 08:30 AM, Rui Nuno Capela wrote:
> On Tue, 15 Dec 2009 15:36:31 -0800, address@hidden wrote:
>> 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, 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 :)

i think i have this all fluid_synth_program_reset() thing gone right now.

qsynth svn trunk bumped to and it is behaving a lot better now
:) or so it seems.

i'm happy to say that remnant issues re.qsynth are moot now and
fluidsynth one-one-one may take off :)

rncbc aka Rui Nuno Capela

reply via email to

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