audacity-manual — For discussion of the manual

Re: [Audacity-manual] TLC for Nyquist

[James C. <cr...@in...>]

On 30/01/2019 20:41, Steve the Fiddle wrote:
> On Wed, 30 Jan 2019 at 19:04, James Crook <cr...@in...> wrote:

>> 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?

Yes.


>> 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.

More like 3 balls (technologies)...

- Nyquist
- Audacity (since Nyquist can/will do stuff to Audacity datastructures)
- Pipes (at the least, be clued in to the possible need to restart Audacity)
- Python
- Some python GUI builder, like wxPython, so you can build toolbars and 
such.

There are probably still too many balls even if direct use of Nyquist 
would 'do it' :-)


> Am I correct in thinking that we have user writeable plug-in locations on
> all platforms?

I think so.  Even if we don't we could easily add the code to look in 
such a directory.


> 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.

GUI for it might be the stumbling block at this stage.  OTOH it might 
suggest/drive specs for what new GUI in Nyquist should support.

--James.

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
>

Re: [Audacity-manual] TLC for Nyquist

[James C. <cr...@in...>]

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

Fixing it gives us a worthwhile step forward soonest.



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.  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.  Explicit is not a problem as of course that can be made nicer by 
some careful preexisting nyquist functions.


> 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.

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 :-)


> 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.

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.



> 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.


> * 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
>
>

Re: [Audacity-manual] TLC for Nyquist

[Peter S. <pet...@gm...>]

On Wed, Jan 30, 2019 at 1:21 PM 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,
>

For my money the most user-unfriendly part of it is having to remember to
click the OK
as well as the Enable.

The fact that it gets moved to the Enabled list rather than staying in the
New list, or shows
as Enabled in the All list, implies to users (and I know from Forum posts
that it's not just me)
that it *is* enabled - but that does not stick until you click the OK.  If
you exit the dialog via
the top-right "X" - you lose the enabling ...



> and lacks several useful features.
>

> 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...
>

+1 to this idea

Peter.



> * Parse the names of new Nyquist plug-ins.
> 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
>
> * 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.
>
> * The Plug-in Manager should remember it's window size. On Linux it
> currently opens showing only the first 6 plug-ins.
>
> Steve
>
>
> On Wed, 30 Jan 2019 at 11:41, Peter Sampson <
> pet...@gm...> wrote:
>
>>
>>
>> On Wed, Jan 30, 2019 at 8:36 AM James Crook <cr...@in...> wrote:
>>
>>> I've been thinking recently about how Nyquist fits into Audacity and our
>>> documentation.  I think Nyquist in Audacity would benefit from some
>>> TLC.  Nyquist has recently become more important, more able to do things
>>> actually in Audacity with the addition of the tools menu and the
>>> extensions that aud-do have brought.
>>>
>>
>> Steve has been giving the Nyquist documentation a fair bit if TLC
>> recently.
>>
>> Most of this work is in the Wiki - but we have also worked on tidying the
>> 2.2.1 alpha
>> manual.
>>
>>
>> Aside: I thought we agreed we were dropping this manual mailing list in
>> favor of
>> just using quality (as we are so few in number).
>>
>> Peter.
>>
>>>
>>> What kinds of thing should happen next?  Not just new documentation, but
>>> also usability features that reduce the need to explain step-by-step -
>>> because the user interface becomes more intuitive.
>>>
>>> I'd like it to in time become much more mainstream for people to extend
>>> Audacity by adding Nyquist tools to the menu.  What needs to happen, and
>>> how should we see the priorities for that to be so?
>>>
>>> --James.
>>>
>>>
>>>
>>> _______________________________________________
>>> Audacity-manual mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>>
>>

Re: [Audacity-manual] TLC for Nyquist

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

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.

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.

* 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.

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.
>
> 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).
>
> Steve
>
> 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.
>>
>> 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.
>> 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
>>
>> * 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.
>>
>> * The Plug-in Manager should remember it's window size. On Linux it
>> currently opens showing only the first 6 plug-ins.
>>
>> Steve
>>
>>
>> On Wed, 30 Jan 2019 at 11:41, Peter Sampson <
>> pet...@gm...> wrote:
>>
>>>
>>>
>>> On Wed, Jan 30, 2019 at 8:36 AM James Crook <cr...@in...> wrote:
>>>
>>>> I've been thinking recently about how Nyquist fits into Audacity and
>>>> our
>>>> documentation.  I think Nyquist in Audacity would benefit from some
>>>> TLC.  Nyquist has recently become more important, more able to do
>>>> things
>>>> actually in Audacity with the addition of the tools menu and the
>>>> extensions that aud-do have brought.
>>>>
>>>
>>> Steve has been giving the Nyquist documentation a fair bit if TLC
>>> recently.
>>>
>>> Most of this work is in the Wiki - but we have also worked on tidying
>>> the 2.2.1 alpha
>>> manual.
>>>
>>>
>>> Aside: I thought we agreed we were dropping this manual mailing list in
>>> favor of
>>> just using quality (as we are so few in number).
>>>
>>> Peter.
>>>
>>>>
>>>> What kinds of thing should happen next?  Not just new documentation,
>>>> but
>>>> also usability features that reduce the need to explain step-by-step -
>>>> because the user interface becomes more intuitive.
>>>>
>>>> I'd like it to in time become much more mainstream for people to extend
>>>> Audacity by adding Nyquist tools to the menu.  What needs to happen,
>>>> and
>>>> how should we see the priorities for that to be so?
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Audacity-manual mailing list
>>>> Aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>>>
>>>

