Re: [Audacity-manual] TLC for Nyquist

[Steve t. F. <ste...@gm...>]

On Wed, 30 Jan 2019 at 19:04, James Crook <cr...@in...> wrote:

> Reading through, I think the place to start is the plug-in manager.
> It is a current 'pain point' for Nyquist.
>

I agree.


>
> Fixing it gives us a worthwhile step forward soonest.
>

Indeed.


>
>
>
> On 30/01/2019 13:53, Steve the Fiddle wrote:
> > At the moment, a major limitation of "Nyquist-Macros" is that they cannot
> > modify the project with Nyquist. For example, you can include "High Pass
> > Filter" in a normal Macro, but not in a Nyquist-Macro. It would be very
> > useful if we could find a solution.
>
> +1
>
> I think we shouldn't be fretting over say Nyquist calling a macro
> (formerly chain) that then calls a "High Pass Filter", but we should
> look into Nyquist tools macros having access to project wave and other
> data at the same level as Nyquist effects do - so you could then include
> the High Pass Filter code in a more complex tool, something you can't do
> currently.
>
>
> > I think we also need to look toward a different way of creating Nyquist
> > Plug-in GUIs, rather than the current ";control" comments:
> >
> > * I'd like the GUI definition to be able to call Nyquist functions while
> > the GUI is displayed, similar to how we use "::OnSomeControl" in C++
> > plug-ins.
> >
> > * I'd like controls that can generate "control signals" (low sample rate
> > "sounds") rather than just numeric / string values, so that "real-time
> > preview" becomes possible.
>
> +1
>
> These two are aspects of 'a more sophisticated shuttle GUI' that Paul
> has expressed strong opinions about and interest in doing.  I don't see
> a barrier to us giving Nyquist access to shuttle GUI, and indeed if we
> do revisit ShuttleGUI, we should make this ability one of the
> drivers/requirements for the enhanced design.
>
>
> > * I'd like Nyquist to be able to access arbitrary blocks of audio data
> from
> > the project during execution, rather than be limited to grabbing the
> > selected track audio at launch time, so that, for example, a Nyquist
> macro
> > can modify the track with a built-in command, and then apply Nyquist code
> > to the modified audio.
> > This would also allow multi-pass effects (such as normalizing) without
> > having to retain the entire track in memory.
>
> I see this as the same thing as solving the 'nyquist macros can't apply
> nyquist effects' problem.


I was unsure if this was "the whole problem", but I clearly see that the
two things are closely related.


> Access to audio data opens the route to
> that.  The 'price' will be that any nyquist code that does that will
> need to be explicit about looping over data, whereas nyquist effects are
> not.


Some plug-ins do need to be explicit about looping over data, it's just
that "most" don't.
A good example of when you would explicitly loop over data, is when you
need to apply some process sample-wise.

Generally we try to avoid looping through samples in a LISP loop (it's very
slow), though doing so can be useful when writing a "proof of concept" that
only requires short audio clips. There's probably four approaches currently
in use:

1) A simple DO loop with (SND-FETCH) to grab each sample. This is usually
done with a low sample rate copy of the audio. An example is "Silence
Finder".

2) Just grab the entire audio in an array with SND-FETCH-ARRAY, then step
through the array, and finally convert the array back to a sound with
SND-FROM-ARRAY. This is convenient for "proof of concepts", but can only be
used on short audio clips. SND-FETCH-ARRAY is limited to a million samples.

3) Iterate through the sound, grabbing less than a million samples at a
time (say, 10,000) with SND-FETCH-ARRAY. This is usually much faster than
grabbing single samples and is practical for fairly long tracks. The
shortcoming is that we can't currently write the samples back to the track
until the script ends, so we have to build the sound in RAM and then return
the entire sound as the return value.
This is the flip-side of being able to access arbitrary blocks of audio
data.

 4) Creating a DSP class and an iterator. This is the fastest way to loop
through samples, but also the most complicated. I used this method to
create prototypes / proof of concepts before writing the improved Pink /
Brownian noise generators in C++.


Explicit is not a problem as of course that can be made nicer by
> some careful preexisting nyquist functions.
>

Yes.


>
>
> > Steve
> >
> > On Wed, 30 Jan 2019 at 13:34, Steve the Fiddle <ste...@gm...
> >
> > wrote:
> >
> > Another idea: An IDE for Nyquist Plug-ins. This could be included in
> > Audacity, or a separate app.
> >
> I don't think it would work well as a separate app, though a plug-in
> extension would make sense.
>

