Quantcast

Changed Property in Nyquist

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Changed Property in Nyquist

Robert Hänggi
Hi

Recently, a property entry of *system-dir* has changed.
Normally, one could get all plug-in locations in Nyquist with the command:
(get '*system-dir* 'plugin)
It has been changed to 'plug-in.

Although I understand the reason, plug-ins that use this information
won't be backwards compatible.

I'm just creating a suite of 14 accessibility plug-ins and was
somewhat surprised that they don't work anymore after a GIT pull...

Please inform if I have from now on to search for both writing variants.

Thanks
Robert

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle
The documentation dated May 2015
(http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
says it should be hyphenated "plug-in", which is in line with policy
on consistency as set out on the wiki
(http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).

I'm glad you brought this up as I see there are places where the
documentation has been incorrectly updated at various times and
contradicts itself. Unless there has been another change of mind, I'll
go through and update as necessary over the next couple of days.

My understanding is that it has been agreed that we consistently use
the hyphenated form of "plug-in".

Due to the number of old plug-in in the wild, both the hyphenated and
non-hyphenated forms are currently supported in the header ";nyquist
plug-in".

Sorry about the inconvenience Robert.

Steve

On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]> wrote:

> Hi
>
> Recently, a property entry of *system-dir* has changed.
> Normally, one could get all plug-in locations in Nyquist with the command:
> (get '*system-dir* 'plugin)
> It has been changed to 'plug-in.
>
> Although I understand the reason, plug-ins that use this information
> won't be backwards compatible.
>
> I'm just creating a suite of 14 accessibility plug-ins and was
> somewhat surprised that they don't work anymore after a GIT pull...
>
> Please inform if I have from now on to search for both writing variants.
>
> Thanks
> Robert
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
Yes, very inconvenient, more so as other names has changed as well,
like 'peak-level' to 'peak'.
It means that all my plug-ins (that use properties) have to include a
version query.

That's harder than it seems.
The only satisfying solution so far is:
; test for version greater equals 2.1.3
(print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1 3)))))

Do you have a simpler solution?

I'm not so sure that  documentation/manual recommendations should have
such an impact on pure LISP syntax, especially when the tendency goes
towards "plugins" as in Steinberg's "VST Plugins" folder.
But if you must change, make it "plug-ins" and not "plug-in".

I like the additions, such as RMS.
If possible, I would also like to see:
- '*track* --> orientation Left Right Mono.
- '*project* --> zoom (i.e. step size for arrow key movement at
current zoom factor).

Well, there are others... ;)

Thanks for keeping Nyquist rocking.

Robert

2017-02-27 14:22 GMT+01:00, Steve the Fiddle <[hidden email]>:

> The documentation dated May 2015
> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
> says it should be hyphenated "plug-in", which is in line with policy
> on consistency as set out on the wiki
> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>
> I'm glad you brought this up as I see there are places where the
> documentation has been incorrectly updated at various times and
> contradicts itself. Unless there has been another change of mind, I'll
> go through and update as necessary over the next couple of days.
>
> My understanding is that it has been agreed that we consistently use
> the hyphenated form of "plug-in".
>
> Due to the number of old plug-in in the wild, both the hyphenated and
> non-hyphenated forms are currently supported in the header ";nyquist
> plug-in".
>
> Sorry about the inconvenience Robert.
>
> Steve
>
> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]> wrote:
>> Hi
>>
>> Recently, a property entry of *system-dir* has changed.
>> Normally, one could get all plug-in locations in Nyquist with the command:
>> (get '*system-dir* 'plugin)
>> It has been changed to 'plug-in.
>>
>> Although I understand the reason, plug-ins that use this information
>> won't be backwards compatible.
>>
>> I'm just creating a suite of 14 accessibility plug-ins and was
>> somewhat surprised that they don't work anymore after a GIT pull...
>>
>> Please inform if I have from now on to search for both writing variants.
>>
>> Thanks
>> Robert
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle
On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]> wrote:

> Yes, very inconvenient, more so as other names has changed as well,
> like 'peak-level' to 'peak'.
> It means that all my plug-ins (that use properties) have to include a
> version query.
>
> That's harder than it seems.
> The only satisfying solution so far is:
> ; test for version greater equals 2.1.3
> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1 3)))))
>
> Do you have a simpler solution?

I think that test will fail if the next version is called Audacity 2.2.0.

If you try to "Get" a property value that does not exist, it will return "NIL".
So, if for example, we add a new property list item part way through
the 2.1.4 development cycle, you can start using it straight away
provided that you handle to possibility of the property not being
available in some versions of Audacity.

For example:

(if (not (setf rms (get '*selection* 'rms)))
    (throw 'err "Audacity version not supported"))

or of course you could provide a legacy function to calculate the RMS.

>
> I'm not so sure that  documentation/manual recommendations should have
> such an impact on pure LISP syntax, especially when the tendency goes
> towards "plugins" as in Steinberg's "VST Plugins" folder.
> But if you must change, make it "plug-ins" and not "plug-in".

Well this is the problem. We are currently in freeze so any changes
have to go through the release manager.
We could discuss the comparative merits of singular or plural, but a
decision needs to be made. If we put off making that decision, the
greater the likelihood of breaking user's custom plug-ins. It would be
'possible' to allow multiple versions, say "plugin" or "plugins" or
"plug-in" or "plug-ins", but that soon gets messy. I think we need to
take that approach for syntax that has been around for a long time,
such as using "real" for slider widgets that take float values, but
generally it's much cleaner to have just one "correct" syntax.

I don't want to be incrementing the Nyquist plug-in version number
with every release, because each time we increment the version number
requires adding conditionals in Audacity to determine how to correctly
parse the code. On the other hand, I don't think it's practical to
wait until we have a frozen specification before we make new features
available.

Clearly we do want to keep changes to existing syntax to a minimum,
but I think we need to accept that new additions may be subject to
change.


>
> I like the additions, such as RMS.
> If possible, I would also like to see:
> - '*track* --> orientation Left Right Mono.

Although we've had track channel allocation in this way for a long
time, I'm uncertain how much longer we will use it. For left/right,
all we really need is "pan". For multi-channel sound we need more
flexible channel allocation. I think it's quite possible that track
channel allocation could change, and we wouldn't want to introduce
this new property now for it to then be obsolete in a release or two.

> - '*project* --> zoom (i.e. step size for arrow key movement at
> current zoom factor).

I don't know how or if that would work with Paul's proposed "Fish Eye"
view, so perhaps best to hold off that for now,

>
> Well, there are others... ;)

Let's discus on the Nyquist forum board. The property lists can
certainly be extended.

Steve

>
> Thanks for keeping Nyquist rocking.
>
> Robert
>
> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> The documentation dated May 2015
>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>> says it should be hyphenated "plug-in", which is in line with policy
>> on consistency as set out on the wiki
>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>
>> I'm glad you brought this up as I see there are places where the
>> documentation has been incorrectly updated at various times and
>> contradicts itself. Unless there has been another change of mind, I'll
>> go through and update as necessary over the next couple of days.
>>
>> My understanding is that it has been agreed that we consistently use
>> the hyphenated form of "plug-in".
>>
>> Due to the number of old plug-in in the wild, both the hyphenated and
>> non-hyphenated forms are currently supported in the header ";nyquist
>> plug-in".
>>
>> Sorry about the inconvenience Robert.
>>
>> Steve
>>
>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]> wrote:
>>> Hi
>>>
>>> Recently, a property entry of *system-dir* has changed.
>>> Normally, one could get all plug-in locations in Nyquist with the command:
>>> (get '*system-dir* 'plugin)
>>> It has been changed to 'plug-in.
>>>
>>> Although I understand the reason, plug-ins that use this information
>>> won't be backwards compatible.
>>>
>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>
>>> Please inform if I have from now on to search for both writing variants.
>>>
>>> Thanks
>>> Robert
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
I thought it would be logical to name the folder locations 'plug-ins'
since the folders themselves are all plural.

Regarding channel allocation, we could consider calling them "Front
Left", "Front Center" etc.
This should be compatible with multi channel definition in the long run.
Although no actual naming convention exists that I would be aware of.

Robert

2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]>:

> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]> wrote:
>> Yes, very inconvenient, more so as other names has changed as well,
>> like 'peak-level' to 'peak'.
>> It means that all my plug-ins (that use properties) have to include a
>> version query.
>>
>> That's harder than it seems.
>> The only satisfying solution so far is:
>> ; test for version greater equals 2.1.3
>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1
>> 3)))))
>>
>> Do you have a simpler solution?
>
> I think that test will fail if the next version is called Audacity 2.2.0.
>
> If you try to "Get" a property value that does not exist, it will return
> "NIL".
> So, if for example, we add a new property list item part way through
> the 2.1.4 development cycle, you can start using it straight away
> provided that you handle to possibility of the property not being
> available in some versions of Audacity.
>
> For example:
>
> (if (not (setf rms (get '*selection* 'rms)))
>     (throw 'err "Audacity version not supported"))
>
> or of course you could provide a legacy function to calculate the RMS.
>
>>
>> I'm not so sure that  documentation/manual recommendations should have
>> such an impact on pure LISP syntax, especially when the tendency goes
>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> But if you must change, make it "plug-ins" and not "plug-in".
>
> Well this is the problem. We are currently in freeze so any changes
> have to go through the release manager.
> We could discuss the comparative merits of singular or plural, but a
> decision needs to be made. If we put off making that decision, the
> greater the likelihood of breaking user's custom plug-ins. It would be
> 'possible' to allow multiple versions, say "plugin" or "plugins" or
> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
> take that approach for syntax that has been around for a long time,
> such as using "real" for slider widgets that take float values, but
> generally it's much cleaner to have just one "correct" syntax.
>
> I don't want to be incrementing the Nyquist plug-in version number
> with every release, because each time we increment the version number
> requires adding conditionals in Audacity to determine how to correctly
> parse the code. On the other hand, I don't think it's practical to
> wait until we have a frozen specification before we make new features
> available.
>
> Clearly we do want to keep changes to existing syntax to a minimum,
> but I think we need to accept that new additions may be subject to
> change.
>
>
>>
>> I like the additions, such as RMS.
>> If possible, I would also like to see:
>> - '*track* --> orientation Left Right Mono.
>
> Although we've had track channel allocation in this way for a long
> time, I'm uncertain how much longer we will use it. For left/right,
> all we really need is "pan". For multi-channel sound we need more
> flexible channel allocation. I think it's quite possible that track
> channel allocation could change, and we wouldn't want to introduce
> this new property now for it to then be obsolete in a release or two.
>
>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> current zoom factor).
>
> I don't know how or if that would work with Paul's proposed "Fish Eye"
> view, so perhaps best to hold off that for now,
>
>>
>> Well, there are others... ;)
>
> Let's discus on the Nyquist forum board. The property lists can
> certainly be extended.
>
> Steve
>
>>
>> Thanks for keeping Nyquist rocking.
>>
>> Robert
>>
>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>> The documentation dated May 2015
>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>>> says it should be hyphenated "plug-in", which is in line with policy
>>> on consistency as set out on the wiki
>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>>
>>> I'm glad you brought this up as I see there are places where the
>>> documentation has been incorrectly updated at various times and
>>> contradicts itself. Unless there has been another change of mind, I'll
>>> go through and update as necessary over the next couple of days.
>>>
>>> My understanding is that it has been agreed that we consistently use
>>> the hyphenated form of "plug-in".
>>>
>>> Due to the number of old plug-in in the wild, both the hyphenated and
>>> non-hyphenated forms are currently supported in the header ";nyquist
>>> plug-in".
>>>
>>> Sorry about the inconvenience Robert.
>>>
>>> Steve
>>>
>>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]>
>>> wrote:
>>>> Hi
>>>>
>>>> Recently, a property entry of *system-dir* has changed.
>>>> Normally, one could get all plug-in locations in Nyquist with the
>>>> command:
>>>> (get '*system-dir* 'plugin)
>>>> It has been changed to 'plug-in.
>>>>
>>>> Although I understand the reason, plug-ins that use this information
>>>> won't be backwards compatible.
>>>>
>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>>
>>>> Please inform if I have from now on to search for both writing variants.
>>>>
>>>> Thanks
>>>> Robert
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle
On 27 February 2017 at 16:48, Robert Hänggi <[hidden email]> wrote:
> I thought it would be logical to name the folder locations 'plug-ins'
> since the folders themselves are all plural.

I get your point Robert, but on the other hand, the other "system-dir*
property lists are all singular terms:
base, data, help and temp.

"Plug-in" does NOT refer to the name of the directories in this
context. Although most of these directories are called "plug-ins" some
have other names, such as "plugin" and "nyquist".

Steve