Re: [Audacity-manual] TLC for Nyquist

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

Another idea: An IDE for Nyquist Plug-ins. This could be included in
Audacity, or a separate app.

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).

Steve

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.
>
> 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.
> 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
>
> * 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.
>
> * The Plug-in Manager should remember it's window size. On Linux it
> currently opens showing only the first 6 plug-ins.
>
> Steve
>
>
> On Wed, 30 Jan 2019 at 11:41, Peter Sampson <
> pet...@gm...> wrote:
>
>>
>>
>> On Wed, Jan 30, 2019 at 8:36 AM James Crook <cr...@in...> wrote:
>>
>>> I've been thinking recently about how Nyquist fits into Audacity and our
>>> documentation.  I think Nyquist in Audacity would benefit from some
>>> TLC.  Nyquist has recently become more important, more able to do things
>>> actually in Audacity with the addition of the tools menu and the
>>> extensions that aud-do have brought.
>>>
>>
>> Steve has been giving the Nyquist documentation a fair bit if TLC
>> recently.
>>
>> Most of this work is in the Wiki - but we have also worked on tidying the
>> 2.2.1 alpha
>> manual.
>>
>>
>> Aside: I thought we agreed we were dropping this manual mailing list in
>> favor of
>> just using quality (as we are so few in number).
>>
>> Peter.
>>
>>>
>>> What kinds of thing should happen next?  Not just new documentation, but
>>> also usability features that reduce the need to explain step-by-step -
>>> because the user interface becomes more intuitive.
>>>
>>> I'd like it to in time become much more mainstream for people to extend
>>> Audacity by adding Nyquist tools to the menu.  What needs to happen, and
>>> how should we see the priorities for that to be so?
>>>
>>> --James.
>>>
>>>
>>>
>>> _______________________________________________
>>> Audacity-manual mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>>
>>

Re: [Audacity-manual] TLC for Nyquist

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

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.

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.
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

* 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.

* The Plug-in Manager should remember it's window size. On Linux it
currently opens showing only the first 6 plug-ins.

Steve


On Wed, 30 Jan 2019 at 11:41, Peter Sampson <pet...@gm...>
wrote:

>
>
> On Wed, Jan 30, 2019 at 8:36 AM James Crook <cr...@in...> wrote:
>
>> I've been thinking recently about how Nyquist fits into Audacity and our
>> documentation.  I think Nyquist in Audacity would benefit from some
>> TLC.  Nyquist has recently become more important, more able to do things
>> actually in Audacity with the addition of the tools menu and the
>> extensions that aud-do have brought.
>>
>
> Steve has been giving the Nyquist documentation a fair bit if TLC recently.
>
> Most of this work is in the Wiki - but we have also worked on tidying the
> 2.2.1 alpha
> manual.
>
>
> Aside: I thought we agreed we were dropping this manual mailing list in
> favor of
> just using quality (as we are so few in number).
>
> Peter.
>
>>
>> What kinds of thing should happen next?  Not just new documentation, but
>> also usability features that reduce the need to explain step-by-step -
>> because the user interface becomes more intuitive.
>>
>> I'd like it to in time become much more mainstream for people to extend
>> Audacity by adding Nyquist tools to the menu.  What needs to happen, and
>> how should we see the priorities for that to be so?
>>
>> --James.
>>
>>
>>
>> _______________________________________________
>> Audacity-manual mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>
>

Re: [Audacity-manual] TLC for Nyquist

[Peter S. <pet...@gm...>]

On Wed, Jan 30, 2019 at 8:36 AM James Crook <cr...@in...> wrote:

> I've been thinking recently about how Nyquist fits into Audacity and our
> documentation.  I think Nyquist in Audacity would benefit from some
> TLC.  Nyquist has recently become more important, more able to do things
> actually in Audacity with the addition of the tools menu and the
> extensions that aud-do have brought.
>

Steve has been giving the Nyquist documentation a fair bit if TLC recently.

Most of this work is in the Wiki - but we have also worked on tidying the
2.2.1 alpha
manual.


Aside: I thought we agreed we were dropping this manual mailing list in
favor of
just using quality (as we are so few in number).

Peter.

>
> What kinds of thing should happen next?  Not just new documentation, but
> also usability features that reduce the need to explain step-by-step -
> because the user interface becomes more intuitive.
>
> I'd like it to in time become much more mainstream for people to extend
> Audacity by adding Nyquist tools to the menu.  What needs to happen, and
> how should we see the priorities for that to be so?
>
> --James.
>
>
>
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>

[Audacity-manual] TLC for Nyquist

[James C. <cr...@in...>]

I've been thinking recently about how Nyquist fits into Audacity and our 
documentation.  I think Nyquist in Audacity would benefit from some 
TLC.  Nyquist has recently become more important, more able to do things 
actually in Audacity with the addition of the tools menu and the 
extensions that aud-do have brought.

What kinds of thing should happen next?  Not just new documentation, but 
also usability features that reduce the need to explain step-by-step - 
because the user interface becomes more intuitive.

I'd like it to in time become much more mainstream for people to extend 
Audacity by adding Nyquist tools to the menu.  What needs to happen, and 
how should we see the priorities for that to be so?

--James.

Re: [Audacity-manual] Effect menu page - OOPs, ignore

[Bill W. <bi...@go...>]

I was looking at the wrong version of the manual. The 2.3.0 manual is correct.
Sorry about the noise.
— Bill

> On 2018/09/18, at 1:11 PM, Bill Wharrie <bi...@go...> wrote:
> 
> On https://manual.audacityteam.org/man/effect_menu.html <https://manual.audacityteam.org/man/effect_menu.html>
> it appears that the menu image needs to be updated;
> - it says “Audacity” but the latest build shows “Built-in”
> - it has a “LADSPA” submenu, but since we’re shipping SC4 disabled, that submenu doesn’t show up in a virgin install.
> 
> I could live with the LADSPA submenu since SC4 is shipped but not enabled.
> 
> But showing “Audacity” instead of “Built-in” is a P1 IMO.
> 
> — Bill
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual

[Audacity-manual] Effect menu page

[Bill W. <bi...@go...>]

On https://manual.audacityteam.org/man/effect_menu.html <https://manual.audacityteam.org/man/effect_menu.html>
it appears that the menu image needs to be updated;
- it says “Audacity” but the latest build shows “Built-in”
- it has a “LADSPA” submenu, but since we’re shipping SC4 disabled, that submenu doesn’t show up in a virgin install.

I could live with the LADSPA submenu since SC4 is shipped but not enabled.

But showing “Audacity” instead of “Built-in” is a P1 IMO.

— Bill

[Audacity-manual] 2.3.0 Manual is FROZEN

[Peter S. <pet...@gm...>]

James has formally announced Code Freeze for 2.3.0 on devel

Accordingly the 2.3.0 Manual is now FROZEN

Peter.

Re: [Audacity-manual] Translation of manual?

[Peter S. <pet...@gm...>]

On Mon, Sep 17, 2018 at 12:42 PM James Crook <cr...@in...> wrote:

> At the top of our alpha manual, and therefore in our offline manual and
> static copy we say:
>
> "Translation volunteers welcome... If you'd like to help translate this
> Manual to other languages, please write to our feedback address for an
> account on this wiki."
>
> However, we know that noone translates the entire manual, an incomplete
> translation is of little use


I have noted over the years that Manual translators get all fired up for a
little
while and then fall by the wayside.

It is a a hard job to keep up with all the changes that take place (it's
hard enough
doing that in English) so I do sympathise.

and translating the Audacity UI is far more
> important.


+1

In practice we ask people who are interested in translating
> the manual to translate the FAQ, and if they have energy the tour guide
> too.
>
> A small additional problem with the current wording is that the offline
> and static version are not 'this wiki'.
>
>
> I'm proposing that:
>
> - Either we drop the line entirely.  OR
> - We change it to:
>
> "Translation volunteers welcome... If you'd like to help translate the
> most important pages of this manual into other languages, please write
> to our feedback address."
>
> I've a mild preference for dropping the call for translators of the
> manual entirely.
>

+1

I've more than a mild preference for that.

Translation of the app is much more important for my money.

What about getting them to translate WIT ?

Peter.


>
> --James.
>
>
>
>
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>

[Audacity-manual] Translation of manual?

[James C. <cr...@in...>]

At the top of our alpha manual, and therefore in our offline manual and 
static copy we say:

"Translation volunteers welcome... If you'd like to help translate this 
Manual to other languages, please write to our feedback address for an 
account on this wiki."

However, we know that noone translates the entire manual, an incomplete 
translation is of little use and translating the Audacity UI is far more 
important.  In practice we ask people who are interested in translating 
the manual to translate the FAQ, and if they have energy the tour guide 
too.

A small additional problem with the current wording is that the offline 
and static version are not 'this wiki'.


I'm proposing that:

- Either we drop the line entirely.  OR
- We change it to:

"Translation volunteers welcome... If you'd like to help translate the 
most important pages of this manual into other languages, please write 
to our feedback address."

I've a mild preference for dropping the call for translators of the 
manual entirely.


--James.

[Audacity-manual] Autogenerated screenshots

[James C. <cr...@in...>]

Auto generated screenshots:

https://wit.audacityteam.org/images.htm

These are in addition to the menus, effects dialogs, preferences, icons 
and annotated toolbars now being auto-generated.

If we have some sequence of actions, we can now get Audacity to capture 
the steps.


Some problem images shown here:
https://alphamanual.audacityteam.org/man/User:JamesCrook/Problem_Images_for_Automation

I am hoping that these will become less of a problem during 2.3.0 
development.
If we want to change cropping, drop shadows etc, that can be easily 
scripted.


--James.

[Audacity-manual] Click Hint.

[James C. <cr...@in...>]

Proposal for making the clickable image maps more discoverable:

https://alphamanual.audacityteam.org/man/User:JamesCrook/Click_Tip

Re: [Audacity-manual] The Manual is "locked"

[James C. <cr...@in...>]

I've added a new todo list for mw2html script (that converts wiki to 
local html copy).
http://wiki.audacityteam.org/wiki/Mw2html_to_do

Idea is that some time in the future when this is implemented we will be 
able to create a production manual without first changing the alpha 
designation and 'other changes' before the dump.

--James.



On 10/14/2017 4:27 PM, Peter Sampson wrote:
> On Sat, Oct 14, 2017 at 4:15 PM, Bill Wharrie <bi...@go...> wrote:
>
>> Peter:
>> It seems Paul L is ready to do another build for Mac and Windows, so the
>> “alpha” needs to go away on the front page, plus any other changes needed
>> before the dump.
>>
> I removed the alpha designation.
>
>
>> AFAICT the manual is good to go.
>>
>
> Thanks for your confirmation of that Bill - I have marked the manual as
> "Ready".
>
> Peter.
>
>
>
>> — Bill
>>
>>> On 2017/10/14, at 4:05 AM, Peter Sampson <pet...@gm...>
>> wrote:
>>> As we have just meandered into RC1 for 2.2.0 I have set the "YES"
>> indicator
>>> on the front page of the alpha Manual
>>> to indicate that the Manual is locked and that no further editing should
>>> take place.
>>>
>>> Note that this is not a hard-lock in that it does not physically inhibit
>>> edits - but it MUST be observed by editors.
>>>
>>> Thanks,
>>> Peter.
>>> ------------------------------------------------------------
>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-manual mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-manual mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual

Re: [Audacity-manual] Draft Audacity2.2.0 Manual v02

[James C. <cr...@in...>]

And now the image maps are sorted.  And I made a custom page for the 
first page just to show we can.

https://www.dropbox.com/s/qe3ec8zrxg59aaj/DraftAudacity2.2.0Manual_v04.pdf?dl=0



I am suggesting hosting it either on FossHub Audacity-devel.html or, 
since it is an experiment, on FossHub DarkAudacity.html.


--James.


On 11/17/2017 9:06 PM, James Crook wrote:
> On 11/17/2017 4:39 PM, Peter Sampson wrote:
>> Can we do something about the typeface
> Yes.
>
>> This is in Times New Roman - and although Connie doesn't (yet) 
>> explicitly
>> specify our preferred font/typeface it is certainly not Times New Roman.
>>
>> Americans may like TNR - but it tends to look old and stuffy imo.
>
> Switched to a nice new sans for v03.  It's at:
> https://www.dropbox.com/s/1lx8l779p6smmj9/DraftAudacity2.2.0Manual_v03.pdf?dl=0 
>
>
> I've also written a snag list for the pdf manual at:
> http://wiki.audacityteam.org/wiki/Bugs_In_Automation_Project
>
> I also have a prototype/proof of concept for the image maps, and just 
> (hah!) need to work it up into a full solution.  That will probably 
> take a couple of days.  I might park that for the time being to get on 
> with other parts of the automation project.
>
> --James.
>
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual

[Audacity-manual] Javascripty "What's That" page

[James C. <cr...@in...>]

I'm working on an augmented version of Bill's Awesome Image Map:
https://alphamanual.audacityteam.org/man/Main_Page


I intend to build on that idea, and produce a dynamic javascript image 
map, that acts as a kind of super index to the manual.  In particular it 
will include the menu items, and will include the alternative Transport 
Buttons that you get when you press shift.


I have started doing the interaction design.
http://wiki.audacityteam.org/wiki/Proposal_Dynamic_Imagemap_using_Javascript

Comments on the ideas are very welcome, both on the main part of the 
page and the discussion page.

This is a way for people to find their way into the manual.  It also 
should help us with producing annotated images for the manual which take 
a long time to do by hand.  This connects in with the part of the 
project to generate images for the manual, which has produced imagemaps 
for the menus and preferences.


--James.

Re: [Audacity-manual] Draft Audacity2.2.0 Manual v02

[James C. <cr...@in...>]

On 11/17/2017 4:39 PM, Peter Sampson wrote:
> Can we do something about the typeface
Yes.

> This is in Times New Roman - and although Connie doesn't (yet) explicitly
> specify our preferred font/typeface it is certainly not Times New Roman.
>
> Americans may like TNR - but it tends to look old and stuffy imo.

Switched to a nice new sans for v03.  It's at:
https://www.dropbox.com/s/1lx8l779p6smmj9/DraftAudacity2.2.0Manual_v03.pdf?dl=0

I've also written a snag list for the pdf manual at:
http://wiki.audacityteam.org/wiki/Bugs_In_Automation_Project

I also have a prototype/proof of concept for the image maps, and just 
(hah!) need to work it up into a full solution.  That will probably take 
a couple of days.  I might park that for the time being to get on with 
other parts of the automation project.

--James.

Re: [Audacity-manual] Draft Audacity2.2.0 Manual v02

[Peter S. <pet...@gm...>]

On Fri, Nov 17, 2017 at 12:47 PM, Steve the Fiddle <ste...@gm...
> wrote:

> Good work James.
> This is the best looking pdf version that I've seen to date.
> The absence of clickable image links is possibly the main shortcoming
> at the moment, but I'm sure that you'll overcome that :-)
>
> I can't imagine many users reading this cover to cover, but we do
> regularly see requests for a PDF version,



I suspect that most of those users want to print out the Manual (and good
luck to them
with 565 pages - maybe we should buy shares in paper and ink).

For those that don't print it out I struggle to see the benefit of a PDF
Manual (even with
working hyperlinks) over the installed HTML manual that s=comes with most
of our
downloads - but maybe I'm missing something.

Peter.





> and the "side pane" index is
> very handy.
>
> Steve
>
> On 17 November 2017 at 12:21, James Crook <cr...@in...> wrote:
> > Gale wanted a pdf version of the entire manual.  I have produced one,
> though
> > currently minus the front-page with its clickable image.
> >
> >
> > The main benefits of the pdf format are:
> >
> > - Table-of-contents tree that is clickable/browsable.
> > - Thumbnail browser, that gives thumbnails of all 565 pages.
> > - All in one file and more convenient for eReaders.
> >
> > I like the two column layout.  I think it works well once you get used to
> > it.  The scale of it, 565 pages, gives an idea of just how much work has
> > gone into the manual over the years!
> >
> >
> > Of course the format conversion is not perfect.  Pages with tables and
> > clickable images are not 'done' yet.  I'm probably aware of most of the
> > systematic issues with my format conversion, e.g. hyperlinks to wikipedia
> > don't work.  There are also many differences we'd probably like between
> text
> > in an html and pdf manual, which would best be handled by adapted
> templates
> > in the wiki.
> >
> >
> > A dropbox download of the draft manual to try out is here:
> >
> > https://www.dropbox.com/s/o90lz7mnv6bn9sf/DraftAudacity2.2.0Manual_v02.
> pdf?dl=0
> > (18Mb)
> >
> > We could offer this draft pdf as a download on our devel fosshub page, if
> > people think that;'s a good idea, and see how much interest there is from
> > the download figures.
> >
> > I think the main value of being able to do this conversion is for
> localised
> > sections of the manual.  The script/pipeline that automates conversion
> from
> > wiki format to pdf could be adapted to collect them.  We could in future
> > offer pdf downloads of tutorials and FAQ that have been translated.
> That is
> > a project for the future.  It involves working with the translators too.
> >
> >
> > Feedback welcome.
> >
> >
> > --James
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Audacity-manual mailing list
> > Aud...@li...
> > https://lists.sourceforge.net/lists/listinfo/audacity-manual
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>

Re: [Audacity-manual] Draft Audacity2.2.0 Manual v02

[Peter S. <pet...@gm...>]

Can we do something about the typeface

This is in Times New Roman - and although Connie doesn't (yet) explicitly
specify our preferred
font/typeface it is certainly not Times New Roman.

Americans may like TNR - but it tends to look old and stuffy imo.

Peter

On Fri, Nov 17, 2017 at 12:47 PM, Steve the Fiddle <ste...@gm...
> wrote:

> Good work James.
> This is the best looking pdf version that I've seen to date.
> The absence of clickable image links is possibly the main shortcoming
> at the moment, but I'm sure that you'll overcome that :-)
>
> I can't imagine many users reading this cover to cover, but we do
> regularly see requests for a PDF version, and the "side pane" index is
> very handy.
>
> Steve
>
> On 17 November 2017 at 12:21, James Crook <cr...@in...> wrote:
> > Gale wanted a pdf version of the entire manual.  I have produced one,
> though
> > currently minus the front-page with its clickable image.
> >
> >
> > The main benefits of the pdf format are:
> >
> > - Table-of-contents tree that is clickable/browsable.
> > - Thumbnail browser, that gives thumbnails of all 565 pages.
> > - All in one file and more convenient for eReaders.
> >
> > I like the two column layout.  I think it works well once you get used to
> > it.  The scale of it, 565 pages, gives an idea of just how much work has
> > gone into the manual over the years!
> >
> >
> > Of course the format conversion is not perfect.  Pages with tables and
> > clickable images are not 'done' yet.  I'm probably aware of most of the
> > systematic issues with my format conversion, e.g. hyperlinks to wikipedia
> > don't work.  There are also many differences we'd probably like between
> text
> > in an html and pdf manual, which would best be handled by adapted
> templates
> > in the wiki.
> >
> >
> > A dropbox download of the draft manual to try out is here:
> >
> > https://www.dropbox.com/s/o90lz7mnv6bn9sf/DraftAudacity2.2.0Manual_v02.
> pdf?dl=0
> > (18Mb)
> >
> > We could offer this draft pdf as a download on our devel fosshub page, if
> > people think that;'s a good idea, and see how much interest there is from
> > the download figures.
> >
> > I think the main value of being able to do this conversion is for
> localised
> > sections of the manual.  The script/pipeline that automates conversion
> from
> > wiki format to pdf could be adapted to collect them.  We could in future
> > offer pdf downloads of tutorials and FAQ that have been translated.
> That is
> > a project for the future.  It involves working with the translators too.
> >
> >
> > Feedback welcome.
> >
> >
> > --James
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Audacity-manual mailing list
> > Aud...@li...
> > https://lists.sourceforge.net/lists/listinfo/audacity-manual
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual
>

