Undocumented features and the Audacity Nyquist time transformation environment

[edgar-rft]

Hi all on the Audacity Nyquist list,

Summary of some recent questions on this list:

Steve: Any other undocumented features that you know of?

Leland:
;codetype lisp | sal ...
;debugflags trace | notrace | compiler | nocompiler ...

Edgar: I will add this to my Audacity Nyquist pages ASAP.

Steve: Is there any information about using SAL in Audacity?

Leland: I was sort of hoping Edgar might add it to his site.

Edgar: The bad news is that I do not use SAL and therefore have no
idea how it works. I very often have to use the Nyquist low-level
interface directly where (for me) SAL introduces nothing but
additional complications (more details below).

Steve: Are there any advantages to using SAL?

Leland: Much easier to grok for us Lisp challenged ppl. :-)

Edgar: This is definetly true (and probably the main reason for adding
a SAL compiler to Nyquist), a second reason is that SAL makes Nyquist
more compatible to other music composition programming environments like
"common music" (Rick Taube) and the "snd" editor (Bill Schottstaedt).

I also want to say that I do not think of Lisp as the automatically
"best language for every purpose", but in case of Nyquist the sound
functions are nested deep into the Lisp interpreter (especially the
"lazy evaluation" backtracking system), so that the "most easy" way
to deal with the Nyquist low-level interface (the "snd-..." functions)
is XLISP and not SAL (what is probably possible, too).

This means that I have nothing "against" SAL but for me SAL is not
really useful and therefore I just simply have no idea how it works
in detail. That's the reason why there is still no documentation.

--- Audacity Nyquist time transformation environment ---

One of the main reasons why I have to use the low-level interface
directly is that the Nyquist time transformation environment in
Audacity is messed up by setting the logical time of "1.0" to the
length of the Audacity selection instead of "1.0 seconds".

I agree with Roger that this is very useful for music composition
(Audacity "generate" plugins) where you can write Nyquist code like:

XLISP: (compute-sound 1.0)
SAL: computeSound(1.0)

and you will automatically get a sound of a length that fits right
into the Audacity selection.

But on the other side is pure pain to work this way in audio processing
(Audacity "process" plugins) where delays in time units of seconds are
needed for echo compensation and similar stuff, which every time needed
to be computed out of the "wrong" selection-length time units.

And as a result of this:

Nyquist "audio process" code, developed in CMU-Nyquist cannot be used
in Audacity because of the different interpretation of time units.

This makes CMU-Nyquist incompatible to Nyquist in Audacity.

In "old" Nyquist versions there very often was the additional problem
that XLISP floats with only six digits precision introduced so much
miscalculation, that computing exact delay shifts in microseconds in
Audacity was nearly impossible.

Newer versions of Nyquist (like Nyquist 3.03, used in the current
Audacity 1.3.x versions we are talking about here) use native machine
floats so this is not a real problem any more but computing with
messed-up time units is still incompatible and over-complicated.

I don't know wether the following is a really good idea but:

IMHO it would be a much better solution to leave the "len" variable
as-is and write some XLISP (or SAL) high-level functions to compute
the particular length of the current Auacity selection to be used in
"generate" plugins and make the rest of the time transformation
environment behaving the same way as used in CMU-Nyquist.

This would make Nyquist in Audacity being compatible to CMU-Nyquist.

Because I have no exact idea how much this breaks the code of already
existing Nyquist "generate" plugins (like "click-track" etc.) I would
first of all like to know what the other people on this list think
about this idea. Herewith I volunteer to help with fixing all broken
Nyquist plugins.

I would be interested to know what the others think about this...

Thanks,

- 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

[Stevethefiddle]

Re. Audacity Nyquist time transformation environment

This is one part of Nyquist that makes me break out in a cold sweat and
I've still not really got to grips with it yet.

Agreed it is really confusing that Audacity Nyquist is incompatible with
CMU-Nyquist in this respect. Would your suggestion mean that when
writing plug-ins Audacity-Nyquist would behave as described in the
CMU-Nyquist manual, or would this depend on whether it is a process or
generate type?

If it means that when writing a generate type plug-in that a time unit
of 1.0 is the selection, but when writing a process type plug-in a time
unit of 1.0 is 1 second, then that would probably be more confusing than
the current situation.

As for things it would break - apart from existing plug-ins, Leland's
Nyquist Workbench would probably need an update.

There's quite a lot of Generate type plug-ins here:
http://audacity.sourceforge.net/download/nyquistplugins
and I think that David Sky is currently working on another one.

Compatibility with CMU-Nyquist would seem to me to be a good thing, (I
don't think it's likely that anyone is going to write an
Audacity-Nyquist manual any time soon), but I really don't know enough
about it to express an opinion as to whether it is really the best thing
to do.

Steve


On Wed, 2009-09-23 at 20:06 +0200, [hidden email] wrote:

> Hi all on the Audacity Nyquist list,
>
> Summary of some recent questions on this list:
>
> Steve: Any other undocumented features that you know of?
>
> Leland:
> ;codetype lisp | sal ...
> ;debugflags trace | notrace | compiler | nocompiler ...
>
> Edgar: I will add this to my Audacity Nyquist pages ASAP.
>
> Steve: Is there any information about using SAL in Audacity?
>
> Leland: I was sort of hoping Edgar might add it to his site.
>
> Edgar: The bad news is that I do not use SAL and therefore have no
> idea how it works. I very often have to use the Nyquist low-level
> interface directly where (for me) SAL introduces nothing but
> additional complications (more details below).
>
> Steve: Are there any advantages to using SAL?
>
> Leland: Much easier to grok for us Lisp challenged ppl. :-)
>
> Edgar: This is definetly true (and probably the main reason for adding
> a SAL compiler to Nyquist), a second reason is that SAL makes Nyquist
> more compatible to other music composition programming environments like
> "common music" (Rick Taube) and the "snd" editor (Bill Schottstaedt).
>
> I also want to say that I do not think of Lisp as the automatically
> "best language for every purpose", but in case of Nyquist the sound
> functions are nested deep into the Lisp interpreter (especially the
> "lazy evaluation" backtracking system), so that the "most easy" way
> to deal with the Nyquist low-level interface (the "snd-..." functions)
> is XLISP and not SAL (what is probably possible, too).
>
> This means that I have nothing "against" SAL but for me SAL is not
> really useful and therefore I just simply have no idea how it works
> in detail. That's the reason why there is still no documentation.
>
> --- Audacity Nyquist time transformation environment ---
>
> One of the main reasons why I have to use the low-level interface
> directly is that the Nyquist time transformation environment in
> Audacity is messed up by setting the logical time of "1.0" to the
> length of the Audacity selection instead of "1.0 seconds".
>
> I agree with Roger that this is very useful for music composition
> (Audacity "generate" plugins) where you can write Nyquist code like:
>
> XLISP: (compute-sound 1.0)
> SAL: computeSound(1.0)
>
> and you will automatically get a sound of a length that fits right
> into the Audacity selection.
>
> But on the other side is pure pain to work this way in audio processing
> (Audacity "process" plugins) where delays in time units of seconds are
> needed for echo compensation and similar stuff, which every time needed
> to be computed out of the "wrong" selection-length time units.
>
> And as a result of this:
>
> Nyquist "audio process" code, developed in CMU-Nyquist cannot be used
> in Audacity because of the different interpretation of time units.
>
> This makes CMU-Nyquist incompatible to Nyquist in Audacity.
>
> In "old" Nyquist versions there very often was the additional problem
> that XLISP floats with only six digits precision introduced so much
> miscalculation, that computing exact delay shifts in microseconds in
> Audacity was nearly impossible.
>
> Newer versions of Nyquist (like Nyquist 3.03, used in the current
> Audacity 1.3.x versions we are talking about here) use native machine
> floats so this is not a real problem any more but computing with
> messed-up time units is still incompatible and over-complicated.
>
> I don't know wether the following is a really good idea but:
>
> IMHO it would be a much better solution to leave the "len" variable
> as-is and write some XLISP (or SAL) high-level functions to compute
> the particular length of the current Auacity selection to be used in
> "generate" plugins and make the rest of the time transformation
> environment behaving the same way as used in CMU-Nyquist.
>
> This would make Nyquist in Audacity being compatible to CMU-Nyquist.
>
> Because I have no exact idea how much this breaks the code of already
> existing Nyquist "generate" plugins (like "click-track" etc.) I would
> first of all like to know what the other people on this list think
> about this idea. Herewith I volunteer to help with fixing all broken
> Nyquist plugins.
>
> I would be interested to know what the others think about this...
>
> Thanks,
>
> - 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

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

Hi Edgar,
    I think SAL is much easier for most people to use, and the