>
> Regarding channel allocation, we could consider calling them "Front
> Left", "Front Center" etc.
> This should be compatible with multi channel definition in the long run.
> Although no actual naming convention exists that I would be aware of.
>
> Robert
>
> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]> wrote:
>>> Yes, very inconvenient, more so as other names has changed as well,
>>> like 'peak-level' to 'peak'.
>>> It means that all my plug-ins (that use properties) have to include a
>>> version query.
>>>
>>> That's harder than it seems.
>>> The only satisfying solution so far is:
>>> ; test for version greater equals 2.1.3
>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1
>>> 3)))))
>>>
>>> Do you have a simpler solution?
>>
>> I think that test will fail if the next version is called Audacity 2.2.0.
>>
>> If you try to "Get" a property value that does not exist, it will return
>> "NIL".
>> So, if for example, we add a new property list item part way through
>> the 2.1.4 development cycle, you can start using it straight away
>> provided that you handle to possibility of the property not being
>> available in some versions of Audacity.
>>
>> For example:
>>
>> (if (not (setf rms (get '*selection* 'rms)))
>>     (throw 'err "Audacity version not supported"))
>>
>> or of course you could provide a legacy function to calculate the RMS.
>>
>>>
>>> I'm not so sure that  documentation/manual recommendations should have
>>> such an impact on pure LISP syntax, especially when the tendency goes
>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>>> But if you must change, make it "plug-ins" and not "plug-in".
>>
>> Well this is the problem. We are currently in freeze so any changes
>> have to go through the release manager.
>> We could discuss the comparative merits of singular or plural, but a
>> decision needs to be made. If we put off making that decision, the
>> greater the likelihood of breaking user's custom plug-ins. It would be
>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>> take that approach for syntax that has been around for a long time,
>> such as using "real" for slider widgets that take float values, but
>> generally it's much cleaner to have just one "correct" syntax.
>>
>> I don't want to be incrementing the Nyquist plug-in version number
>> with every release, because each time we increment the version number
>> requires adding conditionals in Audacity to determine how to correctly
>> parse the code. On the other hand, I don't think it's practical to
>> wait until we have a frozen specification before we make new features
>> available.
>>
>> Clearly we do want to keep changes to existing syntax to a minimum,
>> but I think we need to accept that new additions may be subject to
>> change.
>>
>>
>>>
>>> I like the additions, such as RMS.
>>> If possible, I would also like to see:
>>> - '*track* --> orientation Left Right Mono.
>>
>> Although we've had track channel allocation in this way for a long
>> time, I'm uncertain how much longer we will use it. For left/right,
>> all we really need is "pan". For multi-channel sound we need more
>> flexible channel allocation. I think it's quite possible that track
>> channel allocation could change, and we wouldn't want to introduce
>> this new property now for it to then be obsolete in a release or two.
>>
>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>>> current zoom factor).
>>
>> I don't know how or if that would work with Paul's proposed "Fish Eye"
>> view, so perhaps best to hold off that for now,
>>
>>>
>>> Well, there are others... ;)
>>
>> Let's discus on the Nyquist forum board. The property lists can
>> certainly be extended.
>>
>> Steve
>>
>>>
>>> Thanks for keeping Nyquist rocking.
>>>
>>> Robert
>>>
>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>>> The documentation dated May 2015
>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>>>> says it should be hyphenated "plug-in", which is in line with policy
>>>> on consistency as set out on the wiki
>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>>>
>>>> I'm glad you brought this up as I see there are places where the
>>>> documentation has been incorrectly updated at various times and
>>>> contradicts itself. Unless there has been another change of mind, I'll
>>>> go through and update as necessary over the next couple of days.
>>>>
>>>> My understanding is that it has been agreed that we consistently use
>>>> the hyphenated form of "plug-in".
>>>>
>>>> Due to the number of old plug-in in the wild, both the hyphenated and
>>>> non-hyphenated forms are currently supported in the header ";nyquist
>>>> plug-in".
>>>>
>>>> Sorry about the inconvenience Robert.
>>>>
>>>> Steve
>>>>
>>>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]>
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> Recently, a property entry of *system-dir* has changed.
>>>>> Normally, one could get all plug-in locations in Nyquist with the
>>>>> command:
>>>>> (get '*system-dir* 'plugin)
>>>>> It has been changed to 'plug-in.
>>>>>
>>>>> Although I understand the reason, plug-ins that use this information
>>>>> won't be backwards compatible.
>>>>>
>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>>>
>>>>> Please inform if I have from now on to search for both writing variants.
>>>>>
>>>>> Thanks
>>>>> Robert
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
In reply to this post by Robert Hänggi
Thanks for pointing out the floor with the version check.

It is probably better to use something like

(print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version) '(100 10 1)))))

provided that the second and third numbers won't ever be greater nine... ;)
Robert

2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:

> I thought it would be logical to name the folder locations 'plug-ins'
> since the folders themselves are all plural.
>
> Regarding channel allocation, we could consider calling them "Front
> Left", "Front Center" etc.
> This should be compatible with multi channel definition in the long run.
> Although no actual naming convention exists that I would be aware of.
>
> Robert
>
> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]>
>> wrote:
>>> Yes, very inconvenient, more so as other names has changed as well,
>>> like 'peak-level' to 'peak'.
>>> It means that all my plug-ins (that use properties) have to include a
>>> version query.
>>>
>>> That's harder than it seems.
>>> The only satisfying solution so far is:
>>> ; test for version greater equals 2.1.3
>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1
>>> 3)))))
>>>
>>> Do you have a simpler solution?
>>
>> I think that test will fail if the next version is called Audacity 2.2.0.
>>
>> If you try to "Get" a property value that does not exist, it will return
>> "NIL".
>> So, if for example, we add a new property list item part way through
>> the 2.1.4 development cycle, you can start using it straight away
>> provided that you handle to possibility of the property not being
>> available in some versions of Audacity.
>>
>> For example:
>>
>> (if (not (setf rms (get '*selection* 'rms)))
>>     (throw 'err "Audacity version not supported"))
>>
>> or of course you could provide a legacy function to calculate the RMS.
>>
>>>
>>> I'm not so sure that  documentation/manual recommendations should have
>>> such an impact on pure LISP syntax, especially when the tendency goes
>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>>> But if you must change, make it "plug-ins" and not "plug-in".
>>
>> Well this is the problem. We are currently in freeze so any changes
>> have to go through the release manager.
>> We could discuss the comparative merits of singular or plural, but a
>> decision needs to be made. If we put off making that decision, the
>> greater the likelihood of breaking user's custom plug-ins. It would be
>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>> take that approach for syntax that has been around for a long time,
>> such as using "real" for slider widgets that take float values, but
>> generally it's much cleaner to have just one "correct" syntax.
>>
>> I don't want to be incrementing the Nyquist plug-in version number
>> with every release, because each time we increment the version number
>> requires adding conditionals in Audacity to determine how to correctly
>> parse the code. On the other hand, I don't think it's practical to
>> wait until we have a frozen specification before we make new features
>> available.
>>
>> Clearly we do want to keep changes to existing syntax to a minimum,
>> but I think we need to accept that new additions may be subject to
>> change.
>>
>>
>>>
>>> I like the additions, such as RMS.
>>> If possible, I would also like to see:
>>> - '*track* --> orientation Left Right Mono.
>>
>> Although we've had track channel allocation in this way for a long
>> time, I'm uncertain how much longer we will use it. For left/right,
>> all we really need is "pan". For multi-channel sound we need more
>> flexible channel allocation. I think it's quite possible that track
>> channel allocation could change, and we wouldn't want to introduce
>> this new property now for it to then be obsolete in a release or two.
>>
>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>>> current zoom factor).
>>
>> I don't know how or if that would work with Paul's proposed "Fish Eye"
>> view, so perhaps best to hold off that for now,
>>
>>>
>>> Well, there are others... ;)
>>
>> Let's discus on the Nyquist forum board. The property lists can
>> certainly be extended.
>>
>> Steve
>>
>>>
>>> Thanks for keeping Nyquist rocking.
>>>
>>> Robert
>>>
>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>>> The documentation dated May 2015
>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>>>> says it should be hyphenated "plug-in", which is in line with policy
>>>> on consistency as set out on the wiki
>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>>>
>>>> I'm glad you brought this up as I see there are places where the
>>>> documentation has been incorrectly updated at various times and
>>>> contradicts itself. Unless there has been another change of mind, I'll
>>>> go through and update as necessary over the next couple of days.
>>>>
>>>> My understanding is that it has been agreed that we consistently use
>>>> the hyphenated form of "plug-in".
>>>>
>>>> Due to the number of old plug-in in the wild, both the hyphenated and
>>>> non-hyphenated forms are currently supported in the header ";nyquist
>>>> plug-in".
>>>>
>>>> Sorry about the inconvenience Robert.
>>>>
>>>> Steve
>>>>
>>>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]>
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> Recently, a property entry of *system-dir* has changed.
>>>>> Normally, one could get all plug-in locations in Nyquist with the
>>>>> command:
>>>>> (get '*system-dir* 'plugin)
>>>>> It has been changed to 'plug-in.
>>>>>
>>>>> Although I understand the reason, plug-ins that use this information
>>>>> won't be backwards compatible.
>>>>>
>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>>>
>>>>> Please inform if I have from now on to search for both writing
>>>>> variants.
>>>>>
>>>>> Thanks
>>>>> Robert
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
Apropos inconsistency:
'peak returns a single value for stereo tracks whereas 'rms returns an
array of two values.

Robert

2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:

> Thanks for pointing out the floor with the version check.
>
> It is probably better to use something like
>
> (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version) '(100 10
> 1)))))
>
> provided that the second and third numbers won't ever be greater nine... ;)
> Robert
>
> 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> I thought it would be logical to name the folder locations 'plug-ins'
>> since the folders themselves are all plural.
>>
>> Regarding channel allocation, we could consider calling them "Front
>> Left", "Front Center" etc.
>> This should be compatible with multi channel definition in the long run.
>> Although no actual naming convention exists that I would be aware of.
>>
>> Robert
>>
>> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]>
>>> wrote:
>>>> Yes, very inconvenient, more so as other names has changed as well,
>>>> like 'peak-level' to 'peak'.
>>>> It means that all my plug-ins (that use properties) have to include a
>>>> version query.
>>>>
>>>> That's harder than it seems.
>>>> The only satisfying solution so far is:
>>>> ; test for version greater equals 2.1.3
>>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1
>>>> 3)))))
>>>>
>>>> Do you have a simpler solution?
>>>
>>> I think that test will fail if the next version is called Audacity
>>> 2.2.0.
>>>
>>> If you try to "Get" a property value that does not exist, it will return
>>> "NIL".
>>> So, if for example, we add a new property list item part way through
>>> the 2.1.4 development cycle, you can start using it straight away
>>> provided that you handle to possibility of the property not being
>>> available in some versions of Audacity.
>>>
>>> For example:
>>>
>>> (if (not (setf rms (get '*selection* 'rms)))
>>>     (throw 'err "Audacity version not supported"))
>>>
>>> or of course you could provide a legacy function to calculate the RMS.
>>>
>>>>
>>>> I'm not so sure that  documentation/manual recommendations should have
>>>> such an impact on pure LISP syntax, especially when the tendency goes
>>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>>>> But if you must change, make it "plug-ins" and not "plug-in".
>>>
>>> Well this is the problem. We are currently in freeze so any changes
>>> have to go through the release manager.
>>> We could discuss the comparative merits of singular or plural, but a
>>> decision needs to be made. If we put off making that decision, the
>>> greater the likelihood of breaking user's custom plug-ins. It would be
>>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>>> take that approach for syntax that has been around for a long time,
>>> such as using "real" for slider widgets that take float values, but
>>> generally it's much cleaner to have just one "correct" syntax.
>>>
>>> I don't want to be incrementing the Nyquist plug-in version number
>>> with every release, because each time we increment the version number
>>> requires adding conditionals in Audacity to determine how to correctly
>>> parse the code. On the other hand, I don't think it's practical to
>>> wait until we have a frozen specification before we make new features
>>> available.
>>>
>>> Clearly we do want to keep changes to existing syntax to a minimum,
>>> but I think we need to accept that new additions may be subject to
>>> change.
>>>
>>>
>>>>
>>>> I like the additions, such as RMS.
>>>> If possible, I would also like to see:
>>>> - '*track* --> orientation Left Right Mono.
>>>
>>> Although we've had track channel allocation in this way for a long
>>> time, I'm uncertain how much longer we will use it. For left/right,
>>> all we really need is "pan". For multi-channel sound we need more
>>> flexible channel allocation. I think it's quite possible that track
>>> channel allocation could change, and we wouldn't want to introduce
>>> this new property now for it to then be obsolete in a release or two.
>>>
>>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>>>> current zoom factor).
>>>
>>> I don't know how or if that would work with Paul's proposed "Fish Eye"
>>> view, so perhaps best to hold off that for now,
>>>
>>>>
>>>> Well, there are others... ;)
>>>
>>> Let's discus on the Nyquist forum board. The property lists can
>>> certainly be extended.
>>>
>>> Steve
>>>
>>>>
>>>> Thanks for keeping Nyquist rocking.
>>>>
>>>> Robert
>>>>
>>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>>>> <[hidden email]>:
>>>>> The documentation dated May 2015
>>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>>>>> says it should be hyphenated "plug-in", which is in line with policy
>>>>> on consistency as set out on the wiki
>>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>>>>
>>>>> I'm glad you brought this up as I see there are places where the
>>>>> documentation has been incorrectly updated at various times and
>>>>> contradicts itself. Unless there has been another change of mind, I'll
>>>>> go through and update as necessary over the next couple of days.
>>>>>
>>>>> My understanding is that it has been agreed that we consistently use
>>>>> the hyphenated form of "plug-in".
>>>>>
>>>>> Due to the number of old plug-in in the wild, both the hyphenated and
>>>>> non-hyphenated forms are currently supported in the header ";nyquist
>>>>> plug-in".
>>>>>
>>>>> Sorry about the inconvenience Robert.
>>>>>
>>>>> Steve
>>>>>
>>>>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]>
>>>>> wrote:
>>>>>> Hi
>>>>>>
>>>>>> Recently, a property entry of *system-dir* has changed.
>>>>>> Normally, one could get all plug-in locations in Nyquist with the
>>>>>> command:
>>>>>> (get '*system-dir* 'plugin)
>>>>>> It has been changed to 'plug-in.
>>>>>>
>>>>>> Although I understand the reason, plug-ins that use this information
>>>>>> won't be backwards compatible.
>>>>>>
>>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>>>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>>>>
>>>>>> Please inform if I have from now on to search for both writing
>>>>>> variants.
>>>>>>
>>>>>> Thanks
>>>>>> Robert
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle


On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]> wrote:
Apropos inconsistency:
'peak returns a single value for stereo tracks whereas 'rms returns an
array of two values.

What do you suggest?

Steve
 

Robert

2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
> Thanks for pointing out the floor with the version check.
>
> It is probably better to use something like
>
> (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version) '(100 10
> 1)))))
>
> provided that the second and third numbers won't ever be greater nine... ;)
> Robert
>
> 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> I thought it would be logical to name the folder locations 'plug-ins'
>> since the folders themselves are all plural.
>>
>> Regarding channel allocation, we could consider calling them "Front
>> Left", "Front Center" etc.
>> This should be compatible with multi channel definition in the long run.
>> Although no actual naming convention exists that I would be aware of.
>>
>> Robert
>>
>> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]>
>>> wrote:
>>>> Yes, very inconvenient, more so as other names has changed as well,
>>>> like 'peak-level' to 'peak'.
>>>> It means that all my plug-ins (that use properties) have to include a
>>>> version query.
>>>>
>>>> That's harder than it seems.
>>>> The only satisfying solution so far is:
>>>> ; test for version greater equals 2.1.3
>>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2 1
>>>> 3)))))
>>>>
>>>> Do you have a simpler solution?
>>>
>>> I think that test will fail if the next version is called Audacity
>>> 2.2.0.
>>>
>>> If you try to "Get" a property value that does not exist, it will return
>>> "NIL".
>>> So, if for example, we add a new property list item part way through
>>> the 2.1.4 development cycle, you can start using it straight away
>>> provided that you handle to possibility of the property not being
>>> available in some versions of Audacity.
>>>
>>> For example:
>>>
>>> (if (not (setf rms (get '*selection* 'rms)))
>>>     (throw 'err "Audacity version not supported"))
>>>
>>> or of course you could provide a legacy function to calculate the RMS.
>>>
>>>>
>>>> I'm not so sure that  documentation/manual recommendations should have
>>>> such an impact on pure LISP syntax, especially when the tendency goes
>>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>>>> But if you must change, make it "plug-ins" and not "plug-in".
>>>
>>> Well this is the problem. We are currently in freeze so any changes
>>> have to go through the release manager.
>>> We could discuss the comparative merits of singular or plural, but a
>>> decision needs to be made. If we put off making that decision, the
>>> greater the likelihood of breaking user's custom plug-ins. It would be
>>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>>> take that approach for syntax that has been around for a long time,
>>> such as using "real" for slider widgets that take float values, but
>>> generally it's much cleaner to have just one "correct" syntax.
>>>
>>> I don't want to be incrementing the Nyquist plug-in version number
>>> with every release, because each time we increment the version number
>>> requires adding conditionals in Audacity to determine how to correctly
>>> parse the code. On the other hand, I don't think it's practical to
>>> wait until we have a frozen specification before we make new features
>>> available.
>>>
>>> Clearly we do want to keep changes to existing syntax to a minimum,
>>> but I think we need to accept that new additions may be subject to
>>> change.
>>>
>>>
>>>>
>>>> I like the additions, such as RMS.
>>>> If possible, I would also like to see:
>>>> - '*track* --> orientation Left Right Mono.
>>>
>>> Although we've had track channel allocation in this way for a long
>>> time, I'm uncertain how much longer we will use it. For left/right,
>>> all we really need is "pan". For multi-channel sound we need more
>>> flexible channel allocation. I think it's quite possible that track
>>> channel allocation could change, and we wouldn't want to introduce
>>> this new property now for it to then be obsolete in a release or two.
>>>
>>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>>>> current zoom factor).
>>>
>>> I don't know how or if that would work with Paul's proposed "Fish Eye"
>>> view, so perhaps best to hold off that for now,
>>>
>>>>
>>>> Well, there are others... ;)
>>>
>>> Let's discus on the Nyquist forum board. The property lists can
>>> certainly be extended.
>>>
>>> Steve
>>>
>>>>
>>>> Thanks for keeping Nyquist rocking.
>>>>
>>>> Robert
>>>>
>>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>>>> <[hidden email]>:
>>>>> The documentation dated May 2015
>>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#.2ASYSTEM-DIR.2A)
>>>>> says it should be hyphenated "plug-in", which is in line with policy
>>>>> on consistency as set out on the wiki
>>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>>>>>
>>>>> I'm glad you brought this up as I see there are places where the
>>>>> documentation has been incorrectly updated at various times and
>>>>> contradicts itself. Unless there has been another change of mind, I'll
>>>>> go through and update as necessary over the next couple of days.
>>>>>
>>>>> My understanding is that it has been agreed that we consistently use
>>>>> the hyphenated form of "plug-in".
>>>>>
>>>>> Due to the number of old plug-in in the wild, both the hyphenated and
>>>>> non-hyphenated forms are currently supported in the header ";nyquist
>>>>> plug-in".
>>>>>
>>>>> Sorry about the inconvenience Robert.
>>>>>
>>>>> Steve
>>>>>
>>>>> On 27 February 2017 at 12:22, Robert Hänggi <[hidden email]>
>>>>> wrote:
>>>>>> Hi
>>>>>>
>>>>>> Recently, a property entry of *system-dir* has changed.
>>>>>> Normally, one could get all plug-in locations in Nyquist with the
>>>>>> command:
>>>>>> (get '*system-dir* 'plugin)
>>>>>> It has been changed to 'plug-in.
>>>>>>
>>>>>> Although I understand the reason, plug-ins that use this information
>>>>>> won't be backwards compatible.
>>>>>>
>>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>>>>>> somewhat surprised that they don't work anymore after a GIT pull...
>>>>>>
>>>>>> Please inform if I have from now on to search for both writing
>>>>>> variants.
>>>>>>
>>>>>> Thanks
>>>>>> Robert
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]>:

> On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]>
> wrote:
>
>> Apropos inconsistency:
>> 'peak returns a single value for stereo tracks whereas 'rms returns an
>> array of two values.
>>
>
> What do you suggest?
>

1. level values per channel for both, peak and rms
2. returned as lists, not as arrays since the latter is poorly
implemented in XLisp.

Robert

> Steve
>
>
>>
>> Robert
>>
>> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
>> > Thanks for pointing out the floor with the version check.
>> >
>> > It is probably better to use something like
>> >
>> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version) '(100
>> > 10
>> > 1)))))
>> >
>> > provided that the second and third numbers won't ever be greater
>> > nine...
>> ;)
>> > Robert
>> >
>> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> I thought it would be logical to name the folder locations 'plug-ins'
>> >> since the folders themselves are all plural.
>> >>
>> >> Regarding channel allocation, we could consider calling them "Front
>> >> Left", "Front Center" etc.
>> >> This should be compatible with multi channel definition in the long
>> >> run.
>> >> Although no actual naming convention exists that I would be aware of.
>> >>
>> >> Robert
>> >>
>> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]
>> >:
>> >>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]>
>> >>> wrote:
>> >>>> Yes, very inconvenient, more so as other names has changed as well,
>> >>>> like 'peak-level' to 'peak'.
>> >>>> It means that all my plug-ins (that use properties) have to include
>> >>>> a
>> >>>> version query.
>> >>>>
>> >>>> That's harder than it seems.
>> >>>> The only satisfying solution so far is:
>> >>>> ; test for version greater equals 2.1.3
>> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2
>> >>>> 1
>> >>>> 3)))))
>> >>>>
>> >>>> Do you have a simpler solution?
>> >>>
>> >>> I think that test will fail if the next version is called Audacity
>> >>> 2.2.0.
>> >>>
>> >>> If you try to "Get" a property value that does not exist, it will
>> return
>> >>> "NIL".
>> >>> So, if for example, we add a new property list item part way through
>> >>> the 2.1.4 development cycle, you can start using it straight away
>> >>> provided that you handle to possibility of the property not being
>> >>> available in some versions of Audacity.
>> >>>
>> >>> For example:
>> >>>
>> >>> (if (not (setf rms (get '*selection* 'rms)))
>> >>>     (throw 'err "Audacity version not supported"))
>> >>>
>> >>> or of course you could provide a legacy function to calculate the
>> >>> RMS.
>> >>>
>> >>>>
>> >>>> I'm not so sure that  documentation/manual recommendations should
>> >>>> have
>> >>>> such an impact on pure LISP syntax, especially when the tendency
>> >>>> goes
>> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>> >>>
>> >>> Well this is the problem. We are currently in freeze so any changes
>> >>> have to go through the release manager.
>> >>> We could discuss the comparative merits of singular or plural, but a
>> >>> decision needs to be made. If we put off making that decision, the
>> >>> greater the likelihood of breaking user's custom plug-ins. It would
>> >>> be
>> >>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>> >>> take that approach for syntax that has been around for a long time,
>> >>> such as using "real" for slider widgets that take float values, but
>> >>> generally it's much cleaner to have just one "correct" syntax.
>> >>>
>> >>> I don't want to be incrementing the Nyquist plug-in version number
>> >>> with every release, because each time we increment the version number
>> >>> requires adding conditionals in Audacity to determine how to
>> >>> correctly
>> >>> parse the code. On the other hand, I don't think it's practical to
>> >>> wait until we have a frozen specification before we make new features
>> >>> available.
>> >>>
>> >>> Clearly we do want to keep changes to existing syntax to a minimum,
>> >>> but I think we need to accept that new additions may be subject to
>> >>> change.
>> >>>
>> >>>
>> >>>>
>> >>>> I like the additions, such as RMS.
>> >>>> If possible, I would also like to see:
>> >>>> - '*track* --> orientation Left Right Mono.
>> >>>
>> >>> Although we've had track channel allocation in this way for a long
>> >>> time, I'm uncertain how much longer we will use it. For left/right,
>> >>> all we really need is "pan". For multi-channel sound we need more
>> >>> flexible channel allocation. I think it's quite possible that track
>> >>> channel allocation could change, and we wouldn't want to introduce
>> >>> this new property now for it to then be obsolete in a release or two.
>> >>>
>> >>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> >>>> current zoom factor).
>> >>>
>> >>> I don't know how or if that would work with Paul's proposed "Fish
>> >>> Eye"
>> >>> view, so perhaps best to hold off that for now,
>> >>>
>> >>>>
>> >>>> Well, there are others... ;)
>> >>>
>> >>> Let's discus on the Nyquist forum board. The property lists can
>> >>> certainly be extended.
>> >>>
>> >>> Steve
>> >>>
>> >>>>
>> >>>> Thanks for keeping Nyquist rocking.
>> >>>>
>> >>>> Robert
>> >>>>
>> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>> >>>> <[hidden email]>:
>> >>>>> The documentation dated May 2015
>> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>> Reference#.2ASYSTEM-DIR.2A)
>> >>>>> says it should be hyphenated "plug-in", which is in line with
>> >>>>> policy
>> >>>>> on consistency as set out on the wiki
>> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>> >>>>>
>> >>>>> I'm glad you brought this up as I see there are places where the
>> >>>>> documentation has been incorrectly updated at various times and
>> >>>>> contradicts itself. Unless there has been another change of mind,
>> I'll
>> >>>>> go through and update as necessary over the next couple of days.
>> >>>>>
>> >>>>> My understanding is that it has been agreed that we consistently
>> >>>>> use
>> >>>>> the hyphenated form of "plug-in".
>> >>>>>
>> >>>>> Due to the number of old plug-in in the wild, both the hyphenated
>> >>>>> and
>> >>>>> non-hyphenated forms are currently supported in the header
>> >>>>> ";nyquist
>> >>>>> plug-in".
>> >>>>>
>> >>>>> Sorry about the inconvenience Robert.
>> >>>>>
>> >>>>> Steve
>> >>>>>
>> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>> >>>>> <[hidden email]
>> >
>> >>>>> wrote:
>> >>>>>> Hi
>> >>>>>>
>> >>>>>> Recently, a property entry of *system-dir* has changed.
>> >>>>>> Normally, one could get all plug-in locations in Nyquist with the
>> >>>>>> command:
>> >>>>>> (get '*system-dir* 'plugin)
>> >>>>>> It has been changed to 'plug-in.
>> >>>>>>
>> >>>>>> Although I understand the reason, plug-ins that use this
>> >>>>>> information
>> >>>>>> won't be backwards compatible.
>> >>>>>>
>> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>> >>>>>> somewhat surprised that they don't work anymore after a GIT
>> >>>>>> pull...
>> >>>>>>
>> >>>>>> Please inform if I have from now on to search for both writing
>> >>>>>> variants.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>> Robert
>> >>>>>>
>> >>>>>> ------------------------------------------------------------
>> ------------------
>> >>>>>> Check out the vibrant tech community on one of the world's most
>> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>>>> _______________________________________________
>> >>>>>> Audacity-quality mailing list
>> >>>>>> [hidden email]
>> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ------------------
>> >>>>> Check out the vibrant tech community on one of the world's most
>> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>>> _______________________________________________
>> >>>>> Audacity-quality mailing list
>> >>>>> [hidden email]
>> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>>>
>> >>>>
>> >>>> ------------------------------------------------------------
>> ------------------
>> >>>> Check out the vibrant tech community on one of the world's most
>> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>> _______________________________________________
>> >>>> Audacity-quality mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>> ------------------------------------------------------------
>> ------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Audacity-quality mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle


On 28 February 2017 at 05:51, Robert Hänggi <[hidden email]> wrote:
2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]>:
> On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]>
> wrote:
>
>> Apropos inconsistency:
>> 'peak returns a single value for stereo tracks whereas 'rms returns an
>> array of two values.
>>
>
> What do you suggest?
>

1. level values per channel for both, peak and rms
2. returned as lists, not as arrays since the latter is poorly
implemented in XLisp.

I agree with point 1, but not point 2.

Arrays in XLISP are less feature rich than lists, and less feature rich than in most other LISP dialects, but I'm not aware of any bugs, so I'd not describe them as "poorly implemented".

Lists tend to imply a collection of "things", where we can add and remove an arbitrary number of items, whereas an array tends to imply a "thing" as a whole. For example, we can consider an audio track as "a thing" and we represent a stereo track as an array. On the other hand we treat clips as a list. So for a stereo track, we can have an array of lists, where the two elements of the array represent the two audio channels, and each element is a list of clips.

Thus:
(aref *track* 0) is the left channel of a selected stereo wave track.
(aref (get '*track* 'clips) 0) is a list of clips in the left channel.
(aref (get '*selection* 'rms) 0) is the RMS level of the left channel,
and potentially
(aref (get '*selection* 'peak) 0) would be the peak level of the left channel.

What I would ideally like to do, is to retain the "plugin" and "peak-level" properties as deprecated legacy code, and have "plug-in" and "peak" as the preferred forms, with "peak" being an array in the case of stereo tracks.

I've approached the release manager about doing this for 2.1.3, but we're already late with this release, and it's the RMs mandate to decide.

Steve

 

Robert

> Steve
>
>
>>
>> Robert
>>
>> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
>> > Thanks for pointing out the floor with the version check.
>> >
>> > It is probably better to use something like
>> >
>> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version) '(100
>> > 10
>> > 1)))))
>> >
>> > provided that the second and third numbers won't ever be greater
>> > nine...
>> ;)
>> > Robert
>> >
>> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> I thought it would be logical to name the folder locations 'plug-ins'
>> >> since the folders themselves are all plural.
>> >>
>> >> Regarding channel allocation, we could consider calling them "Front
>> >> Left", "Front Center" etc.
>> >> This should be compatible with multi channel definition in the long
>> >> run.
>> >> Although no actual naming convention exists that I would be aware of.
>> >>
>> >> Robert
>> >>
>> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <[hidden email]
>> >:
>> >>> On 27 February 2017 at 15:05, Robert Hänggi <[hidden email]>
>> >>> wrote:
>> >>>> Yes, very inconvenient, more so as other names has changed as well,
>> >>>> like 'peak-level' to 'peak'.
>> >>>> It means that all my plug-ins (that use properties) have to include
>> >>>> a
>> >>>> version query.
>> >>>>
>> >>>> That's harder than it seems.
>> >>>> The only satisfying solution so far is:
>> >>>> ; test for version greater equals 2.1.3
>> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version) '(2
>> >>>> 1
>> >>>> 3)))))
>> >>>>
>> >>>> Do you have a simpler solution?
>> >>>
>> >>> I think that test will fail if the next version is called Audacity
>> >>> 2.2.0.
>> >>>
>> >>> If you try to "Get" a property value that does not exist, it will
>> return
>> >>> "NIL".
>> >>> So, if for example, we add a new property list item part way through
>> >>> the 2.1.4 development cycle, you can start using it straight away
>> >>> provided that you handle to possibility of the property not being
>> >>> available in some versions of Audacity.
>> >>>
>> >>> For example:
>> >>>
>> >>> (if (not (setf rms (get '*selection* 'rms)))
>> >>>     (throw 'err "Audacity version not supported"))
>> >>>
>> >>> or of course you could provide a legacy function to calculate the
>> >>> RMS.
>> >>>
>> >>>>
>> >>>> I'm not so sure that  documentation/manual recommendations should
>> >>>> have
>> >>>> such an impact on pure LISP syntax, especially when the tendency
>> >>>> goes
>> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>> >>>
>> >>> Well this is the problem. We are currently in freeze so any changes
>> >>> have to go through the release manager.
>> >>> We could discuss the comparative merits of singular or plural, but a
>> >>> decision needs to be made. If we put off making that decision, the
>> >>> greater the likelihood of breaking user's custom plug-ins. It would
>> >>> be
>> >>> 'possible' to allow multiple versions, say "plugin" or "plugins" or
>> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we need to
>> >>> take that approach for syntax that has been around for a long time,
>> >>> such as using "real" for slider widgets that take float values, but
>> >>> generally it's much cleaner to have just one "correct" syntax.
>> >>>
>> >>> I don't want to be incrementing the Nyquist plug-in version number
>> >>> with every release, because each time we increment the version number
>> >>> requires adding conditionals in Audacity to determine how to
>> >>> correctly
>> >>> parse the code. On the other hand, I don't think it's practical to
>> >>> wait until we have a frozen specification before we make new features
>> >>> available.
>> >>>
>> >>> Clearly we do want to keep changes to existing syntax to a minimum,
>> >>> but I think we need to accept that new additions may be subject to
>> >>> change.
>> >>>
>> >>>
>> >>>>
>> >>>> I like the additions, such as RMS.
>> >>>> If possible, I would also like to see:
>> >>>> - '*track* --> orientation Left Right Mono.
>> >>>
>> >>> Although we've had track channel allocation in this way for a long
>> >>> time, I'm uncertain how much longer we will use it. For left/right,
>> >>> all we really need is "pan". For multi-channel sound we need more
>> >>> flexible channel allocation. I think it's quite possible that track
>> >>> channel allocation could change, and we wouldn't want to introduce
>> >>> this new property now for it to then be obsolete in a release or two.
>> >>>
>> >>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> >>>> current zoom factor).
>> >>>
>> >>> I don't know how or if that would work with Paul's proposed "Fish
>> >>> Eye"
>> >>> view, so perhaps best to hold off that for now,
>> >>>
>> >>>>
>> >>>> Well, there are others... ;)
>> >>>
>> >>> Let's discus on the Nyquist forum board. The property lists can
>> >>> certainly be extended.
>> >>>
>> >>> Steve
>> >>>
>> >>>>
>> >>>> Thanks for keeping Nyquist rocking.
>> >>>>
>> >>>> Robert
>> >>>>
>> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>> >>>> <[hidden email]>:
>> >>>>> The documentation dated May 2015
>> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>> Reference#.2ASYSTEM-DIR.2A)
>> >>>>> says it should be hyphenated "plug-in", which is in line with
>> >>>>> policy
>> >>>>> on consistency as set out on the wiki
>> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements).
>> >>>>>
>> >>>>> I'm glad you brought this up as I see there are places where the
>> >>>>> documentation has been incorrectly updated at various times and
>> >>>>> contradicts itself. Unless there has been another change of mind,
>> I'll
>> >>>>> go through and update as necessary over the next couple of days.
>> >>>>>
>> >>>>> My understanding is that it has been agreed that we consistently
>> >>>>> use
>> >>>>> the hyphenated form of "plug-in".
>> >>>>>
>> >>>>> Due to the number of old plug-in in the wild, both the hyphenated
>> >>>>> and
>> >>>>> non-hyphenated forms are currently supported in the header
>> >>>>> ";nyquist
>> >>>>> plug-in".
>> >>>>>
>> >>>>> Sorry about the inconvenience Robert.
>> >>>>>
>> >>>>> Steve
>> >>>>>
>> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>> >>>>> <[hidden email]
>> >
>> >>>>> wrote:
>> >>>>>> Hi
>> >>>>>>
>> >>>>>> Recently, a property entry of *system-dir* has changed.
>> >>>>>> Normally, one could get all plug-in locations in Nyquist with the
>> >>>>>> command:
>> >>>>>> (get '*system-dir* 'plugin)
>> >>>>>> It has been changed to 'plug-in.
>> >>>>>>
>> >>>>>> Although I understand the reason, plug-ins that use this
>> >>>>>> information
>> >>>>>> won't be backwards compatible.
>> >>>>>>
>> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>> >>>>>> somewhat surprised that they don't work anymore after a GIT
>> >>>>>> pull...
>> >>>>>>
>> >>>>>> Please inform if I have from now on to search for both writing
>> >>>>>> variants.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>> Robert
>> >>>>>>
>> >>>>>> ------------------------------------------------------------
>> ------------------
>> >>>>>> Check out the vibrant tech community on one of the world's most
>> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>>>> _______________________________________________
>> >>>>>> Audacity-quality mailing list
>> >>>>>> [hidden email]
>> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>>>
>> >>>>> ------------------------------------------------------------
>> ------------------
>> >>>>> Check out the vibrant tech community on one of the world's most
>> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>>> _______________________________________________
>> >>>>> Audacity-quality mailing list
>> >>>>> [hidden email]
>> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>>>
>> >>>>
>> >>>> ------------------------------------------------------------
>> ------------------
>> >>>> Check out the vibrant tech community on one of the world's most
>> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>>> _______________________________________________
>> >>>> Audacity-quality mailing list
>> >>>> [hidden email]
>> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>> ------------------------------------------------------------
>> ------------------
>> >>> Check out the vibrant tech community on one of the world's most
>> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >>> _______________________________________________
>> >>> Audacity-quality mailing list
>> >>> [hidden email]
>> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>>
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
Hi Steve

I see arrays as poorly implemented because their only feature is
referencing values.
You cannot simply add, subtract or apply another function to it.
Roger implemented a lot of helper functions to achieve this when the
array item is a sound, e.g. sum-of-arrays or multichannel-max.
To get the highest peak of an x-channel sound you have to write a loop
(looking forward in future).
For a list, you would simply write
(apply 'max (get '*selection* 'peak))

(works also for a mono track, if the single value is embedded in a
list as well.)

Or imagine sorting a 7.1 multichannel track rms/peak array...

Anyway, I can deal with wither solution, simple or complicated.

Thanks for having passed it to James.

Robert

2017-03-01 13:31 GMT+01:00, Steve the Fiddle <[hidden email]>:

> On 28 February 2017 at 05:51, Robert Hänggi <[hidden email]>
> wrote:
>
>> 2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> > On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Apropos inconsistency:
>> >> 'peak returns a single value for stereo tracks whereas 'rms returns an
>> >> array of two values.
>> >>
>> >
>> > What do you suggest?
>> >
>>
>> 1. level values per channel for both, peak and rms
>> 2. returned as lists, not as arrays since the latter is poorly
>> implemented in XLisp.
>>
>
> I agree with point 1, but not point 2.
>
> Arrays in XLISP are less feature rich than lists, and less feature rich
> than in most other LISP dialects, but I'm not aware of any bugs, so I'd not
> describe them as "poorly implemented".
>
> Lists tend to imply a collection of "things", where we can add and remove
> an arbitrary number of items, whereas an array tends to imply a "thing" as
> a whole. For example, we can consider an audio track as "a thing" and we
> represent a stereo track as an array. On the other hand we treat clips as a
> list. So for a stereo track, we can have an array of lists, where the two
> elements of the array represent the two audio channels, and each element is
> a list of clips.
>
> Thus:
> (aref *track* 0) is the left channel of a selected stereo wave track.
> (aref (get '*track* 'clips) 0) is a list of clips in the left channel.
> (aref (get '*selection* 'rms) 0) is the RMS level of the left channel,
> and potentially
> (aref (get '*selection* 'peak) 0) would be the peak level of the left
> channel.
>
> What I would ideally like to do, is to retain the "plugin" and "peak-level"
> properties as deprecated legacy code, and have "plug-in" and "peak" as the
> preferred forms, with "peak" being an array in the case of stereo tracks.
>
> I've approached the release manager about doing this for 2.1.3, but we're
> already late with this release, and it's the RMs mandate to decide.
>
> Steve
>
>
>
>>
>> Robert
>>
>> > Steve
>> >
>> >
>> >>
>> >> Robert
>> >>
>> >> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> > Thanks for pointing out the floor with the version check.
>> >> >
>> >> > It is probably better to use something like
>> >> >
>> >> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version)
>> >> > '(100
>> >> > 10
>> >> > 1)))))
>> >> >
>> >> > provided that the second and third numbers won't ever be greater
>> >> > nine...
>> >> ;)
>> >> > Robert
>> >> >
>> >> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> >> I thought it would be logical to name the folder locations
>> >> >> 'plug-ins'
>> >> >> since the folders themselves are all plural.
>> >> >>
>> >> >> Regarding channel allocation, we could consider calling them "Front
>> >> >> Left", "Front Center" etc.
>> >> >> This should be compatible with multi channel definition in the long
>> >> >> run.
>> >> >> Although no actual naming convention exists that I would be aware
>> >> >> of.
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <
>> [hidden email]
>> >> >:
>> >> >>> On 27 February 2017 at 15:05, Robert Hänggi <
>> [hidden email]>
>> >> >>> wrote:
>> >> >>>> Yes, very inconvenient, more so as other names has changed as
>> >> >>>> well,
>> >> >>>> like 'peak-level' to 'peak'.
>> >> >>>> It means that all my plug-ins (that use properties) have to
>> >> >>>> include
>> >> >>>> a
>> >> >>>> version query.
>> >> >>>>
>> >> >>>> That's harder than it seems.
>> >> >>>> The only satisfying solution so far is:
>> >> >>>> ; test for version greater equals 2.1.3
>> >> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version)
>> '(2
>> >> >>>> 1
>> >> >>>> 3)))))
>> >> >>>>
>> >> >>>> Do you have a simpler solution?
>> >> >>>
>> >> >>> I think that test will fail if the next version is called Audacity
>> >> >>> 2.2.0.
>> >> >>>
>> >> >>> If you try to "Get" a property value that does not exist, it will
>> >> return
>> >> >>> "NIL".
>> >> >>> So, if for example, we add a new property list item part way
>> >> >>> through
>> >> >>> the 2.1.4 development cycle, you can start using it straight away
>> >> >>> provided that you handle to possibility of the property not being
>> >> >>> available in some versions of Audacity.
>> >> >>>
>> >> >>> For example:
>> >> >>>
>> >> >>> (if (not (setf rms (get '*selection* 'rms)))
>> >> >>>     (throw 'err "Audacity version not supported"))
>> >> >>>
>> >> >>> or of course you could provide a legacy function to calculate the
>> >> >>> RMS.
>> >> >>>
>> >> >>>>
>> >> >>>> I'm not so sure that  documentation/manual recommendations should
>> >> >>>> have
>> >> >>>> such an impact on pure LISP syntax, especially when the tendency
>> >> >>>> goes
>> >> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> >> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>> >> >>>
>> >> >>> Well this is the problem. We are currently in freeze so any
>> >> >>> changes
>> >> >>> have to go through the release manager.
>> >> >>> We could discuss the comparative merits of singular or plural, but
>> >> >>> a
>> >> >>> decision needs to be made. If we put off making that decision, the
>> >> >>> greater the likelihood of breaking user's custom plug-ins. It
>> >> >>> would
>> >> >>> be
>> >> >>> 'possible' to allow multiple versions, say "plugin" or "plugins"
>> >> >>> or
>> >> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we need
>> to
>> >> >>> take that approach for syntax that has been around for a long
>> >> >>> time,
>> >> >>> such as using "real" for slider widgets that take float values,
>> >> >>> but
>> >> >>> generally it's much cleaner to have just one "correct" syntax.
>> >> >>>
>> >> >>> I don't want to be incrementing the Nyquist plug-in version number
>> >> >>> with every release, because each time we increment the version
>> number
>> >> >>> requires adding conditionals in Audacity to determine how to
>> >> >>> correctly
>> >> >>> parse the code. On the other hand, I don't think it's practical to
>> >> >>> wait until we have a frozen specification before we make new
>> features
>> >> >>> available.
>> >> >>>
>> >> >>> Clearly we do want to keep changes to existing syntax to a
>> >> >>> minimum,
>> >> >>> but I think we need to accept that new additions may be subject to
>> >> >>> change.
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> I like the additions, such as RMS.
>> >> >>>> If possible, I would also like to see:
>> >> >>>> - '*track* --> orientation Left Right Mono.
>> >> >>>
>> >> >>> Although we've had track channel allocation in this way for a long
>> >> >>> time, I'm uncertain how much longer we will use it. For
>> >> >>> left/right,
>> >> >>> all we really need is "pan". For multi-channel sound we need more
>> >> >>> flexible channel allocation. I think it's quite possible that
>> >> >>> track
>> >> >>> channel allocation could change, and we wouldn't want to introduce
>> >> >>> this new property now for it to then be obsolete in a release or
>> two.
>> >> >>>
>> >> >>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> >> >>>> current zoom factor).
>> >> >>>
>> >> >>> I don't know how or if that would work with Paul's proposed "Fish
>> >> >>> Eye"
>> >> >>> view, so perhaps best to hold off that for now,
>> >> >>>
>> >> >>>>
>> >> >>>> Well, there are others... ;)
>> >> >>>
>> >> >>> Let's discus on the Nyquist forum board. The property lists can
>> >> >>> certainly be extended.
>> >> >>>
>> >> >>> Steve
>> >> >>>
>> >> >>>>
>> >> >>>> Thanks for keeping Nyquist rocking.
>> >> >>>>
>> >> >>>> Robert
>> >> >>>>
>> >> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>> >> >>>> <[hidden email]>:
>> >> >>>>> The documentation dated May 2015
>> >> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>> >> Reference#.2ASYSTEM-DIR.2A)
>> >> >>>>> says it should be hyphenated "plug-in", which is in line with
>> >> >>>>> policy
>> >> >>>>> on consistency as set out on the wiki
>> >> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements
>> ).
>> >> >>>>>
>> >> >>>>> I'm glad you brought this up as I see there are places where the
>> >> >>>>> documentation has been incorrectly updated at various times and
>> >> >>>>> contradicts itself. Unless there has been another change of
>> >> >>>>> mind,
>> >> I'll
>> >> >>>>> go through and update as necessary over the next couple of days.
>> >> >>>>>
>> >> >>>>> My understanding is that it has been agreed that we consistently
>> >> >>>>> use
>> >> >>>>> the hyphenated form of "plug-in".
>> >> >>>>>
>> >> >>>>> Due to the number of old plug-in in the wild, both the
>> >> >>>>> hyphenated
>> >> >>>>> and
>> >> >>>>> non-hyphenated forms are currently supported in the header
>> >> >>>>> ";nyquist
>> >> >>>>> plug-in".
>> >> >>>>>
>> >> >>>>> Sorry about the inconvenience Robert.
>> >> >>>>>
>> >> >>>>> Steve
>> >> >>>>>
>> >> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>> >> >>>>> <[hidden email]
>> >> >
>> >> >>>>> wrote:
>> >> >>>>>> Hi
>> >> >>>>>>
>> >> >>>>>> Recently, a property entry of *system-dir* has changed.
>> >> >>>>>> Normally, one could get all plug-in locations in Nyquist with
>> >> >>>>>> the
>> >> >>>>>> command:
>> >> >>>>>> (get '*system-dir* 'plugin)
>> >> >>>>>> It has been changed to 'plug-in.
>> >> >>>>>>
>> >> >>>>>> Although I understand the reason, plug-ins that use this
>> >> >>>>>> information
>> >> >>>>>> won't be backwards compatible.
>> >> >>>>>>
>> >> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>> >> >>>>>> somewhat surprised that they don't work anymore after a GIT
>> >> >>>>>> pull...
>> >> >>>>>>
>> >> >>>>>> Please inform if I have from now on to search for both writing
>> >> >>>>>> variants.
>> >> >>>>>>
>> >> >>>>>> Thanks
>> >> >>>>>> Robert
>> >> >>>>>>
>> >> >>>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>>> _______________________________________________
>> >> >>>>>> Audacity-quality mailing list
>> >> >>>>>> [hidden email]
>> >> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>> _______________________________________________
>> >> >>>>> Audacity-quality mailing list
>> >> >>>>> [hidden email]
>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>
>> >> >>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>> Check out the vibrant tech community on one of the world's most
>> >> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>> _______________________________________________
>> >> >>>> Audacity-quality mailing list
>> >> >>>> [hidden email]
>> >> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>> ------------------------------------------------------------
>> >> ------------------
>> >> >>> Check out the vibrant tech community on one of the world's most
>> >> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>> _______________________________________________
>> >> >>> Audacity-quality mailing list
>> >> >>> [hidden email]
>> >> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >> ------------------------------------------------------------
>> >> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle


On 1 March 2017 at 13:43, Robert Hänggi <[hidden email]> wrote:
Hi Steve