Are you thinking of our "module" type plug-ins?


>
> I'm kind of inclined to think in another direction, and build on the
> proposed shuttle gui extensions...  so for example if shuttle gui could
> add panels on which we show things, we could craft a panel with Nyquist
> diagnostics on it and such - and have a built in nyquist function for
> 'nyquist diags' do that.  These extra panels would (perhaps) become our
> Nyquist IDE.
>
>
> > If done as a separate app, it could be written in Python / Tk, which
> would
> > perhaps encourage contributions from users of the IDE, and provide easy
> > integration with mod-script-pipe (pipe commands directly from the IDE to
> > Audacity).
> >
> Not convinced by this.  New contributors have then to juggle with too
> many technologies.
>
> A bit of a pipe dream :-)
>

Ho Ho :-)

I was thinking that with the popularity of Python, there may well be people
that are reasonably fluent in Python and interested in getting to grips
with Nyquist. In this case, they are only really needing to juggle one ball
- Nyquist.

If I was developing an IDE for Nyquist plug-ins, I'd be quite tempted to
write it as a separate app in Python, simply because I think I could make
much faster progress than writing it in C++. However, your shuttle GUI
ideas could change the landscape dramatically.


>
>
> > On Wed, 30 Jan 2019 at 13:21, Steve the Fiddle <ste...@gm...
> >
> > wrote:
> >
> > Off the top of my head, the "Plug-in Manager" could do with a lot of
> > improvement. Currently it does what it was designed to do, but it is not
> >  user friendly, and lacks several useful features.
> >
> +1
>
> Plug-in Manager is very unsatisfactory at the moment.
>

At the time it was written, we desperately needed "something", and we got
something, so it did serve a valid purpose, but I agree, a radical
re-design could be in order.


>
> Needs quite a radical re-design, I think.
>
>
> > Some features that would particularly benefit Nyquist:
> >
> >  * Filter plug-ins by type.
> > So that you can list only Nyquist plug-ins, or only VST plug-ins...
> >
> >  * Parse the names of new Nyquist plug-ins.
> >
> With the right code we could/should be able to do this name parsing fast.
> What takes time with VST plug ins is that dlls take time to load. But
> text files are (or should be) quick to read.
>

I hoped that would be the case.


>
>
>
> > If we are concerned about the speed of the manager scanning plug-ins,
> > then this could be limited to when the manager filters by type.
> > Currently, a new (not yet installed) plug-in, is listed as something
> like:
> > trybeforeyoubuy /home/steve/.audacity-data/Plug-Ins/trybeforeyoubuy.ny
> > Whereas after it has been installed, it will show the "name" of the
> > plug-in. User's seem to expect to see the name of the *plug-in* rather
> > than the name of the *file*.
> >
> > * Option to install a Nyquist plug-in from an arbitrary location.
> > We may not be able to do this for all plug-in types (some plug-ins
> > require running an installer), but we can certainly do it for Nyquist
> > plug-ins.
> > For example, if you have a /ny file on your Desktop, select "Install
> > Nyquist Plug-in", and a file browser window opens. Browse to the .ny file
> > and select it. Click the "Install" button, and the file is copied to the
> > default plug-ins folder and enabled. A message is returned saying (for
> > example):
> >
> > Plug-ins installed to "/home/steve/.audacity-files/" :
> > ACX Check
> > RMS Normalize
> > Advanced Echo
> >
> Useful, but I am not interested/motivated to write that change myself.
>

Am I correct in thinking that we have user writeable plug-in locations on
all platforms?
If so, then it may be possible to write a Nyquist Plug-in Installer, as a
Nyquist Plug-in!

That could be quite an interesting little project, I may look into that.

Steve


>
>
> > * A common problem for Mac users when downloading Nyquist plug-ins, is
> > that their computer adds ".txt" to the file name.
> > A plug-in installer could look for file names ending in ".ny.txt" and
> > offer to fix them.
> >
> +1 sounds simple and worth doing.
>
>
> > * The Plug-in Manager should remember it's window size. On Linux it
> > currently opens showing only the first 6 plug-ins.
> >
> +1 sounds simple and worth doing.
>
>
>
> > Steve
> >
> >
>
>
>
>
>
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>