transition to SAL from Nyquist/XLISP is I think much easier than the
transition from, say, Java to SAL. Nyquist/XLISP users know the
semantics very well, so they only have to learn some syntax that is
already pretty familiar if you write in C or Java or Python, etc.
    SAL can call the same snd- functions as Lisp. There are a few
shortcomings in SAL, but overall I find it quite nice and surprising
that you could deal with Lisp identifiers like *env* and a-var and a=b+c
in an infix-oriented language.

> But on the other side is pure pain to work this way in audio processing
> (Audacity "process" plugins) where delays in time units of seconds are
> needed for echo compensation and similar stuff, which every time needed
> to be computed out of the "wrong" selection-length time units.
>
> And as a result of this:
>
> Nyquist "audio process" code, developed in CMU-Nyquist cannot be used
> in Audacity because of the different interpretation of time units.
>
>  

I think things are not so bad, and the semantics are really the same in
both systems. If you want the default environment (stretch by 1) in
Audacity plug-ins, you can just wrap things in (STRETCH-ABS 1 ...) or
even (ENV-ABS ...).
> In "old" Nyquist versions there very often was the additional problem
> that XLISP floats with only six digits precision introduced so much
> miscalculation, that computing exact delay shifts in microseconds in
> Audacity was nearly impossible.
>  
I don't understand this either -- Nyquist uses doubles for time, and I
do sample-accurate editing, splicing, etc. all the time. I don't think
this has changed, and sample accuracy has always been one of the
advantages of Nyquist over, say, csound. There may be an issue of
printing/reading floats: Nyquist (actually XLISP) defaults to using "%g"
to print FLONUMS, but this can be changed from within Lisp/SAL programs.
> This would make Nyquist in Audacity being compatible to CMU-Nyquist.
>
>  
I suspect this is not a compatibility issue, but a question of expected
behavior. I don't understand how either Nyquist or Audacity behave
differently or how you would like them to behave differently.
> Herewith I volunteer to help with fixing all broken
> Nyquist plugins.
>  
As always, I appreciate all your constructive input and contributions.

-Roger


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

Hi Roger and all others on the Audacity Nyquist list,

Preface: I have worked with lots of different audio and electronic
simulation software and I still think of Nyquist as the best high-level
sound programming language I ever have worked with. So please do not
misunderstand the current discussions as just another extensive nagging.

Roger: If you want the default environment (stretch by 1) in Audacity...

Edgar: yes, this is what I'm talking about

Roger: you can just wrap things in (STRETCH-ABS 1 ...) or even
(ENV-ABS ...).

Edgar: Thanks I know, but STRETCH-ABS only wraps a single behaviour and
there is no ENV-ABS function in the Nyquist Lisp code (but I assume it
stretches an encelope by an absolute value).

Furthermore I'm talking about several thousand lines of Nyquist code
and not about five-line mini plugins, and I'm not willing to re-write
several hundred lines of Lisp code every time.

Therefore just another question:

While writing an extensive answer to the previous mails I just realize
that most of the examples of the Nyquist manual work as expected if I
write as the first line of the code at the Audacity Nyquist prompt:

