Testing the code from the Nyquist manual

3 messages Options
Embed this post
Permalink
edgar-rft

Testing the code from the Nyquist manual

Reply Threaded More More options
Print post
Permalink
Question to Dave Storer (and everybody else who is interested):

I would be willing to test the code from the Nyquist manual with all
the things Roger told me in the last few hours. I still hope we will
only need to write up some things like:

If you try the examples from the Nyquist manual in Audacity, write
(abs-env ... code ...) instead of ... manual-code ...

If you tell me what your most important questions are I will start
with them first (but first I will sleep for some hours now).

Maybe I will learn some SAL that way?  Who knows ...

- edgar
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist
Roger Dannenberg

Re: Testing the code from the Nyquist manual

Reply Threaded More More options
Print post
Permalink
[hidden email] wrote:
> Question to Dave Storer (and everybody else who is interested):
>
> I would be willing to test the code from the Nyquist manual with all
> the things Roger told me in the last few hours. I still hope we will
> only need to write up some things like:
>
> If you try the examples from the Nyquist manual in Audacity, write
> (abs-env ... code ...) instead of ... manual-code ...
>  
Or maybe the examples in the Nyquist manual should work without abs-env.
The original concept of Nyquist was that everyone would write behaviors
that could then be used in many contexts. Of course, it's much easier to
write code that works for a particular test case (the default
environment) than for the general case, so in practice, there's a lot of
code that doesn't work when stretched. Also, I've found this whole idea
of using transformations to implicitly stretch and shift is great for
simple examples, but at some point I think it's easier to make durations
and time very explicit in the code and dispense with inheriting
transformations from the calling function. At least you can choose your
poison.
-Roger

> If you tell me what your most important questions are I will start
> with them first (but first I will sleep for some hours now).
>
> Maybe I will learn some SAL that way?  Who knows ...
>
> - edgar
> ______________________________________________________
>  

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist
edgar-rft

Re: Testing the code from the Nyquist manual

Reply Threaded More More options
Print post
Permalink
In reply to this post by edgar-rft
Roger wrote:
> Or maybe the examples in the Nyquist manual should work without abs-env.

Most of the examples in deed DO work without abs-env. Dave hat asked me
some questions about the "time transformation" chapter in the Nyquist manual
where most of the examples there do NOT work "out of the box" in Audacity.
I stupidly have deleted the mails and can't remember the exact questions...

> The original concept of Nyquist was that everyone would write behaviors
> that could then be used in many contexts. Of course, it's much easier to
> write code that works for a particular test case (the default
> environment) than for the general case, so in practice, there's a lot of
> code that doesn't work when stretched. Also, I've found this whole idea
> of using transformations to implicitly stretch and shift is great for
> simple examples, but at some point I think it's easier to make durations
> and time very explicit in the code and dispense with inheriting
> transformations from the calling function. At least you can choose your
> poison.

I'm working with all sorts of music instruments and recording machines
since nearly 30 years now and I still find every year some details
I didn't knew before.

The same way it will probably not be possible to create a sound
programming environment that really covers all imaginable
(and un-imaginable?) cases.

On the other hand, this is what makes sound and music so interesting.
We will hopefully never get bored until the end of our lives...

- edgar





-- 
The author of this email does not necessarily endorse the
following advertisements, which are the sole responsibility
of the advertiser:

________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Audacity-nyquist mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist