Re: [Audacity-devel] Bass and Treble effect

[Richard A. <ri...@au...>]

On Tue, 11 Dec 2012 02:10:43 +0000
Steve the Fiddle <ste...@gm...> wrote:
> Your comment is extremely interesting. I presume that you mean
> "EffectSimpleMono" ?
Yes, I didn't have the Audacity source in front of me at the time.

> One of the major drawbacks for Nyquist effect
> plug-ins is the lack of "Preview". There are dozens of Nyquist effect
> plug-ins for which the ability to preview would be a godsend.
> I've had a look but I can't work out whether "Preview" would be
> possible or not. I noticed your "disclaimer" with the words "I think",
> and was wondering if could confirm if this actually is the case.
I had hoped that the structure was a bit more OO than it actually is.

Conceptually, in all the effects that I've looked at, the OnPreview()
method (which is hooked to the Preview button) does the same thing:

OnPreview()
{
save_the_previous_effect_parameters();

// gets control settings from UI into effect
TransferDataFromWindow();

mEffect->Preview();

restore_the_previous_effect_parameters();
}

The reason they are saving and restoring settings is in order to leave
the effect in the state we found it if the user cancels (except for
effects which don't do this ...).

This is a standard pattern, so we shouldn't have to write it in every
effect, rather in some sort of master template/superclass. I haven't
looked at the details, but my idea is to see if there isn't a sensible
way to implement save_the_previous_effect_parameters() and
restore_the_previous_effect_parameters() as generic code which takes
the ShuttleGui object as it's sole parameter and stores whatever it
finds there. This might also have relevance to commands (which need to
provide the effect settings externally) and chains (which need to do
both read and write of settings).

If we can do that, then the code in ::OnPreview() becomes not just the
same pattern, but actually the same in all the effects, and we can put
in in the superclass for all ShuttleGui effects (there may not be one,
but this may be an excuse to shuttle-ise some legacy code and/or create
one).

If we can do that, then there seems no good reason not to derive
the NyquistEffect class from the same parent, thus giving it (or at
least the Chain-able ones) preview support.

There seems to be more work than I had hoped for here (because there is
less infrastructure in place than I hoped), but all the steps should be
ones that lead to a smaller code base at the end of it!

Richard