From anders.vinjar at bek.no Tue Nov 1 04:08:11 2016 From: anders.vinjar at bek.no (anders.vinjar at bek.no) Date: Tue, 01 Nov 2016 12:08:11 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> Message-ID: <87y413cvac.fsf@bek.no> >>>>> "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. From bil at ccrma.Stanford.EDU Tue Nov 1 07:24:58 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 01 Nov 2016 07:24:58 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <87y413cvac.fsf@bek.no> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> Message-ID: <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> 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. From anders.vinjar at nmh.no Tue Nov 1 08:25:33 2016 From: anders.vinjar at nmh.no (anders.vinjar at nmh.no) Date: Tue, 01 Nov 2016 16:25:33 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> Message-ID: <87pomfcjde.fsf@bek.no> >>>>> "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 From bil at ccrma.Stanford.EDU Tue Nov 1 09:39:28 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 01 Nov 2016 09:39:28 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <87pomfcjde.fsf@bek.no> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> Message-ID: <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> 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... From bil at ccrma.Stanford.EDU Tue Nov 1 09:59:59 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Tue, 01 Nov 2016 09:59:59 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> Message-ID: <3b2b251cba82ab0737ebbe07aaaa5d66@ccrma.stanford.edu> 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. From anders.vinjar at bek.no Wed Nov 2 04:16:58 2016 From: anders.vinjar at bek.no (anders.vinjar at bek.no) Date: Wed, 02 Nov 2016 12:16:58 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <3b2b251cba82ab0737ebbe07aaaa5d66@ccrma.stanford.edu> Message-ID: <87k2cm9ln9.fsf@bek.no> B> ...It will work the first time. !! From anders.vinjar at nmh.no Wed Nov 2 04:07:40 2016 From: anders.vinjar at nmh.no (anders.vinjar at nmh.no) Date: Wed, 02 Nov 2016 12:07:40 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> Message-ID: <87oa1y9m2r.fsf@bek.no> 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 From bil at ccrma.Stanford.EDU Wed Nov 2 05:08:14 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 02 Nov 2016 05:08:14 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <87oa1y9m2r.fsf@bek.no> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <87oa1y9m2r.fsf@bek.no> Message-ID: > 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! From anders.vinjar at nmh.no Wed Nov 2 07:34:22 2016 From: anders.vinjar at nmh.no (anders.vinjar at nmh.no) Date: Wed, 02 Nov 2016 15:34:22 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <87oa1y9m2r.fsf@bek.no> Message-ID: <87a8dihrwx.fsf@bek.no> 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 From bil at ccrma.Stanford.EDU Wed Nov 2 09:30:59 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Wed, 02 Nov 2016 09:30:59 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <87a8dihrwx.fsf@bek.no> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <87oa1y9m2r.fsf@bek.no> <87a8dihrwx.fsf@bek.no> Message-ID: <694447d3af1cbbb60dcd872073f01795@ccrma.stanford.edu> 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 #. version, the offsets are set at read-time, so if you change srates later, the reverb does not adjust. From anders.vinjar at nmh.no Thu Nov 3 02:33:01 2016 From: anders.vinjar at nmh.no (anders.vinjar at nmh.no) Date: Thu, 03 Nov 2016 10:33:01 +0100 Subject: [CM] tap fixed - patch to tankrev.scm References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <87oa1y9m2r.fsf@bek.no> <87a8dihrwx.fsf@bek.no> <694447d3af1cbbb60dcd872073f01795@ccrma.stanford.edu> Message-ID: <87eg2sgb76.fsf@bek.no> 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...) From bil at ccrma.Stanford.EDU Thu Nov 3 07:16:28 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 03 Nov 2016 07:16:28 -0700 Subject: [CM] tap fixed - patch to tankrev.scm In-Reply-To: <87eg2sgb76.fsf@bek.no> References: <87r372m378.fsf@bek.no> <6b7d0df7ae5334707cb0800321d5cd7d@ccrma.stanford.edu> <87y413cvac.fsf@bek.no> <3c7e0d12e20dce1d2f3a5b750958db59@ccrma.stanford.edu> <87pomfcjde.fsf@bek.no> <0f7def892d64a7f829fe5618508cc246@ccrma.stanford.edu> <87oa1y9m2r.fsf@bek.no> <87a8dihrwx.fsf@bek.no> <694447d3af1cbbb60dcd872073f01795@ccrma.stanford.edu> <87eg2sgb76.fsf@bek.no> Message-ID: <880b897b67b756fe9408856d84b32ae3@ccrma.stanford.edu> 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. From anders.vinjar at nmh.no Thu Nov 10 04:27:25 2016 From: anders.vinjar at nmh.no (anders.vinjar at nmh.no) Date: Thu, 10 Nov 2016 13:27:25 +0100 Subject: [CM] sndinfo doesn't work w. large riff/wav (from other apps), sun/next is ok Message-ID: <87pom31pw2.fsf@electricaudiounit.no> Using sndinfo to read some info on large soundfiles. Is it sndlib or sox failing here? $ sox -n -c 2 silence.au trim 0.0 10000.0 $ sndinfo silence.au | grep length length: 10000.000000 $ sox -n -c 2 silence.wav trim 0.0 10000.0 $ sndinfo silence.wav | grep length silence.wav: no data chunk?silence.wav: no data chunk?$ soxi reports correct duration with both files. Making the large .wav with snd makes sndinfo report good numbers. sndinfo and snd fails on large wav-files made with other (libsndfile based) apps too, eg. ardour. It's ok with shorter files (< 2.1 GB?). From bil at ccrma.Stanford.EDU Thu Nov 10 09:47:29 2016 From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU) Date: Thu, 10 Nov 2016 09:47:29 -0800 Subject: [CM] sndinfo doesn't work w. large riff/wav (from other apps), sun/next is ok In-Reply-To: <87pom31pw2.fsf@electricaudiounit.no> References: <87pom31pw2.fsf@electricaudiounit.no> Message-ID: <2f7b681ebfc1c5cf3af35c6a2706f654@ccrma.stanford.edu> The problem is in sndlib, not sox. There were a couple places where the size was treated as a (signed) int, even though snd could write an unsigned int if needed. Thanks for the bug report! From dawsonwu at rahul.net Mon Nov 14 03:02:52 2016 From: dawsonwu at rahul.net (Ken Dawson) Date: Mon, 14 Nov 2016 11:02:52 -0000 Subject: [CM] sndinfo doesn't work w. large riff/wav (from other apps), sun/next is ok In-Reply-To: <2f7b681ebfc1c5cf3af35c6a2706f654@ccrma.stanford.edu> References: <87pom31pw2.fsf@electricaudiounit.no> <2f7b681ebfc1c5cf3af35c6a2706f654@ccrma.stanford.edu> Message-ID: <85a635d7-62f0-dee6-5a0b-f72ae757358e@rahul.net> There has been asimilar issue with libsndfile discussed on Linux Audio Users recently. It may have just been fixed by Erik de Castro Lopo. He mentioned this link. https://github.com/erikd/libsndfile/commit/e4572180c3445ce1afdc9e36ab8c2163637e0755 Hope this is what you are looking for. /ken On 11/10/2016 09:47 AM, bil at ccrma.Stanford.EDU wrote: > The problem is in sndlib, not sox. There were a couple > places where the size was treated as a (signed) int, > even though snd could write an unsigned int if needed. > Thanks for the bug report! > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > https://cm-mail.stanford.edu/mailman/listinfo/cmdist > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j_hearon at hotmail.com Fri Nov 18 09:23:59 2016 From: j_hearon at hotmail.com (James Hearon) Date: Fri, 18 Nov 2016 17:23:59 +0000 Subject: [CM] numerics.scm In-Reply-To: References: Message-ID: Hi, For numerics.scm, these seem useful. Most of them I can evaluate, but the four polynomials (xxx) I cannot seem to figure what it wants. Wondering if anyone might have success or ideas about those guys? Thank You, Jim (load "snd-16/numerics.scm") (factorial 6) -> 720 (binomial 4 2) -> 6 (n-choose-k 10 2) ->45 (plgndr 6 .2 -1) ->2.261952 (legendre-polynomial 1 4);XXX -> argument 1, #f, is boolean but should be a number (legendre 3 4) ->154.0 (gegenbauer 3 4) -> 0.5625693058216614 (chebyshev-polynomial 2 4) ;XXX -> argument 1, #f, is boolean but should be a number (chebyshev 2 4) -> 31.0 hermite-polynomial 1 3) ;XXX -> argument 1, #f, is boolean but should be a number (hermite 1 3) ->6.0 (laguerre-polynomial 3 1) ;XXX -> argument 1, #f, is boolean but should be a number (laguerre 1 4 ) -> -3.0 (Si 10)->1.658347864640153 (Ci 10)->-0.04545628800337046 (sin-m*pi/n 1 9) ->(let ((ex (sqrt 3/4))) (/ (- (expt (+ (sqrt (- 1 (* ex ex))) (* 0+1i ex)) (/ 1 3)) (expt (- (sqrt (- 1 (* ex ex))) (* 0+1i ex)) (/ 1 3))) 0+2i)) (show-digits-of-pi-starting-at-digit 2.0)-> position = 2.000000e+00 fraction = 1.247719318987069 hex digits = "3F6A8885A3 " " position = 2.000000e+00 fraction = 1.247719318987069 hex digits = \"3F6A8885A3 \" " -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.winkler at balcab.ch Wed Nov 30 15:40:42 2016 From: michael.winkler at balcab.ch (Michael Winkler) Date: Thu, 1 Dec 2016 00:40:42 +0100 Subject: [CM] Grace 3.9.0 on Sierra: characters not visible Message-ID: <0c1acb73-e65a-4a86-eaea-5c342f4d29f5@balcab.ch> Hi, I just have installed Grace 3.9.0 on macOS Sierra. In the editor, I can't read anything ? white letters on a white background. What can I do? all the best, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: simple white grace.png Type: image/png Size: 86887 bytes Desc: not available URL: