The problem (as I have discovered by building a
machine to change the imaginary component of my
time-line) is that as you travel vertically in
time, so to speak, you impinge on others' time-lines,
becoming a different person -- disconcerting!
Now I know why I feel like a stranger to myself
at age
B> If you use the #. version, the offsets are set at read-time, so
B> if you change srates later, the reverb does not adjust.
Wouldn't a complex *clm-srate* be useful here? Guessing we need a
version of read also operating in 4 dimensional time-space then (wait, i
have a strong feeling th
I only get about a 5% difference in times. One way
to make it faster is to get rid of some type conversions:
(smpl-266 (* 1.0 (smpls->samples 266)))
(smpl-2974 (* 1.0 (smpls->samples 2974)))
(smpl-1913 (* 1.0 (smpls->samples 1913)))
...
If you use the #.
Great.
> (define (some-huge-comp) (get-internal-real-time))
some-huge-comp
> (define (test)
(list
#.(some-huge-comp)
(some-huge-comp)))
test
> (test)
(628.159582 631.110096)
> (test)
(628.159582 632.668255)
> (test)
(628.159582 634.408648)
Seems the first call on
Something which does the same thing as #. in CL
s7.html (under *#readers*) has a reader macro that
implements CL's #.
(set! *#readers*
(cons (cons #\. (lambda (str)
(and (string=? str ".") (eval (read)
*#readers*))
I actually haven't used it much -- let me kno
B> I'm not sure I understand your question
Is there any way to achieve read-time evaluation in s7?
Something which does the same thing as #. in CL
___
Cmdist mailing list
Cmdist@ccrma.stanford.edu
https://cm-mail.stanford.edu/mailman/listinfo/cmdis
B> ...It will work the first time.
!!
___
Cmdist mailing list
Cmdist@ccrma.stanford.edu
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
I have it! Since these are sampled, you'd have a
sort of pointilistic painting (or cube?)
that you could zoom around in, and whatever
is underneath is the current sample, so you'd have
infinitely many pieces and travel around in them.
All in real-time of-course, so you'd only actually
have to com
I'm not sure I understand your question, but you want
to evaluate the offsets outside the do-loop (i.e. at
the time the instrument is called, not on every sample).
A "sufficiently intelligent" optimizer could recognize
that those entire expressions are not changing, and pull
them out of the loop f
> "B" == Rujo2eW1CriLhL8O writes:
B> After the expansion, you have
B> (let ((FS 29761)) (round (* (/ *clm-srate* FS) smpl)))
B> at a dozen or more places.
So you're telling me i want read-time evaluation then, not read-time
expansion? Replacing an expression with its value
After the expansion, you have
(let ((FS 29761)) (round (* (/ *clm-srate* FS) smpl)))
at a dozen or more places. The optimizer can probably get rid of the
let,
but it is unhappy about *clm-srate*. It can't be certain it's
compatible
with round, or that it's constant during the loop (the la
> "B" == bil:
B> I think the macro version is slower -- s7 does not currently
B> expand macros when first encountered; you can use
B> define-expansion for that, but the speedup is not great.
If (define-expansion expr) expands expr at read-time, why is it slower
(at run-time) than
I think the macro version is slower -- s7 does not
currently expand macros when first encountered;
you can use define-expansion for that, but the
speedup is not great. Since all the smpls->samples
calls involve constants, I'd precompute those
offsets:
(define* (tank-reverb (predelay 0.0) (decay
Here's a patch to tankrev.scm. The negative delay-times in the previous
version were temporary workarounds to not hit the (now fixed) bug in
tap.
Redefining smpls->samples as a macro here to avoid some unnecessary
calculations in the loop.
Btw, do we want this? Does s7 do checking and optimizin
14 matches
Mail list logo
