Re: [Audacity-devel] Context menu and spectral selection effects

[Paul L. <pau...@gm...>]

On Fri, Sep 25, 2015 at 7:16 AM, Steve the Fiddle <ste...@gm...>
wrote:

> On 24 September 2015 at 16:28, Paul Licameli <pau...@gm...>
> wrote:
> >
> >
> > On Thu, Sep 24, 2015 at 11:08 AM, James Crook <cr...@in...> wrote:
> >>
> >> On 24/09/2015 14:32, Paul Licameli wrote:
> >> > I will summarize a proposal here that emerged in other emails.
> >> >
> >> > 1.  Give Audacity a right mouse button context menu for selections in
> >> > wave tracks.  Cut, copy, paste, and delete commands will be there, as
> >> > for the context menu that appears when you right-click on a label text
> >> > box.
> >>
> >> +1
> >> I found I needed to make the right-mouse context menu in AU14 track
> >> panel hierarchical.
> >>
> >> > 2.  Give class Effect a means to inform Audacity that it requires a
> >> > spectral selection. (Just as effects now tell the manager whether they
> >> > are "linear" and need special treatment during preview.)
> >> +1
> >>
> >> > 3.  Define a Nyquist header comment that encodes this choice too, so
> >> > that Nyquist.cpp can interpret it for the effects manager.
> >> That's a possible mechanism.
> >
> >
> > Not an alternative, a necessary part of this idea.
>
> This may be the best mechanism, but there are always alternatives. If
> you don't see them, you are thinking too narrowly.
>
> Just off the top of my head (and these may be bad ideas):
>
> One alternative would be to create a new effect type (generate,
> process, analyze, spectral)
>
> Another alternative would be for Audacity to deduce the effect type
> from the plug-in name (any plug-in that are called "spectral edit ..."
> require spectral editing to be enabled).
>
> Another alternative would be to have a subdirectory of "plug-ins" for
> spectral effects.
>

Those are variations of implementation detail of a common idea:  some
classification of effects as spectral so that the effects manager can treat
them differently, such as putting only them in a context menu or disabling
only them in some conditions.


>
> Another alternative would be to allow effects to use the spectral
> selection when available, and do something sensible when spectral
> selection is not available (at run-time, if the spectral selection is
> called but not available, the user is prompted to enter the required
> frequency).
>

So the .ny effects could prompt the user, but only conditionally, when they
are passed insufficient information.  I don't think Nyquist programming has
the means for this yet.  If it did, I think that would answer the
objections that the present Spectral effects give no help to the curious
who find them in the menu and try them out before they have discovered
spectral selection.

I think any help text coded in Nyquist should not make strong assumptions
about user interface details, else there is a burden to update them -- the
message telling you to select Spectral Selection  or Spectral Selection
log(f) view was too specific and needed revising when the interface
changed.  I made the error of messages that are too general.

Perhaps we should implement a common prompt for frequencies entirely in C++
-- so its messages internationalize too -- and just bind a function that is
callable from Lisp to get frequencies.  Then spectral editing effects in
Nyquist would not include any new user-visible strings and would not need
updating with new Audacity versions.

Besides which we may have spectral effects that are not written in Nyquist
that could invoke the same prompt.


>
> Another alternative is to create a wrapper for (any) effects that
> makes them aware of spectral selections when in spectral editing mode
> (all effects become "spectral" aware).
>

My spectral editing is not a "mode."  Maybe Federico and Luciano's project
was.  I don't like the idea of making it a mode.


>
> Another alternative is to not have "spectral effects", but rather to
> use an FFT filter to pass the spectral selection to an effect,
> filtering out the selection from the original, then mixing the
> processed audio back into the track.
>

This may have merit but not as an alternative.  If this is a suggested
extra capability, it may be useful.  If it is meant to replace what we
have, I say no.  Do not force all spectral effects to work this way.

I wrote the few spectral effects to operate directly on time domain
signals, and require one or two frequency parameters.  Spectral selection
is a convenience for specifying those frequencies with mouse movements.
These effects do not affect only the frequencies within the spectral
selection box.  The top or bottom can specify a -3 dB point, so there is
some attenuation even outside the spectral selection, and there may be
phase shifts even in passband.  I don't think these useful effects could be
satisfactorily reimplemented as proposed.

PRL