I see arrays as poorly implemented because their only feature is
referencing values.
You cannot simply add, subtract or apply another function to it.
Roger implemented a lot of helper functions to achieve this when the
array item is a sound, e.g. sum-of-arrays or multichannel-max.
To get the highest peak of an x-channel sound you have to write a loop
(looking forward in future).
For a list, you would simply write
(apply 'max (get '*selection* 'peak)) 

Multichannel-max is just a LISP loop (undocumented in the Nyquist manual). We could easily add an "array-max" LISP function if we decided it was sufficiently useful, or a more general  "apply-array".

SUM, DIFF and MULT already work on numeric arrays.

I expect that we will be treating multi-channel sounds as an array of sounds for quite some time to come, as that's how stand-alone Nyquist deals with multi-channel sounds, so it seems logical to me to treat references to multi-channel sounds, such as peak or RMS levels, in a similar manner. So if "my-sound" is an array of sounds, and "my-peak" is an array peak levels of that sound, and "my-rms" is an array of RMS values, then (aref my-sound n) has a peak level of (aref my-peak n) and an RMS level of (aref my-rms n). I much prefer that to a mix of arrays and lists and having to remember which is an array and which a list.

 

(works also for a mono track, if the single value is embedded in a
list as well.)

Or imagine sorting a 7.1 multichannel track rms/peak array...

Anyway, I can deal with wither solution, simple or complicated.

Thanks for having passed it to James.

Well it was due to a bit of a misunderstanding that it was committed when it was, but James has given me the OK (off-list) to address the breakages and keep the RMS property. I'll let you know when I've updated the documentation so that you get chance to check it before 2.1.3 is released.

Steve
 

Robert

2017-03-01 13:31 GMT+01:00, Steve the Fiddle <[hidden email]>:
> On 28 February 2017 at 05:51, Robert Hänggi <[hidden email]>
> wrote:
>
>> 2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> > On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Apropos inconsistency:
>> >> 'peak returns a single value for stereo tracks whereas 'rms returns an
>> >> array of two values.
>> >>
>> >
>> > What do you suggest?
>> >
>>
>> 1. level values per channel for both, peak and rms
>> 2. returned as lists, not as arrays since the latter is poorly
>> implemented in XLisp.
>>
>
> I agree with point 1, but not point 2.
>
> Arrays in XLISP are less feature rich than lists, and less feature rich
> than in most other LISP dialects, but I'm not aware of any bugs, so I'd not
> describe them as "poorly implemented".
>
> Lists tend to imply a collection of "things", where we can add and remove
> an arbitrary number of items, whereas an array tends to imply a "thing" as
> a whole. For example, we can consider an audio track as "a thing" and we
> represent a stereo track as an array. On the other hand we treat clips as a
> list. So for a stereo track, we can have an array of lists, where the two
> elements of the array represent the two audio channels, and each element is
> a list of clips.
>
> Thus:
> (aref *track* 0) is the left channel of a selected stereo wave track.
> (aref (get '*track* 'clips) 0) is a list of clips in the left channel.
> (aref (get '*selection* 'rms) 0) is the RMS level of the left channel,
> and potentially
> (aref (get '*selection* 'peak) 0) would be the peak level of the left
> channel.
>
> What I would ideally like to do, is to retain the "plugin" and "peak-level"
> properties as deprecated legacy code, and have "plug-in" and "peak" as the
> preferred forms, with "peak" being an array in the case of stereo tracks.
>
> I've approached the release manager about doing this for 2.1.3, but we're
> already late with this release, and it's the RMs mandate to decide.
>
> Steve
>
>
>
>>
>> Robert
>>
>> > Steve
>> >
>> >
>> >>
>> >> Robert
>> >>
>> >> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> > Thanks for pointing out the floor with the version check.
>> >> >
>> >> > It is probably better to use something like
>> >> >
>> >> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version)
>> >> > '(100
>> >> > 10
>> >> > 1)))))
>> >> >
>> >> > provided that the second and third numbers won't ever be greater
>> >> > nine...
>> >> ;)
>> >> > Robert
>> >> >
>> >> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> >> I thought it would be logical to name the folder locations
>> >> >> 'plug-ins'
>> >> >> since the folders themselves are all plural.
>> >> >>
>> >> >> Regarding channel allocation, we could consider calling them "Front
>> >> >> Left", "Front Center" etc.
>> >> >> This should be compatible with multi channel definition in the long
>> >> >> run.
>> >> >> Although no actual naming convention exists that I would be aware
>> >> >> of.
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <
>> [hidden email]
>> >> >:
>> >> >>> On 27 February 2017 at 15:05, Robert Hänggi <
>> [hidden email]>
>> >> >>> wrote:
>> >> >>>> Yes, very inconvenient, more so as other names has changed as
>> >> >>>> well,
>> >> >>>> like 'peak-level' to 'peak'.
>> >> >>>> It means that all my plug-ins (that use properties) have to
>> >> >>>> include
>> >> >>>> a
>> >> >>>> version query.
>> >> >>>>
>> >> >>>> That's harder than it seems.
>> >> >>>> The only satisfying solution so far is:
>> >> >>>> ; test for version greater equals 2.1.3
>> >> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version)
>> '(2
>> >> >>>> 1
>> >> >>>> 3)))))
>> >> >>>>
>> >> >>>> Do you have a simpler solution?
>> >> >>>
>> >> >>> I think that test will fail if the next version is called Audacity
>> >> >>> 2.2.0.
>> >> >>>
>> >> >>> If you try to "Get" a property value that does not exist, it will
>> >> return
>> >> >>> "NIL".
>> >> >>> So, if for example, we add a new property list item part way
>> >> >>> through
>> >> >>> the 2.1.4 development cycle, you can start using it straight away
>> >> >>> provided that you handle to possibility of the property not being
>> >> >>> available in some versions of Audacity.
>> >> >>>
>> >> >>> For example:
>> >> >>>
>> >> >>> (if (not (setf rms (get '*selection* 'rms)))
>> >> >>>     (throw 'err "Audacity version not supported"))
>> >> >>>
>> >> >>> or of course you could provide a legacy function to calculate the
>> >> >>> RMS.
>> >> >>>
>> >> >>>>
>> >> >>>> I'm not so sure that  documentation/manual recommendations should
>> >> >>>> have
>> >> >>>> such an impact on pure LISP syntax, especially when the tendency
>> >> >>>> goes
>> >> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> >> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>> >> >>>
>> >> >>> Well this is the problem. We are currently in freeze so any
>> >> >>> changes
>> >> >>> have to go through the release manager.
>> >> >>> We could discuss the comparative merits of singular or plural, but
>> >> >>> a
>> >> >>> decision needs to be made. If we put off making that decision, the
>> >> >>> greater the likelihood of breaking user's custom plug-ins. It
>> >> >>> would
>> >> >>> be
>> >> >>> 'possible' to allow multiple versions, say "plugin" or "plugins"
>> >> >>> or
>> >> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we need
>> to
>> >> >>> take that approach for syntax that has been around for a long
>> >> >>> time,
>> >> >>> such as using "real" for slider widgets that take float values,
>> >> >>> but
>> >> >>> generally it's much cleaner to have just one "correct" syntax.
>> >> >>>
>> >> >>> I don't want to be incrementing the Nyquist plug-in version number
>> >> >>> with every release, because each time we increment the version
>> number
>> >> >>> requires adding conditionals in Audacity to determine how to
>> >> >>> correctly
>> >> >>> parse the code. On the other hand, I don't think it's practical to
>> >> >>> wait until we have a frozen specification before we make new
>> features
>> >> >>> available.
>> >> >>>
>> >> >>> Clearly we do want to keep changes to existing syntax to a
>> >> >>> minimum,
>> >> >>> but I think we need to accept that new additions may be subject to
>> >> >>> change.
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> I like the additions, such as RMS.
>> >> >>>> If possible, I would also like to see:
>> >> >>>> - '*track* --> orientation Left Right Mono.
>> >> >>>
>> >> >>> Although we've had track channel allocation in this way for a long
>> >> >>> time, I'm uncertain how much longer we will use it. For
>> >> >>> left/right,
>> >> >>> all we really need is "pan". For multi-channel sound we need more
>> >> >>> flexible channel allocation. I think it's quite possible that
>> >> >>> track
>> >> >>> channel allocation could change, and we wouldn't want to introduce
>> >> >>> this new property now for it to then be obsolete in a release or
>> two.
>> >> >>>
>> >> >>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> >> >>>> current zoom factor).
>> >> >>>
>> >> >>> I don't know how or if that would work with Paul's proposed "Fish
>> >> >>> Eye"
>> >> >>> view, so perhaps best to hold off that for now,
>> >> >>>
>> >> >>>>
>> >> >>>> Well, there are others... ;)
>> >> >>>
>> >> >>> Let's discus on the Nyquist forum board. The property lists can
>> >> >>> certainly be extended.
>> >> >>>
>> >> >>> Steve
>> >> >>>
>> >> >>>>
>> >> >>>> Thanks for keeping Nyquist rocking.
>> >> >>>>
>> >> >>>> Robert
>> >> >>>>
>> >> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>> >> >>>> <[hidden email]>:
>> >> >>>>> The documentation dated May 2015
>> >> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>> >> Reference#.2ASYSTEM-DIR.2A)
>> >> >>>>> says it should be hyphenated "plug-in", which is in line with
>> >> >>>>> policy
>> >> >>>>> on consistency as set out on the wiki
>> >> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements
>> ).
>> >> >>>>>
>> >> >>>>> I'm glad you brought this up as I see there are places where the
>> >> >>>>> documentation has been incorrectly updated at various times and
>> >> >>>>> contradicts itself. Unless there has been another change of
>> >> >>>>> mind,
>> >> I'll
>> >> >>>>> go through and update as necessary over the next couple of days.
>> >> >>>>>
>> >> >>>>> My understanding is that it has been agreed that we consistently
>> >> >>>>> use
>> >> >>>>> the hyphenated form of "plug-in".
>> >> >>>>>
>> >> >>>>> Due to the number of old plug-in in the wild, both the
>> >> >>>>> hyphenated
>> >> >>>>> and
>> >> >>>>> non-hyphenated forms are currently supported in the header
>> >> >>>>> ";nyquist
>> >> >>>>> plug-in".
>> >> >>>>>
>> >> >>>>> Sorry about the inconvenience Robert.
>> >> >>>>>
>> >> >>>>> Steve
>> >> >>>>>
>> >> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>> >> >>>>> <[hidden email]
>> >> >
>> >> >>>>> wrote:
>> >> >>>>>> Hi
>> >> >>>>>>
>> >> >>>>>> Recently, a property entry of *system-dir* has changed.
>> >> >>>>>> Normally, one could get all plug-in locations in Nyquist with
>> >> >>>>>> the
>> >> >>>>>> command:
>> >> >>>>>> (get '*system-dir* 'plugin)
>> >> >>>>>> It has been changed to 'plug-in.
>> >> >>>>>>
>> >> >>>>>> Although I understand the reason, plug-ins that use this
>> >> >>>>>> information
>> >> >>>>>> won't be backwards compatible.
>> >> >>>>>>
>> >> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>> >> >>>>>> somewhat surprised that they don't work anymore after a GIT
>> >> >>>>>> pull...
>> >> >>>>>>
>> >> >>>>>> Please inform if I have from now on to search for both writing
>> >> >>>>>> variants.
>> >> >>>>>>
>> >> >>>>>> Thanks
>> >> >>>>>> Robert
>> >> >>>>>>
>> >> >>>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>>> _______________________________________________
>> >> >>>>>> Audacity-quality mailing list
>> >> >>>>>> [hidden email]
>> >> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>> _______________________________________________
>> >> >>>>> Audacity-quality mailing list
>> >> >>>>> [hidden email]
>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>
>> >> >>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>> Check out the vibrant tech community on one of the world's most
>> >> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>> _______________________________________________
>> >> >>>> Audacity-quality mailing list
>> >> >>>> [hidden email]
>> >> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>> ------------------------------------------------------------
>> >> ------------------
>> >> >>> Check out the vibrant tech community on one of the world's most
>> >> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>> _______________________________________________
>> >> >>> Audacity-quality mailing list
>> >> >>> [hidden email]
>> >> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >> ------------------------------------------------------------
>> >> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Stevethefiddle
Having discussed this with James (RM), I've committed a couple of small changes to resolve issues raised by Robert.
This commit is mostly updating code comments to use the hyphenated form of "plug-ins" consistently within Nyquist.cpp.
The two functional changes are:

1) The error message:
"Bad Nyquist 'control' type specification: '%s' in plugin file '%s'.\nControl not created."
has been updated to:
"Bad Nyquist 'control' type specification: '%s' in plug-in file '%s'.\nControl not created."

2) The *SYSTEM_DIR* property "PLUGIN" has been restored as legacy syntax so as to not break existing plug-ins.
The preferred syntax is to use "PLUG-IN".


https://github.com/audacity/audacity/commit/b66675d71
This commit restores the *SELECTION* PEAK-LEVEL property.
I've marked this as "deprecated" in a code comment, though we could decide later to retain it under a different name such as MULTICHAN-PEAK.
The preferred syntax for now is:
*SELECTION* PEAK
which returns peak level per channel, either as a single number for mono tracks, or an array of two numbers for a stereo track.


The documentation (which is on the wiki) still needs updating, and I aim to do that over the next few days.
I'm not anticipating any further changes to Nyquist before 2.1.3 is released.

Steve


On 1 March 2017 at 15:03, Steve the Fiddle <[hidden email]> wrote:


On 1 March 2017 at 13:43, Robert Hänggi <[hidden email]> wrote:
Hi Steve

I see arrays as poorly implemented because their only feature is
referencing values.
You cannot simply add, subtract or apply another function to it.
Roger implemented a lot of helper functions to achieve this when the
array item is a sound, e.g. sum-of-arrays or multichannel-max.
To get the highest peak of an x-channel sound you have to write a loop
(looking forward in future).
For a list, you would simply write
(apply 'max (get '*selection* 'peak)) 

Multichannel-max is just a LISP loop (undocumented in the Nyquist manual). We could easily add an "array-max" LISP function if we decided it was sufficiently useful, or a more general  "apply-array".

SUM, DIFF and MULT already work on numeric arrays.

I expect that we will be treating multi-channel sounds as an array of sounds for quite some time to come, as that's how stand-alone Nyquist deals with multi-channel sounds, so it seems logical to me to treat references to multi-channel sounds, such as peak or RMS levels, in a similar manner. So if "my-sound" is an array of sounds, and "my-peak" is an array peak levels of that sound, and "my-rms" is an array of RMS values, then (aref my-sound n) has a peak level of (aref my-peak n) and an RMS level of (aref my-rms n). I much prefer that to a mix of arrays and lists and having to remember which is an array and which a list.

 

(works also for a mono track, if the single value is embedded in a
list as well.)

Or imagine sorting a 7.1 multichannel track rms/peak array...

Anyway, I can deal with wither solution, simple or complicated.

Thanks for having passed it to James.

Well it was due to a bit of a misunderstanding that it was committed when it was, but James has given me the OK (off-list) to address the breakages and keep the RMS property. I'll let you know when I've updated the documentation so that you get chance to check it before 2.1.3 is released.

Steve
 

Robert

2017-03-01 13:31 GMT+01:00, Steve the Fiddle <[hidden email]>:
> On 28 February 2017 at 05:51, Robert Hänggi <[hidden email]>
> wrote:
>
>> 2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> > On 27 February 2017 at 22:14, Robert Hänggi <[hidden email]>
>> > wrote:
>> >
>> >> Apropos inconsistency:
>> >> 'peak returns a single value for stereo tracks whereas 'rms returns an
>> >> array of two values.
>> >>
>> >
>> > What do you suggest?
>> >
>>
>> 1. level values per channel for both, peak and rms
>> 2. returned as lists, not as arrays since the latter is poorly
>> implemented in XLisp.
>>
>
> I agree with point 1, but not point 2.
>
> Arrays in XLISP are less feature rich than lists, and less feature rich
> than in most other LISP dialects, but I'm not aware of any bugs, so I'd not
> describe them as "poorly implemented".
>
> Lists tend to imply a collection of "things", where we can add and remove
> an arbitrary number of items, whereas an array tends to imply a "thing" as
> a whole. For example, we can consider an audio track as "a thing" and we
> represent a stereo track as an array. On the other hand we treat clips as a
> list. So for a stereo track, we can have an array of lists, where the two
> elements of the array represent the two audio channels, and each element is
> a list of clips.
>
> Thus:
> (aref *track* 0) is the left channel of a selected stereo wave track.
> (aref (get '*track* 'clips) 0) is a list of clips in the left channel.
> (aref (get '*selection* 'rms) 0) is the RMS level of the left channel,
> and potentially
> (aref (get '*selection* 'peak) 0) would be the peak level of the left
> channel.
>
> What I would ideally like to do, is to retain the "plugin" and "peak-level"
> properties as deprecated legacy code, and have "plug-in" and "peak" as the
> preferred forms, with "peak" being an array in the case of stereo tracks.
>
> I've approached the release manager about doing this for 2.1.3, but we're
> already late with this release, and it's the RMs mandate to decide.
>
> Steve
>
>
>
>>
>> Robert
>>
>> > Steve
>> >
>> >
>> >>
>> >> Robert
>> >>
>> >> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> > Thanks for pointing out the floor with the version check.
>> >> >
>> >> > It is probably better to use something like
>> >> >
>> >> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version)
>> >> > '(100
>> >> > 10
>> >> > 1)))))
>> >> >
>> >> > provided that the second and third numbers won't ever be greater
>> >> > nine...
>> >> ;)
>> >> > Robert
>> >> >
>> >> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <[hidden email]>:
>> >> >> I thought it would be logical to name the folder locations
>> >> >> 'plug-ins'
>> >> >> since the folders themselves are all plural.
>> >> >>
>> >> >> Regarding channel allocation, we could consider calling them "Front
>> >> >> Left", "Front Center" etc.
>> >> >> This should be compatible with multi channel definition in the long
>> >> >> run.
>> >> >> Although no actual naming convention exists that I would be aware
>> >> >> of.
>> >> >>
>> >> >> Robert
>> >> >>
>> >> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <
>> [hidden email]
>> >> >:
>> >> >>> On 27 February 2017 at 15:05, Robert Hänggi <
>> [hidden email]>
>> >> >>> wrote:
>> >> >>>> Yes, very inconvenient, more so as other names has changed as
>> >> >>>> well,
>> >> >>>> like 'peak-level' to 'peak'.
>> >> >>>> It means that all my plug-ins (that use properties) have to
>> >> >>>> include
>> >> >>>> a
>> >> >>>> version query.
>> >> >>>>
>> >> >>>> That's harder than it seems.
>> >> >>>> The only satisfying solution so far is:
>> >> >>>> ; test for version greater equals 2.1.3
>> >> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity* 'version)
>> '(2
>> >> >>>> 1
>> >> >>>> 3)))))
>> >> >>>>
>> >> >>>> Do you have a simpler solution?
>> >> >>>
>> >> >>> I think that test will fail if the next version is called Audacity
>> >> >>> 2.2.0.
>> >> >>>
>> >> >>> If you try to "Get" a property value that does not exist, it will
>> >> return
>> >> >>> "NIL".
>> >> >>> So, if for example, we add a new property list item part way
>> >> >>> through
>> >> >>> the 2.1.4 development cycle, you can start using it straight away
>> >> >>> provided that you handle to possibility of the property not being
>> >> >>> available in some versions of Audacity.
>> >> >>>
>> >> >>> For example:
>> >> >>>
>> >> >>> (if (not (setf rms (get '*selection* 'rms)))
>> >> >>>     (throw 'err "Audacity version not supported"))
>> >> >>>
>> >> >>> or of course you could provide a legacy function to calculate the
>> >> >>> RMS.
>> >> >>>
>> >> >>>>
>> >> >>>> I'm not so sure that  documentation/manual recommendations should
>> >> >>>> have
>> >> >>>> such an impact on pure LISP syntax, especially when the tendency
>> >> >>>> goes
>> >> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>> >> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>> >> >>>
>> >> >>> Well this is the problem. We are currently in freeze so any
>> >> >>> changes
>> >> >>> have to go through the release manager.
>> >> >>> We could discuss the comparative merits of singular or plural, but
>> >> >>> a
>> >> >>> decision needs to be made. If we put off making that decision, the
>> >> >>> greater the likelihood of breaking user's custom plug-ins. It
>> >> >>> would
>> >> >>> be
>> >> >>> 'possible' to allow multiple versions, say "plugin" or "plugins"
>> >> >>> or
>> >> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we need
>> to
>> >> >>> take that approach for syntax that has been around for a long
>> >> >>> time,
>> >> >>> such as using "real" for slider widgets that take float values,
>> >> >>> but
>> >> >>> generally it's much cleaner to have just one "correct" syntax.
>> >> >>>
>> >> >>> I don't want to be incrementing the Nyquist plug-in version number
>> >> >>> with every release, because each time we increment the version
>> number
>> >> >>> requires adding conditionals in Audacity to determine how to
>> >> >>> correctly
>> >> >>> parse the code. On the other hand, I don't think it's practical to
>> >> >>> wait until we have a frozen specification before we make new
>> features
>> >> >>> available.
>> >> >>>
>> >> >>> Clearly we do want to keep changes to existing syntax to a
>> >> >>> minimum,
>> >> >>> but I think we need to accept that new additions may be subject to
>> >> >>> change.
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> I like the additions, such as RMS.
>> >> >>>> If possible, I would also like to see:
>> >> >>>> - '*track* --> orientation Left Right Mono.
>> >> >>>
>> >> >>> Although we've had track channel allocation in this way for a long
>> >> >>> time, I'm uncertain how much longer we will use it. For
>> >> >>> left/right,
>> >> >>> all we really need is "pan". For multi-channel sound we need more
>> >> >>> flexible channel allocation. I think it's quite possible that
>> >> >>> track
>> >> >>> channel allocation could change, and we wouldn't want to introduce
>> >> >>> this new property now for it to then be obsolete in a release or
>> two.
>> >> >>>
>> >> >>>> - '*project* --> zoom (i.e. step size for arrow key movement at
>> >> >>>> current zoom factor).
>> >> >>>
>> >> >>> I don't know how or if that would work with Paul's proposed "Fish
>> >> >>> Eye"
>> >> >>> view, so perhaps best to hold off that for now,
>> >> >>>
>> >> >>>>
>> >> >>>> Well, there are others... ;)
>> >> >>>
>> >> >>> Let's discus on the Nyquist forum board. The property lists can
>> >> >>> certainly be extended.
>> >> >>>
>> >> >>> Steve
>> >> >>>
>> >> >>>>
>> >> >>>> Thanks for keeping Nyquist rocking.
>> >> >>>>
>> >> >>>> Robert
>> >> >>>>
>> >> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>> >> >>>> <[hidden email]>:
>> >> >>>>> The documentation dated May 2015
>> >> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>> >> Reference#.2ASYSTEM-DIR.2A)
>> >> >>>>> says it should be hyphenated "plug-in", which is in line with
>> >> >>>>> policy
>> >> >>>>> on consistency as set out on the wiki
>> >> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_Elements
>> ).
>> >> >>>>>
>> >> >>>>> I'm glad you brought this up as I see there are places where the
>> >> >>>>> documentation has been incorrectly updated at various times and
>> >> >>>>> contradicts itself. Unless there has been another change of
>> >> >>>>> mind,
>> >> I'll
>> >> >>>>> go through and update as necessary over the next couple of days.
>> >> >>>>>
>> >> >>>>> My understanding is that it has been agreed that we consistently
>> >> >>>>> use
>> >> >>>>> the hyphenated form of "plug-in".
>> >> >>>>>
>> >> >>>>> Due to the number of old plug-in in the wild, both the
>> >> >>>>> hyphenated
>> >> >>>>> and
>> >> >>>>> non-hyphenated forms are currently supported in the header
>> >> >>>>> ";nyquist
>> >> >>>>> plug-in".
>> >> >>>>>
>> >> >>>>> Sorry about the inconvenience Robert.
>> >> >>>>>
>> >> >>>>> Steve
>> >> >>>>>
>> >> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>> >> >>>>> <[hidden email]
>> >> >
>> >> >>>>> wrote:
>> >> >>>>>> Hi
>> >> >>>>>>
>> >> >>>>>> Recently, a property entry of *system-dir* has changed.
>> >> >>>>>> Normally, one could get all plug-in locations in Nyquist with
>> >> >>>>>> the
>> >> >>>>>> command:
>> >> >>>>>> (get '*system-dir* 'plugin)
>> >> >>>>>> It has been changed to 'plug-in.
>> >> >>>>>>
>> >> >>>>>> Although I understand the reason, plug-ins that use this
>> >> >>>>>> information
>> >> >>>>>> won't be backwards compatible.
>> >> >>>>>>
>> >> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and was
>> >> >>>>>> somewhat surprised that they don't work anymore after a GIT
>> >> >>>>>> pull...
>> >> >>>>>>
>> >> >>>>>> Please inform if I have from now on to search for both writing
>> >> >>>>>> variants.
>> >> >>>>>>
>> >> >>>>>> Thanks
>> >> >>>>>> Robert
>> >> >>>>>>
>> >> >>>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>>> _______________________________________________
>> >> >>>>>> Audacity-quality mailing list
>> >> >>>>>> [hidden email]
>> >> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>>> Check out the vibrant tech community on one of the world's most
>> >> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>>> _______________________________________________
>> >> >>>>> Audacity-quality mailing list
>> >> >>>>> [hidden email]
>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>>>
>> >> >>>>
>> >> >>>> ------------------------------------------------------------
>> >> ------------------
>> >> >>>> Check out the vibrant tech community on one of the world's most
>> >> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>>> _______________________________________________
>> >> >>>> Audacity-quality mailing list
>> >> >>>> [hidden email]
>> >> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>> ------------------------------------------------------------
>> >> ------------------
>> >> >>> Check out the vibrant tech community on one of the world's most
>> >> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> >>> _______________________________________________
>> >> >>> Audacity-quality mailing list
>> >> >>> [hidden email]
>> >> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >> ------------------------------------------------------------
>> >> ------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changed Property in Nyquist

Robert Hänggi
Sounds fine to me, Steve.

My Nyquist-Reference plug-in works again as intended, without version checking.
I'm personally favouring plug-in over plugin More so as my screen
reader tends to pronounce the latter like "bludgeon". :D

The only problem I'm facing is that earlier 2.1.3 alphas will pass the
version check although e.g. rms is not available there. Thus, still
individual checking required.
Perhaps we can also in 2.2.0 add a build date or so under the
*audacity* property.

Thanks
Robert

2017-03-01 19:49 GMT+01:00, Steve the Fiddle <[hidden email]>:

> Having discussed this with James (RM), I've committed a couple of small
> changes to resolve issues raised by Robert.
>
> https://github.com/audacity/audacity/commit/f19b79f5c
> This commit is mostly updating code comments to use the hyphenated form of
> "plug-ins" consistently within Nyquist.cpp.
> The two functional changes are:
>
> 1) The error message:
> "Bad Nyquist 'control' type specification: '%s' in plugin file
> '%s'.\nControl
> not created."
> has been updated to:
> "Bad Nyquist 'control' type specification: '%s' in plug-in file
> '%s'.\nControl not created."
>
> 2) The *SYSTEM_DIR* property "PLUGIN" has been restored as legacy syntax so
> as to not break existing plug-ins.
> The preferred syntax is to use "PLUG-IN".
>
>
> https://github.com/audacity/audacity/commit/b66675d71
> This commit restores the *SELECTION* PEAK-LEVEL property.
> I've marked this as "deprecated" in a code comment, though we could decide
> later to retain it under a different name such as MULTICHAN-PEAK.
> The preferred syntax for now is:
> *SELECTION* PEAK
> which returns peak level per channel, either as a single number for mono
> tracks, or an array of two numbers for a stereo track.
>
>
> The documentation (which is on the wiki) still needs updating, and I aim to
> do that over the next few days.
> I'm not anticipating any further changes to Nyquist before 2.1.3 is
> released.
>
> Steve
>
>
> On 1 March 2017 at 15:03, Steve the Fiddle <[hidden email]>
> wrote:
>
>>
>>
>> On 1 March 2017 at 13:43, Robert Hänggi <[hidden email]> wrote:
>>
>>> Hi Steve
>>>
>>> I see arrays as poorly implemented because their only feature is
>>> referencing values.
>>> You cannot simply add, subtract or apply another function to it.
>>> Roger implemented a lot of helper functions to achieve this when the
>>> array item is a sound, e.g. sum-of-arrays or multichannel-max.
>>> To get the highest peak of an x-channel sound you have to write a loop
>>> (looking forward in future).
>>> For a list, you would simply write
>>> (apply 'max (get '*selection* 'peak))
>>>
>>
>> Multichannel-max is just a LISP loop (undocumented in the Nyquist
>> manual).
>> We could easily add an "array-max" LISP function if we decided it was
>> sufficiently useful, or a more general  "apply-array".
>>
>> SUM, DIFF and MULT already work on numeric arrays.
>>
>> I expect that we will be treating multi-channel sounds as an array of
>> sounds for quite some time to come, as that's how stand-alone Nyquist
>> deals
>> with multi-channel sounds, so it seems logical to me to treat references
>> to
>> multi-channel sounds, such as peak or RMS levels, in a similar manner. So
>> if "my-sound" is an array of sounds, and "my-peak" is an array peak
>> levels
>> of that sound, and "my-rms" is an array of RMS values, then (aref
>> my-sound
>> n) has a peak level of (aref my-peak n) and an RMS level of (aref my-rms
>> n). I much prefer that to a mix of arrays and lists and having to
>> remember
>> which is an array and which a list.
>>
>>
>>
>>>
>>> (works also for a mono track, if the single value is embedded in a
>>> list as well.)
>>>
>>> Or imagine sorting a 7.1 multichannel track rms/peak array...
>>>
>>> Anyway, I can deal with wither solution, simple or complicated.
>>>
>>> Thanks for having passed it to James.
>>>
>>
>> Well it was due to a bit of a misunderstanding that it was committed when
>> it was, but James has given me the OK (off-list) to address the breakages
>> and keep the RMS property. I'll let you know when I've updated the
>> documentation so that you get chance to check it before 2.1.3 is
>> released.
>>
>> Steve
>>
>>
>>>
>>> Robert
>>>
>>> 2017-03-01 13:31 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>> > On 28 February 2017 at 05:51, Robert Hänggi <[hidden email]>
>>> > wrote:
>>> >
>>> >> 2017-02-28 2:10 GMT+01:00, Steve the Fiddle <[hidden email]
>>> >:
>>> >> > On 27 February 2017 at 22:14, Robert Hänggi
>>> >> > <[hidden email]
>>> >
>>> >> > wrote:
>>> >> >
>>> >> >> Apropos inconsistency:
>>> >> >> 'peak returns a single value for stereo tracks whereas 'rms
>>> >> >> returns
>>> an
>>> >> >> array of two values.
>>> >> >>
>>> >> >
>>> >> > What do you suggest?
>>> >> >
>>> >>
>>> >> 1. level values per channel for both, peak and rms
>>> >> 2. returned as lists, not as arrays since the latter is poorly
>>> >> implemented in XLisp.
>>> >>
>>> >
>>> > I agree with point 1, but not point 2.
>>> >
>>> > Arrays in XLISP are less feature rich than lists, and less feature
>>> > rich
>>> > than in most other LISP dialects, but I'm not aware of any bugs, so
>>> > I'd
>>> not
>>> > describe them as "poorly implemented".
>>> >
>>> > Lists tend to imply a collection of "things", where we can add and
>>> remove
>>> > an arbitrary number of items, whereas an array tends to imply a
>>> > "thing"
>>> as
>>> > a whole. For example, we can consider an audio track as "a thing" and
>>> > we
>>> > represent a stereo track as an array. On the other hand we treat clips
>>> as a
>>> > list. So for a stereo track, we can have an array of lists, where the
>>> two
>>> > elements of the array represent the two audio channels, and each
>>> element is
>>> > a list of clips.
>>> >
>>> > Thus:
>>> > (aref *track* 0) is the left channel of a selected stereo wave track.
>>> > (aref (get '*track* 'clips) 0) is a list of clips in the left channel.
>>> > (aref (get '*selection* 'rms) 0) is the RMS level of the left channel,
>>> > and potentially
>>> > (aref (get '*selection* 'peak) 0) would be the peak level of the left
>>> > channel.
>>> >
>>> > What I would ideally like to do, is to retain the "plugin" and
>>> "peak-level"
>>> > properties as deprecated legacy code, and have "plug-in" and "peak" as
>>> the
>>> > preferred forms, with "peak" being an array in the case of stereo
>>> tracks.
>>> >
>>> > I've approached the release manager about doing this for 2.1.3, but
>>> we're
>>> > already late with this release, and it's the RMs mandate to decide.
>>> >
>>> > Steve
>>> >
>>> >
>>> >
>>> >>
>>> >> Robert
>>> >>
>>> >> > Steve
>>> >> >
>>> >> >
>>> >> >>
>>> >> >> Robert
>>> >> >>
>>> >> >> 2017-02-27 18:19 GMT+01:00, Robert Hänggi <[hidden email]
>>> >:
>>> >> >> > Thanks for pointing out the floor with the version check.
>>> >> >> >
>>> >> >> > It is probably better to use something like
>>> >> >> >
>>> >> >> > (print (<= 213 (apply #'+ (mapcar #'* (get '*audacity* 'version)
>>> >> >> > '(100
>>> >> >> > 10
>>> >> >> > 1)))))
>>> >> >> >
>>> >> >> > provided that the second and third numbers won't ever be greater
>>> >> >> > nine...
>>> >> >> ;)
>>> >> >> > Robert
>>> >> >> >
>>> >> >> > 2017-02-27 17:48 GMT+01:00, Robert Hänggi <
>>> [hidden email]>:
>>> >> >> >> I thought it would be logical to name the folder locations
>>> >> >> >> 'plug-ins'
>>> >> >> >> since the folders themselves are all plural.
>>> >> >> >>
>>> >> >> >> Regarding channel allocation, we could consider calling them
>>> "Front
>>> >> >> >> Left", "Front Center" etc.
>>> >> >> >> This should be compatible with multi channel definition in the
>>> long
>>> >> >> >> run.
>>> >> >> >> Although no actual naming convention exists that I would be
>>> >> >> >> aware
>>> >> >> >> of.
>>> >> >> >>
>>> >> >> >> Robert
>>> >> >> >>
>>> >> >> >> 2017-02-27 17:25 GMT+01:00, Steve the Fiddle <
>>> >> [hidden email]
>>> >> >> >:
>>> >> >> >>> On 27 February 2017 at 15:05, Robert Hänggi <
>>> >> [hidden email]>
>>> >> >> >>> wrote:
>>> >> >> >>>> Yes, very inconvenient, more so as other names has changed as
>>> >> >> >>>> well,
>>> >> >> >>>> like 'peak-level' to 'peak'.
>>> >> >> >>>> It means that all my plug-ins (that use properties) have to
>>> >> >> >>>> include
>>> >> >> >>>> a
>>> >> >> >>>> version query.
>>> >> >> >>>>
>>> >> >> >>>> That's harder than it seems.
>>> >> >> >>>> The only satisfying solution so far is:
>>> >> >> >>>> ; test for version greater equals 2.1.3
>>> >> >> >>>> (print (eval (cons #'and (mapcar #'>= (get '*audacity*
>>> 'version)
>>> >> '(2
>>> >> >> >>>> 1
>>> >> >> >>>> 3)))))
>>> >> >> >>>>
>>> >> >> >>>> Do you have a simpler solution?
>>> >> >> >>>
>>> >> >> >>> I think that test will fail if the next version is called
>>> Audacity
>>> >> >> >>> 2.2.0.
>>> >> >> >>>
>>> >> >> >>> If you try to "Get" a property value that does not exist, it
>>> will
>>> >> >> return
>>> >> >> >>> "NIL".
>>> >> >> >>> So, if for example, we add a new property list item part way
>>> >> >> >>> through
>>> >> >> >>> the 2.1.4 development cycle, you can start using it straight
>>> away
>>> >> >> >>> provided that you handle to possibility of the property not
>>> being
>>> >> >> >>> available in some versions of Audacity.
>>> >> >> >>>
>>> >> >> >>> For example:
>>> >> >> >>>
>>> >> >> >>> (if (not (setf rms (get '*selection* 'rms)))
>>> >> >> >>>     (throw 'err "Audacity version not supported"))
>>> >> >> >>>
>>> >> >> >>> or of course you could provide a legacy function to calculate
>>> the
>>> >> >> >>> RMS.
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> I'm not so sure that  documentation/manual recommendations
>>> should
>>> >> >> >>>> have
>>> >> >> >>>> such an impact on pure LISP syntax, especially when the
>>> tendency
>>> >> >> >>>> goes
>>> >> >> >>>> towards "plugins" as in Steinberg's "VST Plugins" folder.
>>> >> >> >>>> But if you must change, make it "plug-ins" and not "plug-in".
>>> >> >> >>>
>>> >> >> >>> Well this is the problem. We are currently in freeze so any
>>> >> >> >>> changes
>>> >> >> >>> have to go through the release manager.
>>> >> >> >>> We could discuss the comparative merits of singular or plural,
>>> but
>>> >> >> >>> a
>>> >> >> >>> decision needs to be made. If we put off making that decision,
>>> the
>>> >> >> >>> greater the likelihood of breaking user's custom plug-ins. It
>>> >> >> >>> would
>>> >> >> >>> be
>>> >> >> >>> 'possible' to allow multiple versions, say "plugin" or
>>> >> >> >>> "plugins"
>>> >> >> >>> or
>>> >> >> >>> "plug-in" or "plug-ins", but that soon gets messy. I think we
>>> need
>>> >> to
>>> >> >> >>> take that approach for syntax that has been around for a long
>>> >> >> >>> time,
>>> >> >> >>> such as using "real" for slider widgets that take float
>>> >> >> >>> values,
>>> >> >> >>> but
>>> >> >> >>> generally it's much cleaner to have just one "correct" syntax.
>>> >> >> >>>
>>> >> >> >>> I don't want to be incrementing the Nyquist plug-in version
>>> number
>>> >> >> >>> with every release, because each time we increment the version
>>> >> number
>>> >> >> >>> requires adding conditionals in Audacity to determine how to
>>> >> >> >>> correctly
>>> >> >> >>> parse the code. On the other hand, I don't think it's
>>> >> >> >>> practical
>>> to
>>> >> >> >>> wait until we have a frozen specification before we make new
>>> >> features
>>> >> >> >>> available.
>>> >> >> >>>
>>> >> >> >>> Clearly we do want to keep changes to existing syntax to a
>>> >> >> >>> minimum,
>>> >> >> >>> but I think we need to accept that new additions may be
>>> >> >> >>> subject
>>> to
>>> >> >> >>> change.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> I like the additions, such as RMS.
>>> >> >> >>>> If possible, I would also like to see:
>>> >> >> >>>> - '*track* --> orientation Left Right Mono.
>>> >> >> >>>
>>> >> >> >>> Although we've had track channel allocation in this way for a
>>> long
>>> >> >> >>> time, I'm uncertain how much longer we will use it. For
>>> >> >> >>> left/right,
>>> >> >> >>> all we really need is "pan". For multi-channel sound we need
>>> more
>>> >> >> >>> flexible channel allocation. I think it's quite possible that
>>> >> >> >>> track
>>> >> >> >>> channel allocation could change, and we wouldn't want to
>>> introduce
>>> >> >> >>> this new property now for it to then be obsolete in a release
>>> >> >> >>> or
>>> >> two.
>>> >> >> >>>
>>> >> >> >>>> - '*project* --> zoom (i.e. step size for arrow key movement
>>> >> >> >>>> at
>>> >> >> >>>> current zoom factor).
>>> >> >> >>>
>>> >> >> >>> I don't know how or if that would work with Paul's proposed
>>> "Fish
>>> >> >> >>> Eye"
>>> >> >> >>> view, so perhaps best to hold off that for now,
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> Well, there are others... ;)
>>> >> >> >>>
>>> >> >> >>> Let's discus on the Nyquist forum board. The property lists
>>> >> >> >>> can
>>> >> >> >>> certainly be extended.
>>> >> >> >>>
>>> >> >> >>> Steve
>>> >> >> >>>
>>> >> >> >>>>
>>> >> >> >>>> Thanks for keeping Nyquist rocking.
>>> >> >> >>>>
>>> >> >> >>>> Robert
>>> >> >> >>>>
>>> >> >> >>>> 2017-02-27 14:22 GMT+01:00, Steve the Fiddle
>>> >> >> >>>> <[hidden email]>:
>>> >> >> >>>>> The documentation dated May 2015
>>> >> >> >>>>> (http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_
>>> >> >> Reference#.2ASYSTEM-DIR.2A)
>>> >> >> >>>>> says it should be hyphenated "plug-in", which is in line
>>> >> >> >>>>> with
>>> >> >> >>>>> policy
>>> >> >> >>>>> on consistency as set out on the wiki
>>> >> >> >>>>> (http://alphamanual.audacityteam.org/man/Consistency#GUI_
>>> Elements
>>> >> ).
>>> >> >> >>>>>
>>> >> >> >>>>> I'm glad you brought this up as I see there are places where
>>> the
>>> >> >> >>>>> documentation has been incorrectly updated at various times
>>> and
>>> >> >> >>>>> contradicts itself. Unless there has been another change of
>>> >> >> >>>>> mind,
>>> >> >> I'll
>>> >> >> >>>>> go through and update as necessary over the next couple of
>>> days.
>>> >> >> >>>>>
>>> >> >> >>>>> My understanding is that it has been agreed that we
>>> consistently
>>> >> >> >>>>> use
>>> >> >> >>>>> the hyphenated form of "plug-in".
>>> >> >> >>>>>
>>> >> >> >>>>> Due to the number of old plug-in in the wild, both the
>>> >> >> >>>>> hyphenated
>>> >> >> >>>>> and
>>> >> >> >>>>> non-hyphenated forms are currently supported in the header
>>> >> >> >>>>> ";nyquist
>>> >> >> >>>>> plug-in".
>>> >> >> >>>>>
>>> >> >> >>>>> Sorry about the inconvenience Robert.
>>> >> >> >>>>>
>>> >> >> >>>>> Steve
>>> >> >> >>>>>
>>> >> >> >>>>> On 27 February 2017 at 12:22, Robert Hänggi
>>> >> >> >>>>> <[hidden email]
>>> >> >> >
>>> >> >> >>>>> wrote:
>>> >> >> >>>>>> Hi
>>> >> >> >>>>>>
>>> >> >> >>>>>> Recently, a property entry of *system-dir* has changed.
>>> >> >> >>>>>> Normally, one could get all plug-in locations in Nyquist
>>> >> >> >>>>>> with
>>> >> >> >>>>>> the
>>> >> >> >>>>>> command:
>>> >> >> >>>>>> (get '*system-dir* 'plugin)
>>> >> >> >>>>>> It has been changed to 'plug-in.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Although I understand the reason, plug-ins that use this
>>> >> >> >>>>>> information
>>> >> >> >>>>>> won't be backwards compatible.
>>> >> >> >>>>>>
>>> >> >> >>>>>> I'm just creating a suite of 14 accessibility plug-ins and
>>> was
>>> >> >> >>>>>> somewhat surprised that they don't work anymore after a GIT
>>> >> >> >>>>>> pull...
>>> >> >> >>>>>>
>>> >> >> >>>>>> Please inform if I have from now on to search for both
>>> writing
>>> >> >> >>>>>> variants.
>>> >> >> >>>>>>
>>> >> >> >>>>>> Thanks
>>> >> >> >>>>>> Robert
>>> >> >> >>>>>>
>>> >> >> >>>>>> ------------------------------------------------------------
>>> >> >> ------------------
>>> >> >> >>>>>> Check out the vibrant tech community on one of the world's
>>> most
>>> >> >> >>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> >> >>>>>> _______________________________________________
>>> >> >> >>>>>> Audacity-quality mailing list
>>> >> >> >>>>>> [hidden email]
>>> >> >> >>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-qualit
>>> y
>>> >> >> >>>>>
>>> >> >> >>>>> ------------------------------------------------------------
>>> >> >> ------------------
>>> >> >> >>>>> Check out the vibrant tech community on one of the world's
>>> most
>>> >> >> >>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> >> >>>>> _______________________________________________
>>> >> >> >>>>> Audacity-quality mailing list
>>> >> >> >>>>> [hidden email]
>>> >> >> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >> >> >>>>>
>>> >> >> >>>>
>>> >> >> >>>> ------------------------------------------------------------
>>> >> >> ------------------
>>> >> >> >>>> Check out the vibrant tech community on one of the world's
>>> >> >> >>>> most
>>> >> >> >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> >> >>>> _______________________________________________
>>> >> >> >>>> Audacity-quality mailing list
>>> >> >> >>>> [hidden email]
>>> >> >> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >> >> >>>
>>> >> >> >>> ------------------------------------------------------------
>>> >> >> ------------------
>>> >> >> >>> Check out the vibrant tech community on one of the world's
>>> >> >> >>> most
>>> >> >> >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> >> >>> _______________________________________________
>>> >> >> >>> Audacity-quality mailing list
>>> >> >> >>> [hidden email]
>>> >> >> >>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >> ------------------------------------------------------------
>>> >> >> ------------------
>>> >> >> Check out the vibrant tech community on one of the world's most
>>> >> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> >> _______________________________________________
>>> >> >> Audacity-quality mailing list
>>> >> >> [hidden email]
>>> >> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >> >>
>>> >> >
>>> >>
>>> >> ------------------------------------------------------------
>>> >> ------------------
>>> >> Check out the vibrant tech community on one of the world's most
>>> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> >> _______________________________________________
>>> >> Audacity-quality mailing list
>>> >> [hidden email]
>>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >>
>>> >
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...