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
>
[hidden email]
>
https://lists.sourceforge.net/lists/listinfo/audacity-devel>
------------------------------------------------------------------------------
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/Challenge_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
