Re: [CM] tap fixed - patch to tankrev.scm
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 20. But at least this gives a new way to write musical loops. ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 there's already one such inside s7-test-b.scm...) ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 (some-huge-comp) is 'fixed' at read-time. So far so good. However, if i use this when defining the instrument on the calls down in the run-loop, ie: (outa i (+ (* +0.6 (tap delay_48_54 #.(smpls->samples 266))) (* +0.6 (tap delay_48_54 #.(smpls->samples 2974))) ... supposing these calls will be fixed at read-time (ie. when evaluating the (define*...)), calling the instrument is still only around half the speed of the version with 'pre-calculated' data (which btw. is really fast). Is this because of extra overhead vs. memory lookup? -anders ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 know of bugs! ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
B> ...It will work the first time. !! ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 compute one path. And intermediate steps could involve tempo maps + audio interpolation. It will work the first time. ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 for you. Maybe someday... ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
> "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 catched at read time - no cure except for copy-pasting text? B> let, but it is unhappy about *clm-srate*. It can't be certain B> it's compatible with round, or that it's constant during the loop B> (the latter is doable in the best-of-all-worlds Sounds like something i definitely want to check. B> (complex *clm-srate* would mean at least complex phase increments B> and output, so you'd generate a 4-dimensional output -- B> 2-dimensional time makes me smile, but I can't immediately think B> of a musical application. Not disqualifying options like these by design is one of the real blessings of this wonderful tool. Cheers, -anders ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 latter is doable in the best-of-all-worlds, and the former perhaps by wrapping the loop in (when (real? *clm-srate*) (do...))). (complex *clm-srate* would mean at least complex phase increments and output, so you'd generate a 4-dimensional output -- 2-dimensional time makes me smile, but I can't immediately think of a musical application. And, sadly, dumb generators like oscil and delay currently assume their inputs are "real" = floats). The new version of tankrev is in the cvs area, and, unless I messed up the script, also in the daily tarball, snd-17.tar.gz at ccrma-ftp. ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
> "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 hardcoding? B> Since all the smpls->samples calls involve constants, I'd B> precompute those offsets: ... B> which is uglier, but 10 times as fast. That's a decent speed up! It'd be great if this change is done in the dist'ed version as well. Thanks. Anders. ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
Re: [CM] tap fixed - patch to tankrev.scm
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 0.5) (bandwidth 0.9995) (damping 0.005) (reverb-decay-time 1.0)) "(tank-reverb (predelay 0.0) (decay 0.5) (bandwidth 0.9995) (damping 0.005) (reverb-decay-time 1.0))" ;; try setting 'decay = 1.0 for a nice 'freeze' effect (let ((decay-diffusion-1 0.70) (decay-diffusion-2 0.50) (input-diffusion-1 0.750) (input-diffusion-2 0.625) (excursion (smpls->samples 16))) (let ((len (+ (framples *reverb*) (seconds->samples reverb-decay-time))) (predly (make-delay (seconds->samples predelay))) (lp1 (make-one-pole bandwidth (* -1 (- 1 bandwidth ;; input diffusers = series of 4 all-pass-filters (mono input): (input-diffusers (make-all-pass-bank (vector (make-diffuser (smpls->samples 142) input-diffusion-1) (make-diffuser (smpls->samples 107) input-diffusion-1) (make-diffuser (smpls->samples 379) input-diffusion-2) (make-diffuser (smpls->samples 277) input-diffusion-2 ;; tank, fig-of-eight in Dattorro's figure p. 662: (excursion_24 (make-oscil 1.0)) ;max 'Excursion' = 16 samples (FS=29761) (excursion_48 (make-oscil 0.707)) (modallpass_23 (make-mod-all-pass (smpls->samples 672) decay-diffusion-1)) (modallpass_46 (make-mod-all-pass (smpls->samples 908) decay-diffusion-1)) (delay_24_30 (make-delay (smpls->samples 4453))) (delay_48_54 (make-delay (smpls->samples 4217))) (damper_30 (make-one-pole (- 1 damping) (* -1 damping))) (damper_54 (make-one-pole (- 1 damping) (* -1 damping))) (diffuser_31_33 (make-diffuser (smpls->samples 1800) decay-diffusion-2)) (diffuser_55_59 (make-diffuser (smpls->samples 2656) decay-diffusion-2)) (delay_33_39 (make-delay (smpls->samples 3720))) (delay_59_63 (make-delay (smpls->samples 3163))) (dc-block-1 (make-filter 2 (float-vector 1 -1) (float-vector 0 -0.99))) (dc-block-2 (make-filter 2 (float-vector 1 -1) (float-vector 0 -0.99))) (tank_1 0.0) (tank_2 0.0) (smpl-266 (smpls->samples 266)) (smpl-2974 (smpls->samples 2974)) (smpl-1913 (smpls->samples 1913)) (smpl-1996 (smpls->samples 1996)) (smpl-1990 (smpls->samples 1990)) (smpl-187 (smpls->samples 187)) (smpl-1066 (smpls->samples 1066)) (smpl-353 (smpls->samples 353)) (smpl-3627 (smpls->samples 3627)) (smpl-1228 (smpls->samples 1228)) (smpl-2673 (smpls->samples 2673)) (smpl-2111 (smpls->samples 2111)) (smpl-335 (smpls->samples 335)) (smpl-121 (smpls->samples 121)) (smpl-8 (smpls->samples 8))) (do ((i 0 (+ i 1))) ((= i len)) (let ((sig (all-pass-bank input-diffusers (one-pole lp1 (delay predly (ina i *reverb*)) ;; add incoming signal to rotated tank: (set! tank_1 (delay delay_33_39 (all-pass diffuser_31_33 (one-pole damper_30 (delay delay_24_30 (all-pass modallpass_23 (filter dc-block-1 (+ sig (* decay tank_2))) (+ smpl-8 (* smpl-8 (oscil excursion_24) (set! tank_2 (delay delay_59_63 (all-pass diffuser_55_59 (one-pole damper_54 (delay delay_48_54 (all-pass modallpass_46 (filter dc-block-2 (+ sig (* decay tank_1))) (+ smpl-8 (* smpl-8 (oscil excursion_48) ;; tap reflections and output: (outa i (+ (* +0.6 (tap delay_48_54 smpl-266)) (* +0.6 (tap delay_48_54 smpl-2974)) (* -0.6 (tap diffuser_55_59 smpl-1913)) (* +0.6 (tap delay_59_63 smpl-1996)) (* -0.6 (tap delay_24_30 smpl-1990))
[CM] tap fixed - patch to tankrev.scm
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 optimizing of fixed values like these in a loop? Suggestions and improvements are of course very welcome. -anders tankrev.scm.diffs Description: Binary data ___ Cmdist mailing list Cmdist@ccrma.stanford.edu https://cm-mail.stanford.edu/mailman/listinfo/cmdist
