Re: [Audacity-devel] P2 Chains: some effects apply parameters last used via Effect menu instead of those stored in chain.

[Martyn S. <mar...@go...>]

Hi there

Dan Horgan wrote:
> On Tue, Jul 07, 2009 at 11:44:25AM -0700, Gale (Audacity Team) wrote:
>> Dan Horgan wrote:
>>> I've committed a possible fix for this. The problem affected the effects
>>> that remember their settings - the remembered settings were being
>>> applied by the call to Init after the parameters had been set in the
>>> chain.
>>>
>>> Now the parameter string can be passed into the DoEffect call (via
>>> OnEffect) so that the parameters are set in the right order.
>>>
>>> This is basically a quick fix - I think eventually effects should be
>>> Command objects so that they can use the parameter structure that is 
>>> now there.
>> Thanks Dan. As you may have seen on the Checklist, I haven't removed this
>> yet because Equalization still has the same problem as a result of every
>> change to the curve (applied in Chain or in the Effect menu) being written
>> to EQCurves.xml. Is the answer for this one to keep a separate xml file for
>> chains, and should we keep this as a P2?   
>>
>> I do think all the effects should remember their parameters independently
>> for "in chain" and "in effect menu", so applying a change in one place does
>> not change the parameters in the other. This is now true for the effects
>> that had the subject issue (except EQ). 
>>
>>
>> Gale
> 
> Ah yes, thanks Gale. I think I realised this when testing, and promptly
> forgot to do anything about it! I'm not sure what the best solution is
> here. I'd be surprised if it is necessary to have a completely separate
> xml file, and EQCurves.xml also contains the built-in curves which
> people might want to use in chains.

I don't think that would be a good idea.

> I think perhaps it might be enough to ensure that any curve used in a
> chain is saved with its own name - i.e. it is not just called 'custom'.
> The chain curves could still be modified by the dialog from the effect
> menu, but only if the curve with that particular name was saved over.

I think that's right.  People should not use 'custom' for the curve in 
a chain.  After all 'custom' is temporary, transitory, a scratch area, 
whereas a chain is supposed to be set up for repeating a job many 
times in many sessions (I think that's what it's for anyway).  People 
should save the curve they want with a name.  I would go so far as to 
say that we should programmatically ban the use of 'custom' as a batch 
parameter for EQ.  But maybe that's a bit much.

If you apply EQ curve 'A' to a waveform, then run a chain with an EQ 
curve 'B', then call up the EQ again you get curve 'B' and I think the 
bug is that curve 'A' is expected.  Is that right?

There is a variable 'mPrompting' in the EQ code which was originally 
intended to distinguish the batch from normal operation.  I note that 
it is not doing anything useful at the moment and is probably left 
over from a previous attempt to get batch working properly with EQ.

I also note the comment
    // Note: Init may read parameters from preferences
in Effect::DoEffect and the fact that EQ stores it's prefs away after 
successful completion (EffectEqualization::PromptUser).

So why not remove the references to mPrompting and read the prefs in 
EffectEqualization::Init (before the call to DontPromptUser) rather 
than in EffectEqualization::EffectEqualization?

TTFN
Martyn

> This wouldn't necessarily need the user to do anything special. I'm
> thinking that when building a chain, the EQ dialog would be passed a
> curve name like 'Chain-mychain-EQCurve-1' or something similar. Then if
> the user put in a custom curve, it'd be saved with that name (or at
> least, one like that but unique). The Edit Chains dialog would get the
> curve name that was actually used back from the effect, and that name
> could be used as the parameter in the chain.
> 
> I'm still looking at the code to work out how easy/possible this method
> would be to implement though.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have 
> the opportunity to enter the BlackBerry Developer Challenge. See full prize 
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>