Re: [Audacity-manual] Draft Audacity2.2.0 Manual v02

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

Good work James.
This is the best looking pdf version that I've seen to date.
The absence of clickable image links is possibly the main shortcoming
at the moment, but I'm sure that you'll overcome that :-)

I can't imagine many users reading this cover to cover, but we do
regularly see requests for a PDF version, and the "side pane" index is
very handy.

Steve

On 17 November 2017 at 12:21, James Crook <cr...@in...> wrote:
> Gale wanted a pdf version of the entire manual.  I have produced one, though
> currently minus the front-page with its clickable image.
>
>
> The main benefits of the pdf format are:
>
> - Table-of-contents tree that is clickable/browsable.
> - Thumbnail browser, that gives thumbnails of all 565 pages.
> - All in one file and more convenient for eReaders.
>
> I like the two column layout.  I think it works well once you get used to
> it.  The scale of it, 565 pages, gives an idea of just how much work has
> gone into the manual over the years!
>
>
> Of course the format conversion is not perfect.  Pages with tables and
> clickable images are not 'done' yet.  I'm probably aware of most of the
> systematic issues with my format conversion, e.g. hyperlinks to wikipedia
> don't work.  There are also many differences we'd probably like between text
> in an html and pdf manual, which would best be handled by adapted templates
> in the wiki.
>
>
> A dropbox download of the draft manual to try out is here:
>
> https://www.dropbox.com/s/o90lz7mnv6bn9sf/DraftAudacity2.2.0Manual_v02.pdf?dl=0
> (18Mb)
>
> We could offer this draft pdf as a download on our devel fosshub page, if
> people think that;'s a good idea, and see how much interest there is from
> the download figures.
>
> I think the main value of being able to do this conversion is for localised
> sections of the manual.  The script/pipeline that automates conversion from
> wiki format to pdf could be adapted to collect them.  We could in future
> offer pdf downloads of tutorials and FAQ that have been translated.  That is
> a project for the future.  It involves working with the translators too.
>
>
> Feedback welcome.
>
>
> --James
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-manual

[Audacity-manual] Draft Audacity2.2.0 Manual v02

[James C. <cr...@in...>]

Gale wanted a pdf version of the entire manual.  I have produced one, 
though currently minus the front-page with its clickable image.


The main benefits of the pdf format are:

- Table-of-contents tree that is clickable/browsable.
- Thumbnail browser, that gives thumbnails of all 565 pages.
- All in one file and more convenient for eReaders.

I like the two column layout.  I think it works well once you get used 
to it.  The scale of it, 565 pages, gives an idea of just how much work 
has gone into the manual over the years!


Of course the format conversion is not perfect.  Pages with tables and 
clickable images are not 'done' yet.  I'm probably aware of most of the 
systematic issues with my format conversion, e.g. hyperlinks to 
wikipedia don't work.  There are also many differences we'd probably 
like between text in an html and pdf manual, which would best be handled 
by adapted templates in the wiki.


A dropbox download of the draft manual to try out is here:

https://www.dropbox.com/s/o90lz7mnv6bn9sf/DraftAudacity2.2.0Manual_v02.pdf?dl=0 
(18Mb)

We could offer this draft pdf as a download on our devel fosshub page, 
if people think that;'s a good idea, and see how much interest there is 
from the download figures.

I think the main value of being able to do this conversion is for 
localised sections of the manual.  The script/pipeline that automates 
conversion from wiki format to pdf could be adapted to collect them.  We 
could in future offer pdf downloads of tutorials and FAQ that have been 
translated.  That is a project for the future.  It involves working with 
the translators too.


Feedback welcome.


--James

[Audacity-manual] Broken link to the manual ZIP package

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

On this page: http://manual.audacityteam.org/man/unzipping_the_manual.html

This is a broken link:

Download the zipped Manual by left-clicking this link
http://www.fosshub.com/Audacity.html/audacity-manual-2.1.3.zip.

I presume that we can't do anything about that in the 2.2.0 manual.
For the 2.2.1 manual I suggest that we change it to a link to the
FossHub page rather than directly to the manual:

Download the zipped manual by left clicking the relevant link on this
page: https://www.fosshub.com/Audacity.html

That will be one less thing to remember at release time.


Steve