(setf *warp* '(0.0 1.0 nil))
... code from the Nyquist manual ...

WARNING: THIS IS A HARDCORE HACK!
DO NOT USE THIS CODE IN YOUR PLUGINS!

Because Roger probably will get instantly very dizzy in his head by
reading this code, I would like to ask wether there is an "official"
way to change the value of the *warp* variable.

This would probably solve most of my problems.

I have grepped through the Nyquist Lisp code and it seems to me that
*warp* is used as a constant internal value which never should be
changed by the user and there seems to be no Lisp function to
manipulate *warp* directly.

Is there any way to change the global warp behaviour for (say) a block
of 500 lines of lisp code as an "official" alternative to:

(let ((*warp* '(0.0 1.0 nil)))
... 500-lines-of-lisp-code ...
) ; end of let

Thanks,

- edgar



Original message was:

> Hi Edgar,
>     I think SAL is much easier for most people to use, and the
> transition to SAL from Nyquist/XLISP is I think much easier than the
> transition from, say, Java to SAL. Nyquist/XLISP users know the
> semantics very well, so they only have to learn some syntax that is
> already pretty familiar if you write in C or Java or Python, etc.
>     SAL can call the same snd- functions as Lisp. There are a few
> shortcomings in SAL, but overall I find it quite nice and surprising
> that you could deal with Lisp identifiers like *env* and a-var and a=b+c
> in an infix-oriented language.
> > But on the other side is pure pain to work this way in audio processing
> > (Audacity "process" plugins) where delays in time units of seconds are
> > needed for echo compensation and similar stuff, which every time needed
> > to be computed out of the "wrong" selection-length time units.
> >
> > And as a result of this:
> >
> > Nyquist "audio process" code, developed in CMU-Nyquist cannot be used
> > in Audacity because of the different interpretation of time units.
> >
> >  
> I think things are not so bad, and the semantics are really the same in
> both systems. If you want the default environment (stretch by 1) in
> Audacity plug-ins, you can just wrap things in (STRETCH-ABS 1 ...) or
> even (ENV-ABS ...).
> > In "old" Nyquist versions there very often was the additional problem
> > that XLISP floats with only six digits precision introduced so much
> > miscalculation, that computing exact delay shifts in microseconds in
> > Audacity was nearly impossible.
> >  
> I don't understand this either -- Nyquist uses doubles for time, and I
> do sample-accurate editing, splicing, etc. all the time. I don't think
> this has changed, and sample accuracy has always been one of the
> advantages of Nyquist over, say, csound. There may be an issue of
> printing/reading floats: Nyquist (actually XLISP) defaults to using "%g"
> to print FLONUMS, but this can be changed from within Lisp/SAL programs.
> > This would make Nyquist in Audacity being compatible to CMU-Nyquist.
> >
> >  
> I suspect this is not a compatibility issue, but a question of expected
> behavior. I don't understand how either Nyquist or Audacity behave
> differently or how you would like them to behave differently.
> > Herewith I volunteer to help with fixing all broken
> > Nyquist plugins.
> >  
> As always, I appreciate all your constructive input and contributions.
>
> -Roger

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

______________________________________________________
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]

[hidden email] wrote:
> Roger: If you want the default environment (stretch by 1) in Audacity...
>
> Edgar: yes, this is what I'm talking about
>  
It is generally a bug to write a behavior that assumes the stretch
factor is 1 or starts at time zero. If a behavior B is supposed to have
a duration of 3 seconds, independent of whether the caller tries to
stretch it, then it should probably be written as
(stretch-abs 1 (b)) or in SAL, as stretch-abs(1, b()). If the behavior
is supposed to return a sound starting at time zero rather than at the
time inherited from the caller, then it should probably be written as
(at-abs 0 (stretch-abs 1 (b))), or at-abs(0, stretch-abs(1, b())). If
you want the default Nyquist environment, including things like
transposition, sustain, and loudness, then you should use (abs-env (b))
or abs-env(b()).
> Roger: you can just wrap things in (STRETCH-ABS 1 ...) or even
> (ENV-ABS ...).
>  
Oops -- it's abs-env, not env-abs.
> Furthermore I'm talking about several thousand lines of Nyquist code
> and not about five-line mini plugins, and I'm not willing to re-write
> several hundred lines of Lisp code every time.
>  
If that code is wrapped in a function definition, e.g.

(defun f () ... several hundred lines of lisp code ... )

then all you have to do is change to

(defun f () (abs-env (old-f)))
(defun old-f () ... several hundred lines of lisp code ... )

More than likely, this is not a patch but a bug fix, or if not a bug, at
least a generalization of code that formerly only worked in the special
case where the stretch factor was 1.

If the "... several hundred lines of lisp code ..." is not already
wrapped in a function, how do you manage this without setting global
variables to sounds? This would also be a bug in most situations, so
even if it's work to restructure the code, it might improve performance
and make the work more modular, reusable, and the usual good things that
come from encapsulation and abstraction.

> Therefore just another question:
>
> While writing an extensive answer to the previous mails I just realize
> that most of the examples of the Nyquist manual work as expected if I
> write as the first line of the code at the Audacity Nyquist prompt:
>
> (setf *warp* '(0.0 1.0 nil))
> ... code from the Nyquist manual ...
>
> WARNING: THIS IS A HARDCORE HACK!
> DO NOT USE THIS CODE IN YOUR PLUGINS!
>
> Because Roger probably will get instantly very dizzy in his head by
> reading this code, I would like to ask wether there is an "official"
> way to change the value of the *warp* variable.
>  

*warp* is a dynamically scoped variable, so changing it with SETF is
indeed a hack. The main problem with that, besides becoming dependent
upon the implementation details of *warp*  (which could, in principle,
be changed in the future), the SETF could change the *warp* used by the
caller. These sorts of side-effects are highly discouraged in functional
programming.
>  there seems to be no Lisp function to
> manipulate *warp* directly.
>  
Warp actually combines the effects of AT, STRETCH, and some continuous
warp functions. In general, *warp* is the complete mapping from logical
time to real time.
> Is there any way to change the global warp behaviour for (say) a block
> of 500 lines of lisp code as an "official" alternative to:
>
> (let ((*warp* '(0.0 1.0 nil)))
> ... 500-lines-of-lisp-code ...
> ) ; end of let
>  
Yes, use:
   (abs-env (let () ... 500-lines-of-lisp-code ... ))
; this will also reset other potential transforms such as transposition,
loudness, and sustain factor.
>
>  
>  

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

Hi Roger,

The main problem with my "thousands of lines" of Nyquist code
ist that most of it has accumulated over the last few years and
is in deed in a very chaotic state.

So the real problem ist that my own code needs to be re-sorted
and probably in many parts re-written into a much better style.
That's the reason why I never made it public (maybe still to come).

Therefore I most of all need a better understanding of the Nyquist
transformation environment where your last mails already have helped
a lot, thank you very much BTW.

> If the "... several hundred lines of lisp code ..." is not already
> wrapped in a function, how do you manage this without setting global
> variables to sounds?

By using closures over functions building long chains of return-values:

(let ((*warp* '(0.0 1.0 nil)))
(defun fun-1 () (let ((sound (fun-2))) (process sound) sound))
(defun fun-2 () (let ((sound (fun-3))) (process sound) sound))
... many more functions ...
(defun fun-n () (let ((sound (s-read sound))) (process sound) sound))
(s-save (fun-1))
) ; end of let

Reality looks of course a bit more complicated but this is how it works
as a "sample-stream" without huge memory allocation. You only have to
take care that no function starts to "accumulate" samples for any reason.
The only global variables are some fixed parameters, everything else is
based on "sounds, which control sounds" (an envelope is also a sound).

If you know any better way hot to do it, feel free to tell me...

> *warp* is a dynamically scoped variable, so changing it with SETF is
> indeed a hack.

Sorry, I considered my own code as such a kind of idiotic that I didn't
even took care about dynamic scoping. I only wanted to demonstrate how
*NOT* to do it. :-)

> Use: (abs-env (let () ... 500-lines-of-lisp-code ... ))

Thanks a lot, I obviously had read too little in the Nyquist source code,
and I think the far better solution will be if I read the code of the
Nyquist transformation environment once again and then ask more
(and hopefully better) questions.

Thanks a lot to far,

- edgar

> [hidden email] wrote:
> > Roger: If you want the default environment (stretch by 1) in Audacity...
> >
> > Edgar: yes, this is what I'm talking about
> >  
> It is generally a bug to write a behavior that assumes the stretch
> factor is 1 or starts at time zero. If a behavior B is supposed to have
> a duration of 3 seconds, independent of whether the caller tries to
> stretch it, then it should probably be written as
> (stretch-abs 1 (b)) or in SAL, as stretch-abs(1, b()). If the behavior
> is supposed to return a sound starting at time zero rather than at the
> time inherited from the caller, then it should probably be written as
> (at-abs 0 (stretch-abs 1 (b))), or at-abs(0, stretch-abs(1, b())). If
> you want the default Nyquist environment, including things like
> transposition, sustain, and loudness, then you should use (abs-env (b))
> or abs-env(b()).
> > Roger: you can just wrap things in (STRETCH-ABS 1 ...) or even
> > (ENV-ABS ...).
> >  
> Oops -- it's abs-env, not env-abs.
> > Furthermore I'm talking about several thousand lines of Nyquist code
> > and not about five-line mini plugins, and I'm not willing to re-write
> > several hundred lines of Lisp code every time.
> >  
> If that code is wrapped in a function definition, e.g.
>
> (defun f () ... several hundred lines of lisp code ... )
>
> then all you have to do is change to
>
> (defun f () (abs-env (old-f)))
> (defun old-f () ... several hundred lines of lisp code ... )
>
> More than likely, this is not a patch but a bug fix, or if not a bug, at
> least a generalization of code that formerly only worked in the special
> case where the stretch factor was 1.
>
> If the "... several hundred lines of lisp code ..." is not already
> wrapped in a function, how do you manage this without setting global
> variables to sounds? This would also be a bug in most situations, so
> even if it's work to restructure the code, it might improve performance
> and make the work more modular, reusable, and the usual good things that
> come from encapsulation and abstraction.
> > Therefore just another question:
> >
> > While writing an extensive answer to the previous mails I just realize
> > that most of the examples of the Nyquist manual work as expected if I
> > write as the first line of the code at the Audacity Nyquist prompt:
> >
> > (setf *warp* '(0.0 1.0 nil))
> > ... code from the Nyquist manual ...
> >
> > WARNING: THIS IS A HARDCORE HACK!
> > DO NOT USE THIS CODE IN YOUR PLUGINS!
> >
> > Because Roger probably will get instantly very dizzy in his head by
> > reading this code, I would like to ask wether there is an "official"
> > way to change the value of the *warp* variable.
> >  
> *warp* is a dynamically scoped variable, so changing it with SETF is
> indeed a hack. The main problem with that, besides becoming dependent
> upon the implementation details of *warp*  (which could, in principle,
> be changed in the future), the SETF could change the *warp* used by the
> caller. These sorts of side-effects are highly discouraged in functional
> programming.
> >  there seems to be no Lisp function to
> > manipulate *warp* directly.
> >  
> Warp actually combines the effects of AT, STRETCH, and some continuous
> warp functions. In general, *warp* is the complete mapping from logical
> time to real time.
> > Is there any way to change the global warp behaviour for (say) a block
> > of 500 lines of lisp code as an "official" alternative to:
> >
> > (let ((*warp* '(0.0 1.0 nil)))
> > ... 500-lines-of-lisp-code ...
> > ) ; end of let
> >  
> Yes, use:
>    (abs-env (let () ... 500-lines-of-lisp-code ... ))
> ; this will also reset other potential transforms such as transposition,
> loudness, and sustain factor.

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

______________________________________________________
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]

[hidden email] wrote:

> By using closures over functions building long chains of return-values:
> (let ((*warp* '(0.0 1.0 nil)))
> (defun fun-1 () (let ((sound (fun-2))) (process sound) sound))
> (defun fun-2 () (let ((sound (fun-3))) (process sound) sound))
> ... many more functions ...
> (defun fun-n () (let ((sound (s-read sound))) (process sound) sound))
> (s-save (fun-1))
> ) ; end of let
>
>  

If this is roughly how the code is structured, then the solution is
simple: Since *warp* is dynamically scoped, you do not have to wrap all
the defuns, only the call to fun-1, e.g.

(defun fun-1 () (let ((sound (fun-2))) (process sound) sound))
(defun fun-2 () (let ((sound (fun-3))) (process sound) sound))
... many more functions ...
(defun fun-n () (let ((sound (s-read sound))) (process sound) sound))
(s-save (abs-env (fun-1)))

-Roger




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

Hi Roger

Thanks once again, but I think the most important part was:

> It is generally a bug to write a behavior that assumes the stretch
> factor is 1 or starts at time zero. If a behavior B is supposed to
> behave in an exact predefined way, independent of what the caller
> wants it to behave, then "stretch-abs" or "at-abs" should be used
> in the function's code.

This means that many of my functions needs to be rewritten (doesn't
matter, doing things wrong is the fastest way to learn).

- edgar

> [hidden email] wrote:
> > By using closures over functions building long chains of return-values:
> > (let ((*warp* '(0.0 1.0 nil)))
> > (defun fun-1 () (let ((sound (fun-2))) (process sound) sound))
> > (defun fun-2 () (let ((sound (fun-3))) (process sound) sound))
> > ... many more functions ...
> > (defun fun-n () (let ((sound (s-read sound))) (process sound) sound))
> > (s-save (fun-1))
> > ) ; end of let
> >
> >  
> If this is roughly how the code is structured, then the solution is
> simple: Since *warp* is dynamically scoped, you do not have to wrap all
> the defuns, only the call to fun-1, e.g.
>
> (defun fun-1 () (let ((sound (fun-2))) (process sound) sound))
> (defun fun-2 () (let ((sound (fun-3))) (process sound) sound))
> ... many more functions ...
> (defun fun-n () (let ((sound (s-read sound))) (process sound) sound))
> (s-save (abs-env (fun-1)))
>
> -Roger
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

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