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: Rui Nuno Capela
Subject: Re: [fluid-dev] Re: Last QSynth issues committed
Date: Wed, 16 Dec 2009 08:30:28 +0000
User-agent: RoundCube Webmail/0.3.1

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 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
address@hidden





reply via email to

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