Nyquist Workbench for Nightly builds

Programming and Development Nyquist
1

I am a regular user of Nyquist Workbench on Linux, and although it may not yet be considered to be “release ready” I find it very useful.
Setting up a build environment on Windows (or Mac OS X?) is far from trivial, (and certainly not an option on someone else’s computer).

  1. Nightly builds are “use at your own risk” alpha versions and not “release versions”.
  2. There is currently no “release build” of Nyquist Workbench.

Until such time as Nyquist Workbench is available as an official release, I’d like there to be an optional download of Nyquist Workbench built against nightly versions. This would make Nyquist Workbench available to people for whom setting up a build environment is not an option without implying that it is of release quality.

2

I believe the rule was made that users who want modules that are not release-ready (that is, all of them at the moment) have to compile them (and of course Audacity) themselves. That was why modules were pulled from releases, and the “nightly builds” reflect that.

If you want to overturn that rule you will need to post on -devel.


Gale

3

xfrd here from FRs page

Peter

4

I am anxciously waiting for a release where the python module is enabled too. If we were able to build up a pipe from XLISP to that module, we would have the interface between Audacity’s functionality and that one of Nyquist.
This could be a powerful expansion or alternative to the earlier proposed property list for the sound variable within Nyquist.
Furthermore, the free Screen reader NVDA uses Python too, thus, better accessibility support would be possible.

5

Am I correct this is nothing directly to do with Nyquist Workbench?

If so I think we should split the above post and my reply back to the Feature Request board so we can count the vote for it, and also mention it on the “Nyquist Wish List” if others think it is a good idea.


Gale

6

I’ve only mentioned the python module because it has been introduced at the same time as the nyquist workbench module i.e. it requires a similar Audacity building and compiling procedure to enable those modules.

7

Do you mean “mod-script-pipe”?
I think that is more intended for perl rather than Python. The included test script is a perl script.

8

Sorry, it is of course perl.
However, the scripting commands could still be a huge improvement for Nyquist. Here’s the link to the scripting page:
http://manual.audacityteam.org/man/Scripting

On the page one can read:

script. Commands are sent to Audacity over a named pipe. Any scripting language that supports named pipes can be used in place of Perl.

The 60,000 $ question is if such a pipe could be implemented within XLISP.

But that’s a question for another topic. I’d rather be interested which advantages the nyquist workbench can provide for us as developers. It would be nice if Steve could pass on some of his experiences to us.

9

Robert,

I’ll add your vote that you’d like Audacity to progress on releasing the mod-script-pipe scripting module (a number of people have asked for this now that http://manual.audacityteam.org/man/Scripting is clearer about the feature) and also on releasing nyquist workbench.

I’m not clear though why you don’t just compile Audacity and the modules yourself. What operating system are you on? Mac is difficult to compile Audacity on, especially if you are on Snow Leopard or later.


Gale

10

After a lot of faffing and countless crashing - yes it is possible to use mod-script-pipe from within Nyquist, but you need an external script running to receive the returned messages. Then commands can be sent by using something like:

(setq wpipe (open "/tmp/audacity_script_pipe.to.1000" :direction :output))

; send a command
(format wpipe "SetTrackInfo: TrackIndex=0 Type=Name Name=Test_trackn")

(print "Done")
11

I presume that it would be relatively easy for Audacity to include a “null sink” for the returned messages.

12

Could we have Nyquist support added into that feature request?

13

I am most certainly for the mod pipe advancement, as long as it is also an integral part of Nyquist. It’s terrific that Steve has already made some deeper research and experimenting. It seems to look promising although the project is far from beeing mature.
An internal pipe within Nyquist should us enable to implement a lot of points from the wishlist. The mechanism would allow us to develop these ideas within an ordinary XLISP library.

I am afraid my views are somewhat enthusiastic for the time being, but sobriety will soon enough regain the better of me, I guess.
I could of course build Audacity myself (Windows 7 64-Bit), but I am somewhat fed up with doing it over and over again. It is hard enough to do it with the normal releases just to have the ASIO drivers built up as well. After all, I am only a fledgling in the realms of programming.

14

If you’ve done it once then you’ve done the hard part. Once the build environment is set up building should be pretty straightforward.
Having said that, there is a new feature being developed in SVN that may complicate the build for a while.

I think that you will enjoy playing with mod-script-pipe because it can do a lot of stuff that is (currently) impossible in Nyquist.
I think that if you go back to revision 11985 then it should build OK and already be configured for mod-script-pipe support.

You may not want to install the mod-script-pipe version for standard use as it has some bugs and security issues that are not present in the release version.
You can run this special build as a “portable” (not installed) version by creating a Portable Settings folder (see: http://manual.audacityteam.org/o/man/preferences.html#stored )

15

I don’t know how accessible Nyquist Workbench is - I don’t have a screen reader installed and Audacity accessibility is badly broken on Linux :frowning:
If you build Nyquist Workbench then next time that you build Audacity, perhaps you could tell us.

This is not a full description, but highlights most of the main features of the Nyquist Workbench.

Nyquist Workbench provides a graphical environment for writing Nyquist plug-ins. I believe that it was originally written just as a demonstration / proof of concept for Audacity modules, but nevertheless I find it to be a useful tool.

The interface consists of two panels. By default they are side by side, though I prefer to use them one above the other (View > Split Horizontally).
The first panel is for the Nyquist code. The second is for debug output. Both panels are resizeable, which is a significant improvement over the small and non-resizeable window in the Nyquist Prompt effect.

The Workbench interface is a modeless window, so it can remain open while doing other things in Audacity.

Generate, Process and Analyze type plug-ins are supported. The plug-in type is set by adding the usual ;type header at the top of the code. The default type is “generate”.
As with Nyquist plug-ins, the “S” parameter only contains the selected audio data when the plug-in type is set to process or analyze.

The workbench menu bar provides the usual “New, Open, Save, Save As” options.
There are also "Copy to clipboard, Cut to Clipboard, Paste from Clipboard and “Select All Text” options to provide convenient exchange of text between the workbench and other editors.

The final two buttons on the menu bar are for running and stopping scripts (“Start Script” and “Stop Script” respectively).
Pressing the Start Script button will attempt to execute the code in the Code panel. If the code includes the necessary headers for a plug-in GUI then the GUI is created and the full graphical plug-in window pops up like any installed plug-in.

The Stop button can be useful for escaping from an improperly designed loop structure that might otherwise be endless, though this should not be relied on as a fast code loop may not allow time for Workbench to be able to interrupt the loop. It can also be useful for stopping code that will otherwise take too long.

Just as Nyquist plug-ins display standard-output in the debug window, the Workbench prints standard-output in the “Output” window. This output is in real time as the code is running. The output window can be cleared using the “Clear Selection” button in the menu bar.

When the plug-in is complete and tested, it can be saved to the Audacity Plug-ins folder (providing that you have write permissions). The plug-in will then be installed when Audacity is restarted.

Additional features include:

  • Parentheses matching
  • Go to matching parentheses
  • Go to top / higher / previous / next S-expression
  • Revert to saved
  • Autoload last file when launched
  • Search

Bugs:

  • Selected font does not stick
  • Selected text may be same colour as highlight
  • Pasted text may be red instead of black if replacing a currently matched bracket
  • CR/LF are not converted to native format when pasting text
  • Stop Script button may not be able to stop a script
  • Audacity keyboard shortcuts may stop working until Audacity Preferences are opened and closed
  • Audacity plug-in menus are pushed out of order by the name of the current workbench effect

Feature Requests:

  • 2 space tabs
  • Syntax highlighting
  • Auto-complete option
  • Plug-in header template
  • Snippet library support
  • Lisp indentation rules
  • Help menu links to Nyquist and XLisp manuals
  • keyword lookup in Nyquist and XLisp manuals
16

Thank you Steve for the insight.

The workbench is surely a good thing for sighted people. I do not know yet if this also is the case for us vi-p’s. Sometimes it offers some advantages to use a screen reader and keyboard shortcuts only.
I am quite happy with the Nyquist prompt. The window size is of no consequence with a screen reader. The same applies to the debug window.
What I miss are the blockwise indentation and the parenthesis matching or to jump to the corresponding parenthesis.
To create and edit the plug-in files I usually use notepad++, although only Lisp itself is provided under the languages’ menu. For a fast look up of functions I use my labouriously assembled Helper tool.
Nyquist Reference in a nut shell
If I have the right mood and if I can overcome my inner “Schweinehund”, I will give the mods a try.

17

I’ll add that to the list of “feature requests” in my previous post.

You may find the “Go to” features helpful. They should be accessible via the F8 to F12 keys, unless you have them globally associated with another program.

18

OK, It seems like it’s two votes for that including Robert’s vote.


Gale