> The point is that there are alternatives and I don't think that we
> should fixate on one option before alternatives have been properly
> considered with an open mind. This may slow down the introduction of
> new features, but better that than ending up with a bad implementation
> of a great idea.
>
> Steve
>
> >
> >>
> >>
> >> > 4.  Use this comment in the existing spectral editing effects.
> >> > 5.  In the right mouse context menu, when spectral effects should be
> >> > enabled, add a separator and list them.  Otherwise hide them.
> >> -1
> >> We expect the number of spectral-selection effects to grow
> significantly.
> >
> >
> > Oh?  Very significantly, to the point that the menu is unmanageable?
> Who is
> > busy writing them?  Perhaps I should be.
> >
> > Even if they should become many, which I doubt, the effects manager could
> > disable the infrequently used ones and keep your menu small if you wish.
> >
> >>
> >>
> >> > 6.  In the Effects menu, these effects also appear.  When spectral
> >> > editing effects should be disabled, all are disabled by the Effects
> >> > manager and appear gray.
> >> -1
> >> Greying out of effects has a long history of confusing users.  "Why are
> >> ALL me effects greyed out?".   IMHO better that users learn (via a
> >> prompt) that they need the right inputs for the effects.
> >
> >
> > I say it again, do not make it any less convenient for the experienced
> user.
> > I want spectral editing effects that are bound to keystrokes to remain
> > promptless when there is a spectral selection.
> >
> >>
> >>
> >> > 7. The condition to enable spectral editing effects is: firstly,
> >> > either top or bottom frequency selection is defined.  And secondly,
> >> > either the spectral editing toolbar is visible, or, at least one of
> >> > the selected tracks is in spectrogram view and enables spectral
> >> > selection.
> >> +1.
> >>
> >>
> >> > My proposed criterion for enabling the effects would sometimes allow
> >> > spectral selection to apply even in a track that shows a waveform,
> >> > when the spectral selection toolbar is visible or if another track
> >> > showing spectrogram is part of the selection.  My proposal would add
> >> > the spectral editing effects to the context menu even if the pointer
> >> > is in a waveform track.  My proposal would never allow the effect for
> >> > only some selected tracks but not others.  My proposal would apply the
> >> > spectral selection effect to each selected track or not at all.
> >> It's OK, but not compelling.  It's very rare I would want to do the same
> >> spectral edit to multiple tracks (except if they were duplicates) since
> >> the most usual case is removing an artifact and the artifacts are per
> >> track.
> >
> >
> > Remember what I said about workaround for the lack of split views.  Have
> > duplicate tracks in different views.  Apply every effect to both tracks.
> >
> >>
> >>
> >> > This is all intentional and is part of the workflow I had found
> >> > useful.  (To satisfy my preferences, it's either that, or I develop
> >> > split views.)
> >> We can go with that, and just most of us (or me anyway) will typically
> >> select just one track at a time.
> >>
> >> > Benefits:  we make it discoverable for a new user what to do with that
> >> > spectral selection box.  We enable and disable spectral editing
> >> > effects in a uniform way in the effects manager and do not require
> >> > each effect to decide that for itself.
> >> -1.
> >> It's not true.  With your plan users will still be stumped by the
> >> spectral edit effects.  The box will appear to do nothing special for
> >> most effects.  We need a clear plan to fix that too.
> >
> >
> > The box will in fact to nothing special for most effects.  I don't see
> that
> > as a problem that must be fixed.  I think enhancement request 917 is not
> a
> > good idea that has been well thought out.
> >
> > The context menu gives a clue as to what the box is for.  The few
> spectral
> > editing effects (I am not persuaded they will not remain few) are there.
> >
> > In fact with the context menu, I would enable spectral editing by
> default,
> > and give you the means in the context menu to disable it if you don't
> want
> > it.  But then new users who use spectrograms at all will discover this
> > feature.
> >
> > So what did I say that is not true?  Is it not correct that the spectral
> > selection, and what it is useful for, could be discoverable just with a
> > click and a drag and a right-click.  Is it not true that spectral editing
> > effects could be switched on and off uniformly?
> >
> >>
> >>
> >> > Drawback:  I don't know how much else ought to go in the context menu
> >> > and fear agreement might be hard to get. Should other effects be
> >> > listed?  Then which?
> >> The hard part of agreement will be picking a number/size.  And Tall and
> >> shallow or short and deep.  Only an issue for the default in any case,
> >> if we make it configurable.  I would suggest max 8 items at each level,
> >> and as many levels as we like.  If we agree on that, then voting may get
> >> us the rest of the way.
> >>
> >> >
> >> > I nominate myself for most of this, because the context menu impinges
> >> > on the track panel rewrite that is another project I am preparing.  I
> >> > might need help for the interaction with effects manager.
> >> >
> >> > PRL
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> >> Get real-time metrics from all of your servers, apps and tools
> >> in one place.
> >> SourceForge users - Click here to start your Free Trial of Datadog now!
> >> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> >> _______________________________________________
> >> audacity-devel mailing list
> >> aud...@li...
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> > Get real-time metrics from all of your servers, apps and tools
> > in one place.
> > SourceForge users - Click here to start your Free Trial of Datadog now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> > _______________________________________________
> > audacity-devel mailing list
> > aud...@li...
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>