From bbattey at u.washington.edu Wed May 1 05:10:02 2002 From: bbattey at u.washington.edu (B. Battey) Date: Wed, 1 May 2002 05:10:02 -0700 (PDT) Subject: [CM] make-integer-array failure In-Reply-To: <200204301121.EAA16472@cmn14.stanford.edu> Message-ID: CLM2 / MCL Declaring in the main let (zcross (make-integer-array fft2)) and placing in the run* loop (clear-array zcross) results in a Unexpected Quit when the instrument is run. Using (make-double-float-array or just (make-array does not result in a crash. -=Bret Bret Battey, DMA http://BatHatMedia.com ---------------------------------------------------------------------- Center for Digital Arts and Experimental Media University of Washington, Seattle http://www.washington.edu/dxarts/ 2001-2002 Fulbright Scholar to India, Pune University, Pune, Maharashtra Department of Computer Science http://cs.unipune.ernet.in/ From bil at ccrma.Stanford.EDU Thu May 2 04:07:10 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 2 May 2002 04:07:10 -0700 Subject: [CM] file-size limit in snd? In-Reply-To: References: Message-ID: <200205021107.EAA20424@cmn14.stanford.edu> > Cant write files larger than 2GB in snd. Right -- I've been putting off dealing with this, but will tackle it now that someone wants it. Basically a bunch of "int"s have to become "off_t"s; and it took me awhile to find the magic macros _FILE_OFFSET_BITS (to enable the Large File System in Linux), and AC_SYS_LARGEFILE (autoconf). I estimate this will be fully incoporated within a week or less. If you just want to write a big file (not edit it), add this at the top of snd.h and recompile Snd: #define _FILE_OFFSET_BITS 64 That will automatically pull in all the 64-bit file IO functions. I wrote a 4GB file after doing this, just to check it. A remaining question: what's the right way to handle these off_t's in fprintf? (%ld + (long) works but seems incorrect in the long run). From mshannon at domovina.org Thu May 2 04:29:13 2002 From: mshannon at domovina.org (Marty Shannon, RHCE) Date: Thu, 02 May 2002 07:29:13 -0400 Subject: [CM] file-size limit in snd? References: <200205021107.EAA20424@cmn14.stanford.edu> Message-ID: <3CD12309.DA87E5F@domovina.org> Bill Schottstaedt wrote: > > > Cant write files larger than 2GB in snd. > > Right -- I've been putting off dealing with this, but will tackle > it now that someone wants it. Basically a bunch of "int"s have to > become "off_t"s; No, they must become "offset_t"s. "off_t" is typically only 32 bits. > and it took me awhile to find the magic macros > _FILE_OFFSET_BITS (to enable the Large File System in Linux), > and AC_SYS_LARGEFILE (autoconf). I estimate this will be fully > incoporated within a week or less. If you just want to write > a big file (not edit it), add this at the top of snd.h and > recompile Snd: > > #define _FILE_OFFSET_BITS 64 > > That will automatically pull in all the 64-bit file IO functions. > I wrote a 4GB file after doing this, just to check it. > A remaining question: what's the right way to handle > these off_t's in fprintf? (%ld + (long) works but seems > incorrect in the long run). They must be %lld and "long long"s. Cheers, Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:mshannon at domovina.org From bil at ccrma.Stanford.EDU Sun May 5 04:26:48 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 5 May 2002 04:26:48 -0700 Subject: [CM] file-size limit in snd? In-Reply-To: References: Message-ID: <200205051126.EAA04289@cmn14.stanford.edu> I think Snd works now in general with any size file: I tested it pretty fully with a 44.1KHz 20 hour sine wave (its amplitude was changing, so I didn't get bored). sndinfo and sndplay also need to be recompiled. I'm not immediately sure how to get CLM to work in this regard -- it could write and play such files, but I need some way to deal with long longs (64-bit ints) in the foreign function interface. From bil at ccrma.Stanford.EDU Sun May 5 04:27:12 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sun, 5 May 2002 04:27:12 -0700 Subject: [CM] make-integer-array failure In-Reply-To: References: Message-ID: <200205051127.EAA04292@cmn14.stanford.edu> > (zcross (make-integer-array fft2)) > and placing in the run* loop > (clear-array zcross) > results in a Unexpected Quit when the instrument is run. Thanks for the bug report -- I think this is fixed now. From bbattey at u.washington.edu Wed May 8 06:20:42 2002 From: bbattey at u.washington.edu (bbattey at u.washington.edu) Date: Wed, 8 May 2002 06:20:42 -0700 (PDT) Subject: [CM] Removing 'no-output' warning / values returns Message-ID: Hello, I've just finished a 'beta' of an autocorrelation pitch tracker for CLM2. As a analysis tool, it doesn't write out a soundfile, so it has no out and I don't run it within a with-sound. However, CLM2 doesn't expect this, so it gives me a warning that tends to run through 3 or 4 listener pages: warning: output nil?? warning: no output loc? I've removed this from my build by commenting out these lines in cmus.lisp: ;(if (null *output*) (warn "output nil??")) ;(if (null outlst) (warn "no output loc? ~A " ',variable-load-list)) Would anyone by opposed to making this a permanent change in CLM2? (One motivation being that I am creating a package for pitch-curve extraction and modeling that I would like other persons be able to install to use -- without them having to modify the CLM2 build themselves.) --- I've also thought that it would be nice if definstrument could, optionally, return values, since it looks like definstrument doesn't do this the way a standard LISP function would. Perhaps a clm-return function, like (clm- return (values freqs amps fft)). Then one could grab output from an analysis instrument directly without having to place results in global variables: (let (freqs (pitch-track myfile :fftsize 1024)) etc I don't know if this makes sense in the bigger pitcture of CLM2's design, though. Or perhaps there is an ability to do this already that I have missed? Bret Battey, DMA http://BatHatMedia.com ---------------------------------------------------------------------- Center for Digital Arts and Experimental Media University of Washington, Seattle http://www.washington.edu/dxarts/ 2001-2002 Fulbright Scholar to India, Pune University, Pune, Maharashtra Department of Computer Science http://cs.unipune.ernet.in/ From bil at ccrma.Stanford.EDU Wed May 8 06:40:23 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 8 May 2002 06:40:23 -0700 Subject: [CM] Removing 'no-output' warning / values returns In-Reply-To: References: Message-ID: <200205081340.GAA09942@cmn14.stanford.edu> > Would anyone by opposed to making this a permanent change in CLM2? Not me -- I suppose it could be on the *clm-safety* switch. > I've also thought that it would be nice if definstrument could, optionally, _ > return values That's what run* was intended for -- doesn't it work in MCL? From bil at ccrma.Stanford.EDU Wed May 8 07:02:48 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 8 May 2002 07:02:48 -0700 Subject: [CM] Removing 'no-output' warning / values returns In-Reply-To: References: Message-ID: <200205081402.HAA09969@cmn14.stanford.edu> > > I've also thought that it would be nice if definstrument could, optionally, _ > > return values > That's what run* was intended for -- doesn't it work in MCL? Oops -- I think I see what the problem is -- I assumed tagbody was like everything else and returned its last value, but it always returns nil. This change to defins.lisp line 500 or so will export the instrument value: (if (zerop clm::*interrupted*) (let ((val nil)) (tagbody (restart-case (setf val (progn ,ins-code)) (nil () :report "abort current note." (go C-INSTRUMENT-DONE))) C-INSTRUMENT-DONE) val)))) From marcus.roeckrath at gmx.de Wed May 8 11:49:37 2002 From: marcus.roeckrath at gmx.de (Marcus Roeckrath) Date: Wed, 8 May 2002 20:49:37 +0200 Subject: [CM] How have this to be modified Message-ID: <02050820493703.03757@lighthouse> Hi, a long time agao, it must in times of snd 3 or so I put in the following definitions in ~/.snd: (define data-max (lambda () (let ((maxval 0.0)) (lambda (data len) (if data (do ((i 0 (1+ i))) ((= i len) #f) (let ((curval (abs (vector-ref data i)))) (if (> curval maxval) (set! maxval curval)))) maxval))))) (define maxlevel (lambda () (scan-across-all-chans (data-max)))) Now I used this again but it doesn't work. scan-across-all-chans isn't there available anymor. data-max seams to be icompatible, gives an error. Can someone tell me how I have to modify these functions? Thanks. -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Mailer/BBS/Fax : +49-2536-9943 (V34, X75) FidoNet: 2:2449/523 E-Mail : marcus.roeckrath at gmx.de WWW : http://home.foni.net/~marcusroeckrath/ From bil at ccrma.Stanford.EDU Thu May 9 05:39:26 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 9 May 2002 05:39:26 -0700 Subject: [CM] How have this to be modified In-Reply-To: <02050820493703.03757@lighthouse> References: <02050820493703.03757@lighthouse> Message-ID: <200205091239.FAA11697@cmn14.stanford.edu> > Now I used this again but it doesn't work. scan-across-all-chans isn't there > available anymor. data-max seams to be icompatible, gives an error. > Can someone tell me how I have to modify these functions? scan-across-all-chans is in snd4.scm. Here's a quick stab at a replacement: (define (maxlevel) (let ((mx 0.0)) (for-each (lambda (snd) (set! mx (max mx (apply max (maxamp snd #t))))) (sounds)) mx)) Or if you want the list of all maxes: (maxamp #t #t). From ppagano at bellsouth.net Thu May 9 16:16:37 2002 From: ppagano at bellsouth.net (shreeswifty) Date: Thu, 9 May 2002 19:16:37 -0400 Subject: [CM] Pvoc References: <200205091901.g49J11l04364@cm-mail.stanford.edu> Message-ID: <000e01c1f7af$9185ff60$7fa14ed8@gnv.bellsouth.net> Hello I am new to teh CM list mostly as my interest in snd grows. I would appreciate all and any working pvoc schemes that i might employ for snd cheers Pat Pagano, Director South East Just Intonation Society http://www.screwmusicforever.com/SHREESWIFT/ From nik at f0.am Fri May 10 01:11:24 2002 From: nik at f0.am (nik gaffney) Date: Fri, 10 May 2002 10:11:24 +0200 Subject: [CM] cm,clm and sbcl Message-ID: <200205100811.g4A8BEV15458@picard.skynet.be> after trying to get the common (lisp) music systems to compile/run/work on a mac running debian, im curious as to whether anyone has managed to get these systems running using steel bank cl, or clisp on ppc ?+ From taube at uiuc.edu Fri May 10 09:03:05 2002 From: taube at uiuc.edu (Rick Taube) Date: Fri, 10 May 2002 11:03:05 -0500 Subject: [CM] cm,clm and sbcl Message-ID: cm is working in the lastest clisp but i havent tried the ppc version. it would be a trivial port if it didnt work out of the box. i dont know anything about steel bank cl though, ill look into it. >after trying to get the common (lisp) music systems to compile/run/work on a >mac running debian, im curious as to whether anyone has managed to get these >systems running using steel bank cl, or clisp on ppc ?+ > >_______________________________________________ >Cmdist mailing list >Cmdist at ccrma.stanford.edu >http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From bil at ccrma.Stanford.EDU Sat May 11 04:35:14 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sat, 11 May 2002 04:35:14 -0700 Subject: [CM] snd 5.10 Message-ID: <200205111135.EAA15474@cmn14.stanford.edu> Changes in Snd 5.10: Snd can handle files of any size with aplomb. --with-run is now the default (Guile 1.5 or later). The optimizer is going well enough that I started moving some functions into Scheme (snd5.scm) that existed simply to speed up stuff: vct-do!, vcts-map!, vcts-do!. The latter were trying to deal with locsig-like applications, but CLM-2's locsig (which came later) returns a frame, not a list, leaving the vcts-* without any purpose in life. Also added vct-map with arguments more like Scheme's. added optimization-hook (to find out why the optimizer gave up) Added singer.scm, piano.scm, maraca.scm, fade.scm, all translated from CLM. singer.scm runs 20 times faster optimized! Thanks to Anders Vinjar, Stefan Schwandter, David Baker, Ashley Gadd, Dave Phillips, Michael Klingbeil, Brett Battey, and Fernando Lopez-Lezcano for bug reports and bugfixes. From nik at xdv.org Sun May 12 06:27:08 2002 From: nik at xdv.org (nik gaffney) Date: Sun, 12 May 2002 15:27:08 +0200 Subject: [CM] cm,clm and sbcl Message-ID: <20020512132708.GA18414@xdv.org> > cm is working in the lastest clisp but i havent tried the ppc version. it > would be a trivial port if it didnt work out of the box. i tried to get clm working, im using >> GNU CLISP 2.27 the (load "all.lisp") doesnt complain, but if i try loading an example (simple-fm from the docs) i get errors like -> [2]> (load "simple-fm.cl") ;; Loading file simple-fm.cl ... ; Writing "/home/zzk/clm/clm-2/clm_clp_PM.c" ; Compiling "/home/zzk/clm/clm-2/clm_clp_PM.c" /usr/lib/crt1.o(.rodata+0x4): undefined reference to ain' /tmp/ccuRu9Lp.o: In function lm_clp_pm4': /tmp/ccuRu9Lp.o(.text+0xa4): undefined reference to lm_signal' /tmp/ccuRu9Lp.o(.text+0xa4): relocation truncated to fit: R_PPC_REL24 clm_signal /tmp/ccuRu9Lp.o(.text+0x14c): undefined reference to in' etc+ + and the run macro "cannot handle CONTROL in (CONTROL SIMP-ON)" when i try loading the simple realtime example > i dont know > anything about steel bank cl though, ill look into it. sbcl is derived from cmucl, with a few changes in focus. so, porting from cmucl to sbcl shouldnt be to difficult (famous last words) http://sbcl.sourceforge.net/ From csr21 at cam.ac.uk Mon May 13 05:00:11 2002 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 13 May 2002 13:00:11 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <20020512132708.GA18414@xdv.org> References: <20020512132708.GA18414@xdv.org> Message-ID: <20020513120011.GA8662@cam.ac.uk> On Sun, May 12, 2002 at 03:27:08PM +0200, nik gaffney wrote: > > i dont know > > anything about steel bank cl though, ill look into it. > > sbcl is derived from cmucl, with a few changes in focus. > so, porting from cmucl to sbcl shouldnt be to difficult (famous last words) > > http://sbcl.sourceforge.net/ Famous last words, indeed :-) In terms of porting code between them, things you might need to be aware of are: * package name changes: Most of SBCL's packages are prefixed with SB- (so, for example, extensions live in SB-EXT, rather than EXT); also, there is no equivalent package to C-CALL (all alien machinery lives in SB-ALIEN). * deletion of extensions: Some things which CMUCL treats as supported extensions are either deleted entirely (e.g. search lists) or not supported as extensions, but are viewed as internal implementation details (e.g. SB-UNIX machinery). Hovering somewhere in this area is also calling lisp from C via funcallX -- this interface is possibly subject to change in the medium- to long-term. That said, bodies of code, including foreign-interfacing code, have been made to run under both without expending vast amounts of effort, so please don't treat this message as discouragement -- quite the reverse, in fact. Don't hesitate to get in touch with the sbcl development team if you have any questions or requests. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) From cnichols at ccrma.Stanford.EDU Mon May 13 18:40:57 2002 From: cnichols at ccrma.Stanford.EDU (Charles Nichols) Date: Mon, 13 May 2002 18:40:57 -0700 (PDT) Subject: [CM] jcrev.ins Message-ID: I'm only getting left channel output from jcrev.ins, eventhough I've got :reverb jc-reverb :reverb-channels 2 in the with-sound parameter list: OutA max amp: 0.262 (near 21.430 secs) OutB max amp: 0.264 (near 21.533 secs) RevA max amp: 0.069 (near 17.220 secs) RevB max amp: 0.000 (near 0.000 secs) Anyone else run into this problem, or know what I've forgotten? -Charles CharlesNichols.com From bil at ccrma.Stanford.EDU Tue May 14 04:24:17 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Tue, 14 May 2002 04:24:17 -0700 Subject: [CM] cm,clm and sbcl In-Reply-To: <20020512132708.GA18414@xdv.org> References: <20020512132708.GA18414@xdv.org> Message-ID: <200205141124.EAA21473@cmn14.stanford.edu> > ; Writing "/home/zzk/clm/clm-2/clm_clp_PM.c" > ; Compiling "/home/zzk/clm/clm-2/clm_clp_PM.c" > /usr/lib/crt1.o(.rodata+0x4): undefined reference to ain' > /tmp/ccuRu9Lp.o: In function lm_clp_pm4': Before building CLM or using it in this system: (pushnew :linux *features*) > and the run macro "cannot handle CONTROL in (CONTROL SIMP-ON)" > when i try loading the simple realtime example This is due to a Clisp limitation -- it has no foreign function interface worth the name, so the real-time stuff cannot work. > sbcl is derived from cmucl, with a few changes in focus. > so, porting from cmucl to sbcl shouldnt be to difficult (famous last words) CMN works in sbcl (with a minor change to cmn-init.lisp), but CLM doesn't; I made a few hundred changes for sbcl, but finally stopped when I hit (in ffi.lisp): debugger invoked on condition of type SB-INT:BUG: full call to SB-KERNEL:%INSTANCE-REF This is probably a bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe Lisp code; or there might be a bug in the OS or hardware that SBCL is running on.) If it seems to be a bug in SBCL itself, the maintainers would like to know about it. Bug reports are welcome on the SBCL mailing lists, which you can find at . I'd rewrite this error message if I were associated with sbcl -- "corrupted by bad user code" and "a bug in the OS or hardware" are just going to make people laugh. Other things I noticed; sbcl stumbles on: (defconstant a-name "a string") claiming that I'm trying to set the value twice. And in ffi.lisp, it complains: ; caught 1 fatal ERROR condition compilation aborted because of input error: READ failure in COMPILE-FILE: READER-ERROR at 57154 on #: too many colons in "SB-ALIEN" From csr21 at cam.ac.uk Tue May 14 05:15:14 2002 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 14 May 2002 13:15:14 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <200205141124.EAA21473@cmn14.stanford.edu> References: <20020512132708.GA18414@xdv.org> <200205141124.EAA21473@cmn14.stanford.edu> Message-ID: <20020514121514.GA15215@cam.ac.uk> On Tue, May 14, 2002 at 04:24:17AM -0700, Bill Schottstaedt wrote: > > sbcl is derived from cmucl, with a few changes in focus. > > so, porting from cmucl to sbcl shouldnt be to difficult (famous last words) > > CMN works in sbcl (with a minor change to cmn-init.lisp), > but CLM doesn't; I made a few hundred changes for sbcl, but > finally stopped when I hit (in ffi.lisp): [ do you mean clm-snd.lisp? I've just got this, and that's where it BUGs for me... ] > debugger invoked on condition of type SB-INT:BUG: > full call to SB-KERNEL:%INSTANCE-REF > This is probably a bug in SBCL itself. (Alternatively, SBCL might have been > corrupted by bad user code, e.g. by an undefined Lisp operation like > (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe > Lisp code; or there might be a bug in the OS or hardware that SBCL is running > on.) If it seems to be a bug in SBCL itself, the maintainers would like to > know about it. Bug reports are welcome on the SBCL mailing lists, which you > can find at . If my BUG is the same as your BUG, this message arises due to compiling the following macro definition: #-just-lisp (defmacro (result &optional fstr &rest args) (let ((lst (gethash (second result) vars))) (if (or lst (varinfo-refd lst)) (format *c-file* " ~A = FALSE;~%" (lc (second result)))) (format *c-file* " {char *buf; buf = (char *)calloc(512,sizeof(char));~% sprintf(buf,~A);~% clm_send_snd(buf); free(buf);}~%" (apply #'lisp-to-C-format nil fstr args))) nil) And the problem lies in the (or lst (varinfo-refd lst)) -- the second clause only gets executed if lst is NIL, at which point doing structure accesses on it isn't going to be great. Admittedly, the compiler giving up at this point isn't ideal, and is in fact BUG 168 in our (overflowing) bug file, but changing it to (and lst (varinfo-refd lst)) should make this problem go away. If you're seeing a different BUG, could you let me know how to reproduce it, please? >Other things I noticed; sbcl stumbles on: > > (defconstant a-name "a string") > > claiming that I'm trying to set the value twice. This is actually ANSI compliant behaviour, somewhat surprisingly; under Macro DEFCONSTANT, ANSI specifies that constant values are compared with EQL for compatibility, and under SBCL (eql "a string" "a string") is not T in general. Workarounds are either to use defparameter or a symbol macro instead, or else if you need either compile-time or execute-time value only to wrap it in a (eval-when (:compile-toplevel) ...) or (eval-when (:execute) ...) respectively. > And in ffi.lisp, it complains: > > ; caught 1 fatal ERROR condition > compilation aborted because of input error: > READ failure in COMPILE-FILE: > READER-ERROR at 57154 on # for "file \"/home/bil/test/clm/ffi.lisp\"" > {9346E89}>: > too many colons in "SB-ALIEN" This one's odd -- how did it happen? If you can send me instructions for reproducing it, I'll look into it. Thanks for the report, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) From cburns at ccrma.Stanford.EDU Tue May 14 15:53:10 2002 From: cburns at ccrma.Stanford.EDU (Christopher Burns) Date: Tue, 14 May 2002 15:53:10 -0700 (PDT) Subject: [CM] Linux Sound Workshop Message-ID: Hi all -- This workshop might be of interest to CLM users on this list. Please forward as appropriate.... thanks, Chris ============================================= Dear friends, The Center for Computer Research in Music and Acoustics at Stanford University is holding a workshop on Linux Sound: Open Source Music Synthesis, Composition, and Audio Programming this summer that you might be interested in. June 24 - July 5, 2002 Instructors: Fernando Lopez-Lezcano, Miller Puckette, Christopher Burns Linux offers a wonderful environment for low-latency audio development, performance, and composition. Let us help flatten the linux audio learning curve and get you up and running within just a few short weeks! CCRMA has been using the Linux operating system for music composition, synthesis, and audio DSP research since 1996. This workshop will focus on currently available open source tools and environments for computer music research and composition using Linux. The workshop will include an overview of some of the most popular linux distributions and a brief installation clinic with specific focus on audio, midi and real-time performance (dealing with both hardware and software). Low level sound and midi drivers reviewed will include oss, oss-free and alsa. Environments for sound synthesis and composition will include the Common Lisp based clm system, STK (c++) and pd (c). Many other interesting tools like the snd sound editor (and its internal scheme programming environment) will also be covered. Due to the very dynamic nature of the open source community and software base more programs will probably be included by the time the workshop starts. The workshop will also include a brief tour of sound processing and synthesis techniques. Familiarity with computers and programming languages is helpful. You can get campus housing, enjoy the facilities and take in the Stanford Jazz Festival every evening. We hope to see you this summer! Miller, Fernando, and Chris From bil at ccrma.Stanford.EDU Wed May 15 06:17:26 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 15 May 2002 06:17:26 -0700 Subject: [CM] jcrev.ins In-Reply-To: References: Message-ID: <200205151317.GAA23486@cmn14.stanford.edu> > I'm only getting left channel output from jcrev.ins, eventhough I've got > :reverb jc-reverb :reverb-channels 2 in the with-sound parameter list: > > OutA max amp: 0.262 (near 21.430 secs) > OutB max amp: 0.264 (near 21.533 secs) > RevA max amp: 0.069 (near 17.220 secs) > RevB max amp: 0.000 (near 0.000 secs) :reverb-channels refers to the reverb input channels, not output. To write to RevB, you'd need to use locsig, or outb to *reverb*. But, jc-reverb doesn't pay any attention to the 2nd reverb input channel. It does write the reverb to all the output channels (up to 4 anyway). From dan at telent.net Tue May 14 05:06:38 2002 From: dan at telent.net (Daniel Barlow) Date: Tue, 14 May 2002 13:06:38 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <200205141124.EAA21473@cmn14.stanford.edu> (Bill Schottstaedt's message of "Tue, 14 May 2002 04:24:17 -0700") References: <20020512132708.GA18414@xdv.org> <200205141124.EAA21473@cmn14.stanford.edu> Message-ID: <87vg9r3pdd.fsf@noetbook.telent.net> [ I'm not yet on this list, though I intend to be by next week. I'll check the archive for replies but please cc me anything you particularly want me to see] Bill Schottstaedt writes: > CMN works in sbcl (with a minor change to cmn-init.lisp), > but CLM doesn't; I made a few hundred changes for sbcl, but > finally stopped when I hit (in ffi.lisp): I have CLM :just-lisp working in SBCL, at least to the extent that it can play the synthesized violin example. I haven't tried getting all the stuff with the code walker going. > debugger invoked on condition of type SB-INT:BUG: > full call to SB-KERNEL:%INSTANCE-REF > This is probably a bug in SBCL itself. (Alternatively, SBCL might have been [...] I hit something very similar in clm-snd.lisp, which I reported this as an SBCL bug, though the code that triggers it is kind of questionable anyway: --- clm-2.orig/clm-snd.lisp Thu May 9 12:47:58 2002 +++ clm-2/clm-snd.lisp Fri May 10 06:44:58 2002 @@ -141,7 +141,7 @@ #-just-lisp (defmacro (result &optional fstr &rest args) (let ((lst (gethash (second result) vars))) - (if (or lst (varinfo-refd lst)) + (if lst #+nil (or lst (varinfo-refd lst)) (format *c-file* " ~A = FALSE;~%" (lc (second result)))) (format *c-file* " {char *buf; buf = (char *)calloc(512,sizeof(char));~% sprintf(buf,~A);~% clm_send_snd(buf); free(buf);}~%" (apply #'lisp-to-C-format nil fstr args))) I can't see what (varinfo-refd nil) is supposed to return, so I tend to cut SBCL some slack where it doesn't either. Is your ffi.lisp problem likely to be similar? > people laugh. Other things I noticed; sbcl stumbles on: > > (defconstant a-name "a string") I believe that one is somehow religious, though I forget the exact reasoning. > claiming that I'm trying to set the value twice. And in ffi.lisp, it complains: I haven't tried building the ffi version yet. I'll come back to CLM when I have my new usb audio adaptor working properly. -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources From bil at ccrma.Stanford.EDU Wed May 15 06:59:41 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 15 May 2002 06:59:41 -0700 Subject: [CM] cm,clm and sbcl In-Reply-To: <20020514121514.GA15215@cam.ac.uk> References: <20020512132708.GA18414@xdv.org> <200205141124.EAA21473@cmn14.stanford.edu> <20020514121514.GA15215@cam.ac.uk> Message-ID: <200205151359.GAA23550@cmn14.stanford.edu> > And the problem lies in the (or lst (varinfo-refd lst)) Right -- a typo, but an innocuous one in context (that is, the "normal" user won't be expecting send-snd to return a value in the run loop) -- thanks for pointing it out to me. > > (defconstant a-name "a string") > > claiming that I'm trying to set the value twice. > This is actually ANSI compliant behaviour, somewhat surprisingly Humph! I can't believe that anyone really intended to make string constants illegal in lisp. And even if they did, no lisp implementor should cooperate. > > too many colons in "SB-ALIEN" > This one's odd -- how did it happen? I'll have to fire up the thing (at home) and get back to you. One thing I'd greatly appreciate in projects like this would be a document describing the changes (from cmu-cl in this case), or even better, some stab at providing backwards compatibility. The current Common Lisp situation is extremely annoying in this regard -- every Clisp version, for example, is backwards incompatible, and ACL changes its FFI constantly. Most of these changes (package names, for example), strike me as purely cosmetic and unnecessary. From dan at telent.net Wed May 15 07:35:16 2002 From: dan at telent.net (Daniel Barlow) Date: Wed, 15 May 2002 15:35:16 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <200205151359.GAA23550@cmn14.stanford.edu> (Bill Schottstaedt's message of "Wed, 15 May 2002 06:59:41 -0700") References: <20020512132708.GA18414@xdv.org> <200205141124.EAA21473@cmn14.stanford.edu> <20020514121514.GA15215@cam.ac.uk> <200205151359.GAA23550@cmn14.stanford.edu> Message-ID: <87hel94gyj.fsf@noetbook.telent.net> Bill Schottstaedt writes: > I'll have to fire up the thing (at home) and get back to you. > One thing I'd greatly appreciate in projects like this would be > a document describing the changes (from cmu-cl in this case), Not quite what you asked for, but you might find it useful anyway: doc/FOR-CMUCL-DEVELOPERS in the SBCL source archive. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/sbcl/sbcl/doc/FOR-CMUCL-DEVELOPERS?rev=HEAD&content-type=text/vnd.viewcvs-markup -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources From peter_edwards75 at hotmail.com Wed May 15 08:31:23 2002 From: peter_edwards75 at hotmail.com (Peter Edwards) Date: Wed, 15 May 2002 15:31:23 +0000 Subject: [CM] unsubscirbe Message-ID: _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From nik at xdv.org Thu May 16 04:30:57 2002 From: nik at xdv.org (nik gaffney) Date: Thu, 16 May 2002 13:30:57 +0200 Subject: [CM] cm,clm and sbcl Message-ID: <20020516113057.GA15918@xdv.org> thanks for this info, since im intersted in the realtime sysnthesis aspect of the clm system would it make more sense to persevere with sbcl, and wait for a compatible ffi.lisp ? using debian on ppc, there are 3 options (it seems) for cl -clisp -sbcl (derived from cmucl) -openmcl (derived from macintosh cl) since clm 'works' using either these compilers on different platforms, or their parent compilers (probably also on different platforms), whcih would provide the most suitable for clm developemnt do you think?+ >> and the run macro "cannot handle CONTROL in (CONTROL SIMP-ON)" >> when i try loading the simple realtime example > > This is due to a Clisp limitation -- it has no foreign function > interface worth the name, so the real-time stuff cannot work. > >> sbcl is derived from cmucl, with a few changes in focus. >> so, porting from cmucl to sbcl shouldnt be to difficult (famous last >> words) > > CMN works in sbcl (with a minor change to cmn-init.lisp), > but CLM doesn't; I made a few hundred changes for sbcl, but > finally stopped when I hit (in ffi.lisp): From bil at ccrma.Stanford.EDU Thu May 16 04:46:08 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 16 May 2002 04:46:08 -0700 Subject: [CM] cm,clm and sbcl In-Reply-To: <20020516113057.GA15918@xdv.org> References: <20020516113057.GA15918@xdv.org> Message-ID: <200205161146.EAA25403@cmn14.stanford.edu> > since clm 'works' using either these compilers on different platforms, or > their parent compilers (probably also on different platforms), whcih would > provide the most suitable for clm developemnt do you think?+ Does sbcl work on the PPC? I thought it was x86-specific. In the long term, I think clisp is not an option; if it weren't for the fact that many CLM users are using clisp, I'd remove support for it. In terms of real-time CLM work, I think sbcl will eventually be a fully functional option, and have high hopes for openmcl (but haven't actually tried to use it yet). In the longest term (...) I'm thinking of using the Snd optimizer to replace the current horrible kludge of writing an intermediate C file. This would simplify the FFI side of things, and do away with the current redundant code in cmus.lisp (i.e. use clm.c in both programs). Basically it would move about 15000 lines into the existing sndlib/Snd world, leaving a CL wrapper. (I have even toyed with a xen.h implementation in acl so that clm2xen.c could be used as well). From csr21 at cam.ac.uk Thu May 16 05:06:39 2002 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 16 May 2002 13:06:39 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <200205161146.EAA25403@cmn14.stanford.edu> References: <20020516113057.GA15918@xdv.org> <200205161146.EAA25403@cmn14.stanford.edu> Message-ID: <20020516120639.GA28973@cam.ac.uk> On Thu, May 16, 2002 at 04:46:08AM -0700, Bill Schottstaedt wrote: > > since clm 'works' using either these compilers on different platforms, or > > their parent compilers (probably also on different platforms), whcih would > > provide the most suitable for clm developemnt do you think?+ > > Does sbcl work on the PPC? I thought it was x86-specific. [ with my musician's hat on, I hope eventually to get back into lisp-aided music... but for now, I'll reply with my lisp implementor's hat on ] SBCL is supported under PPC/Linux, Alpha/Linux and SPARC/(Linux|Solaris) currently... ports to Tru64 and MacOS X are either in the works or being thought about. I think Dan Barlow has sbcl/clm working on his PPC to the extent of playing with delay effects :-) > In the long term, > I think clisp is not an option; if it weren't for the fact that many CLM > users are using clisp, I'd remove support for it. In terms of real-time > CLM work, I think sbcl will eventually be a fully functional option, and > have high hopes for openmcl (but haven't actually tried to use it yet). OpenMCL is, in my experience, beginning to get into shape; one of the things about working on a large system like a lisp compiler that is allegedly portable is that implementation bugs are exposed quickly in both directions... as of version 0.11 of OpenMCL, it is a bug (or three) in SBCL that prevent it from being cross-compiled successfully. Or, in other words, "OpenMCL is a good-quality ANSI CL". As for its FFI, I'm afraid I haven't really played with it much, but I would be surprised if it weren't in good shape... though, again, it is a "0." version so the interface might be subject to change. There is a developer mailing list for openmcl, too (openmcl-devel @ clozure.com) which will be more able to fill you in on the details than I. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) From dan at telent.net Thu May 16 05:14:02 2002 From: dan at telent.net (Daniel Barlow) Date: Thu, 16 May 2002 13:14:02 +0100 Subject: [CM] cm,clm and sbcl In-Reply-To: <200205161146.EAA25403@cmn14.stanford.edu> (Bill Schottstaedt's message of "Thu, 16 May 2002 04:46:08 -0700") References: <20020516113057.GA15918@xdv.org> <200205161146.EAA25403@cmn14.stanford.edu> Message-ID: <878z6k47ed.fsf@noetbook.telent.net> Bill Schottstaedt writes: > Does sbcl work on the PPC? I thought it was x86-specific. In the long term, It was once. In the current 0.7.3 version it also runs on PPC (Linux), SPARC (Linux and Solaris 2), and Alpha (Linux; I have a patch for Tru64 support, but can't merge it until I get access to a Tru64 system again) (People have asked for an OSX port, but gaps in OSX signal handling make it not completely trivial, so it will probably not happen unless someone with sufficient motivation learns SBCL internals or someone with SBCL internals knowledge is motivated sufficiently.) > In the longest term (...) I'm thinking of using the Snd optimizer to > replace the current horrible kludge of writing an intermediate C file. > This would simplify the FFI side of things, and do away with the current > redundant code in cmus.lisp (i.e. use clm.c in both programs). Basically Out of interest, roughly what performance increase is expected from :just-lisp to the FFI version? I looked at the benchmarks in README.clm but there don't seem to be many just-lisp results for native compilers on recent hardware. -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources From bil at ccrma.Stanford.EDU Thu May 16 05:24:38 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 16 May 2002 05:24:38 -0700 Subject: [CM] cm,clm and sbcl In-Reply-To: <878z6k47ed.fsf@noetbook.telent.net> References: <20020516113057.GA15918@xdv.org> <200205161146.EAA25403@cmn14.stanford.edu> <878z6k47ed.fsf@noetbook.telent.net> Message-ID: <200205161224.FAA25470@cmn14.stanford.edu> > Out of interest, roughly what performance increase is expected from > :just-lisp to the FFI version? It's been a while since I ran any timing tests, but a factor of 30 would not surprise me. At Rick's urging, a long time ago, I wrote a version of some of the mus.lisp code that actually got within a factor of 3 or 4 of C speed, but it was incredibly ugly code -- basically every sub-expression had an explicit type declaration! But maybe one really ugly pile of pure-lisp code would be better than what I have now... There would still need to be a C side for the real-time controls (hmmm...maybe not...need to think about this...) From Torsten.Anders at hfm.uni-weimar.de Fri May 17 02:05:26 2002 From: Torsten.Anders at hfm.uni-weimar.de (Torsten.Anders at hfm.uni-weimar.de) Date: Fri, 17 May 2002 11:05:26 +0200 Subject: [CM] Problems with cmn:rest in CMU Message-ID: Hi, This is probably a known problem, but still annoying: In CMU-CL cl:rest is imported in the :cmn package and redefined -- which breaks a lot of other code, when CMN is loaded. For various Lisp implementations cl:rest is only shadow-imported into CMN. I tried just to insert a (:shadow "REST") or something similar into the defpackage, without success yet. Any proposal? It was somewhat disturbing first to find the cause of the problem, because the docstring is still that of #'cl:rest, though the definition is changed: (describe #'cl:rest) -> # is function. Arguments: (&rest objects) Function documentation: Means the same as the cdr of a list. Its declared argument types are: (LIST) Its result type is: T On Monday, 4/1/02 02:34:05 pm [-1] it was compiled from: [...]/cmn/source/cmn2.lisp Created: Thursday, 9/3/98 04:18:10 pm [-1] Regards, Torsten Anders From bil at ccrma.Stanford.EDU Sat May 18 04:11:20 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Sat, 18 May 2002 04:11:20 -0700 Subject: [CM] Problems with cmn:rest in CMU In-Reply-To: References: Message-ID: <200205181111.EAA29174@cmn14.stanford.edu> > I tried just to insert a (:shadow "REST") or > something similar into the defpackage, without success yet. Any proposal? How about (:shadow common-lisp:rest)? From taube at uiuc.edu Mon May 20 10:21:51 2002 From: taube at uiuc.edu (Rick Taube) Date: Mon, 20 May 2002 12:21:51 -0500 Subject: [CM] cm-2.3.4 available Message-ID: CM 2.3.4 is available from ccrma-ftp: sources (linux, mac, windows): ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/sources/cm-2.3.4.tar.gz ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/sources/cm-2.3.4.sea.bin ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/sources/cm-2.3.4.zip binaries (mac/windows): ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/binaries/cm-2.3.4-ppc.sea.bin ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/binaries/cm-2.3.4-win32.zip Whats new: o CM ported to SBCL Common Lisp 0.7.2 o New RANGE pattern enumerates numbers. Can also be used for cycles and bounded random walks. o New TRANSPOSER object replaces the hackish intervals macro. The object also supports 12-tone manipulations like inversion, retrograde, retrograde-inversion and modulus from an offset. o DEFPROCESS can now return a list of processes. See the new file "cm:examples;reich.cm" for an example of this. The file "cm:examples;ligeti.cm" also contains process lists as well as uses of the new RANGE and TRANPOSER objects. o The SPROUT and OUTPUT process clauses now allow lists of objects to be sprouted or output. o New "typed" pattern inits can be used in place of OF: NOTES KEYNUMS RHYTHMS AMPLITUDES INTERVALS These all cause data specified as their value to be parsed according to the function for which the init is named. For example, the following two are equivalent: (new cycle of '(c5 d e) parsing #'note) (new cycle notes '(c5 d e)) o KEYNUM and NOTE now support an explicit :TO scale. o New tuning entries in cm:etc;examples;scales.cm for Sargam, Just, Meantone, Werckmeister 3, and Wendy Carlos' Alpha scale. o New LOOKUP function performs non-interpolating x-to-y lookup. Y values do not need to be numbers. o New RESCALE-ENVELOPE rescales an envelope according to new upper and lower bounds on either axis. o New SCALE-MOD function performs modulus operations on notes. o DEFOBJECT now defines slot accessors for slot discriptions that don't explicity provide them. The name of the accessor will be - where is the name of the object being defined and is the name of the slot. To declare a slot without any accessor specify :ACCESSOR NIL in its description. o Examples of pattern definitions like: (new cycle a b c) have been removed from documentation. Examples now always show explicit OF initializations like: (new cycle of '(a b c)) o The (new pattern ... in ...) hack has been removed from documentation but continues to work. o TRANSPOSE now accepts note names in its second arg. o New contrib file: cm:etc;contrib;bezier.lisp implements bezier curves in Plotter thanks to Bret Battey. o More example tunings and modes added to "cm:examples;scale.cm" o cm:ect;contrib;cm.el supports easy point and region evaluation for inf-lisp in XEMACS. also supples an inferior lisp that runs in its own frame and key bindings that allow APPLE commands for eval, copy, paste etc. o Lots of mode/tuning bugs fixed, thanks to Bret Battey for finding them! From carl.boingie at rcn.com Mon May 20 14:27:48 2002 From: carl.boingie at rcn.com (Carl Edwards) Date: Mon, 20 May 2002 17:27:48 -0400 Subject: [CM] CM on a PC References: Message-ID: <01d601c20049$1c90a7d0$c7e47ad1@laptop> Hi all, A few newbie questions here, if anyone has the time... I had thought I had asked some of these questions months ago when I first began investigating lisp and CM, but now, looking through my list history I guess I may have only *thought* I did. If this is a repeat though, please excuse my lousy archiving skills. Okay, so I've read enough Winston, Touretzky, and Cope to feel that I should try to actually make an example (or two) in CM. First I want to make sure I'm not expecting something to happen that won't... 1. I see that there are special instructions for getting midi to work on both Macs and SGIs. Does this mean that midi does not work on PCs or that it woks with no special preperations? 2. Plotter is huge for me. I'm very much a visual person. Does Plotter work on PCs or is platform specific? 3. Does anyone know if CM works in the (beautifully documented) Franz trial edition? Or should I just plan on using CLisp? Or some alternative? Thanks in advance for lending a hand, Carl Edwards From taube at uiuc.edu Mon May 20 17:49:36 2002 From: taube at uiuc.edu (Rick Taube) Date: Mon, 20 May 2002 17:49:36 -0700 Subject: [CM] CM on a PC References: <01d601c20049$1c90a7d0$c7e47ad1@laptop> Message-ID: <000f01c20061$6225fe40$76197e82@music.uiuc.edu> > 1. I see that there are special instructions for getting midi to work on > both Macs and SGIs. Does this mean that midi does not work on PCs or that it > woks with no special preperations? It will work on windows if you write midi files. If you do this then the Windows Media Player will automatically get called whenever a .midi file is output. So in the examples like reich.cm whenever you see a "midi.port" you should change it to "whatever.midi" where "whatever" is the name of the file you want to write. By default CM will write this file to the cm:tmp; directory. you can change this by specifyong some other directory in the file name. I think CLISP will allow these pathnaes to use the unix directory characger / instead of the the windows \ char (which always has to be doubled in lisp since its an "escape" char.) Also, you should explicity set the tempo of you midi files to 60 instead of the default 120 that is specified by the MIDI protocol. you do this by using the :tempo arg to events, ie (events ... "test.midi" :tempo 60) > 2. Plotter is huge for me. I'm very much a visual person. Does Plotter work > on PCs or is platform specific? no sorry it doesnt. it only works on the mac right now. > 3. Does anyone know if CM works in the (beautifully documented) Franz trial > edition? Or should I just plan on using CLisp? Or some alternative? > it should work fine in Franz trial if they give you enough heap size. it also works in clisp 2.27 and 2.28 on windows. you can get the prebuilt clisp binary of cm from ccrma's ftp site. > From taube at uiuc.edu Tue May 21 11:45:23 2002 From: taube at uiuc.edu (Rick Taube) Date: Tue, 21 May 2002 13:45:23 -0500 Subject: [CM] updated 3m-2.3.4 docs Message-ID: The file: ftp://ccrma-ftp.stanford.edu/pub/Lisp/cm/patches/cm-2.3.4/cm-2.3.4-doc.tar.gz contains a newly generated documentation tree with updated/validated html links, correct footers in the reference manual and a gif of the object hierarchy as it now stands. Ill remake the source tarfiles tomorrow to include the updated docs, my apologies i forgot yesterday. -rick From bil at ccrma.Stanford.EDU Thu May 23 04:37:12 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 23 May 2002 04:37:12 -0700 Subject: [CM] CLM-on-Mac improvements Message-ID: <200205231137.EAA09238@cmn14.stanford.edu> Michael Klingbeil has made many more improvements to the Mac (MCL) version of CLM: optimization switches, interruptible run loop, documentation, clm1.lisp (and hence ATS). These are now in the clm tarball at ccrma-ftp. Needless to say, thank you! From bil at ccrma.Stanford.EDU Thu May 23 04:39:58 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 23 May 2002 04:39:58 -0700 Subject: [CM] snd and opengl Message-ID: <200205231140.EAA09248@cmn14.stanford.edu> I've added support for OpenGL to Snd -- there's an example of a spectrogram in grfsnd.html; the configure switch is --with-gl. Also gl.c is a set of GL/Guile bindings in the same style as xm.c and xg.c. Currently works in Motif only (and of course there are a million things-to-do -- there's a partial list in snd-chn.c around line 1970). From dlphilp at bright.net Thu May 23 07:04:47 2002 From: dlphilp at bright.net (Dave Phillips) Date: Thu, 23 May 2002 10:04:47 -0400 Subject: [CM] snd and opengl References: <200205231140.EAA09248@cmn14.stanford.edu> Message-ID: <3CECF6FF.39C0223B@bright.net> Bill Schottstaedt wrote: > I've added support for OpenGL to Snd -- there's an example > of a spectrogram in grfsnd.html; the configure switch is > --with-gl. Also gl.c is a set of GL/Guile bindings in the > same style as xm.c and xg.c. Currently works in Motif only > (and of course there are a million things-to-do -- there's > a partial list in snd-chn.c around line 1970). Wow, that's very nice, Bill ! Much more useful than the old GL example. It will be interesting to see where you take this feature. Btw, how can I turn it off to revert to the normal FFT display ? On a down note: I'm still having a terrible time with ALSA/SBLive and Snd. I'm getting persistent xruns on playback (haven't even tried recording recently), no matter how I invoke (set! (dac-size)). I've plugged in various values, Snd doesn't complain, but nothing improves. I feel like I'm missing something about buffers, but where/how else would I change them if not via dac-size ? OTOH I built Snd with just OSS support. Of course it doesn't report any xruns, but the traveling cursor is out of sync with the playback. Any suggestions ?? Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org From bil at ccrma.Stanford.EDU Fri May 24 04:47:15 2002 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 24 May 2002 04:47:15 -0700 Subject: [CM] snd and opengl In-Reply-To: <3CECF6FF.39C0223B@bright.net> References: <200205231140.EAA09248@cmn14.stanford.edu> <3CECF6FF.39C0223B@bright.net> Message-ID: <200205241147.EAA10800@cmn14.stanford.edu> > Btw, how can I turn it off to revert to the normal FFT display ? I added a switch named "with-gl" -- set it to #f to revert to the previous style of spectrogram. > OTOH I built Snd with just OSS support. Of course it doesn't report any > xruns, but the traveling cursor is out of sync with the playback. Any > suggestions ?? This is caused by the "fragments" (i.e. buffers) on the audio card -- Snd is using its current read location to set the cursor location, but that can be as much as 1/2 second ahead of what's coming out of the speakers. You can improve it by using fewer (or smaller?) fragments -- this also improves the responsiveness of the various controls, but at the cost of clicks. My "TODO" list includes trying to readback the fragment settings to fixup this bug; I'll bump it higher in the queue. From Julien.Quint at imag.fr Fri May 24 04:51:18 2002 From: Julien.Quint at imag.fr (Julien Quint) Date: Fri, 24 May 2002 13:51:18 +0200 Subject: [snd] cursor out of sync (was Re: [CM] snd and opengl) In-Reply-To: <3CECF6FF.39C0223B@bright.net> References: <200205231140.EAA09248@cmn14.stanford.edu> <3CECF6FF.39C0223B@bright.net> Message-ID: <20020524115118.GA5713@houdini.imag.fr> On Thu, May 23, 2002 at 10:04:47AM -0400, Dave Phillips wrote: > OTOH I built Snd with just OSS support. Of course it doesn't report any > xruns, but the traveling cursor is out of sync with the playback. Any > suggestions ?? I had the same problem for a while and finally found a solution somewhere in the snd documentation. It seems to be caused by the default buffer sizes that are too small. I am using the following: (set! (dac-size) 65536) (set-oss-buffers 2 12) in my .snd init file and it works like a charm! Julien BTW -- Thanks Dave for your articles on the O'Reilly Network, that helped me a lot in getting started with Snd. Thanks to Bill also, the doc is a little demanding but very helpful. From dlphilp at bright.net Fri May 24 06:11:19 2002 From: dlphilp at bright.net (Dave Phillips) Date: Fri, 24 May 2002 09:11:19 -0400 Subject: [snd] cursor out of sync (was Re: [CM] snd and opengl) References: <200205231140.EAA09248@cmn14.stanford.edu> <3CECF6FF.39C0223B@bright.net> <20020524115118.GA5713@houdini.imag.fr> Message-ID: <3CEE3BF7.62D88AC2@bright.net> Hi, Julien: Actually, I knew about that setting and thought that's what I already had in my .snd file. Haha, I forgot I had it commented out, so I changed it back, recompiled Snd without ALSA, and indeed the cursor sync is fine now. Thank you for the reminder ! Best regards, == Dave Phillips The Book Of Linux Music & Sound at http://www.nostarch.com/lms.htm The Linux Soundapps Site at http://linux-sound.org Julien Quint wrote: > > On Thu, May 23, 2002 at 10:04:47AM -0400, Dave Phillips wrote: > > OTOH I built Snd with just OSS support. Of course it doesn't report any > > xruns, but the traveling cursor is out of sync with the playback. Any > > suggestions ?? > > I had the same problem for a while and finally found a solution somewhere > in the snd documentation. It seems to be caused by the default buffer sizes > that are too small. I am using the following: > > (set! (dac-size) 65536) > (set-oss-buffers 2 12) > > in my .snd init file and it works like a charm! > > Julien > > BTW -- Thanks Dave for your articles on the O'Reilly Network, that helped me > a lot in getting started with Snd. Thanks to Bill also, the doc is a little > demanding but very helpful. > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist -- From bbattey at u.washington.edu Mon May 27 02:16:31 2002 From: bbattey at u.washington.edu (bbattey at u.washington.edu) Date: Mon, 27 May 2002 02:16:31 -0700 (PDT) Subject: [CM] CLM-on-Mac improvements In-Reply-To: <200205231137.eaa09238@cmn14.stanford.edu> Message-ID: *Something* in the new CLM build appears to be causing severe compile difficulties with one of my instruments (mac/mcl). It is a very fat (not phat, but fat) instrument, broken up into about 10 macro calls. Prior to this last update, it took 40-60 seconds to compile on my computer. With the new version, I'm not actually sure it can compile at all: I give up after 15 minutes. Specifically, CLM executes the MrC -shared_lib_export on -opt speed,unroll,unswitch (etc.) command, ToolServer launches... but ToolServer never succesfully completes its work. At first I assumed this was a bug in my code that was not being trapped properly and causing an infinite loop in MrC. So I commented out all of my macro calls. Compile worked. I added in the macros one by one. The compile time kept expanding, exponentially it seems, with each addition. Until it exceeded 15 minutes... At which time I gave up and compiled it with the old CLM. I could send the instrument to someone if that would help, since I'm not sure where to go from here in trying to track down the problem. -=Bret Bret Battey, DMA http://BatHatMedia.com ---------------------------------------------------------------------- Center for Digital Arts and Experimental Media University of Washington, Seattle http://www.washington.edu/dxarts/ 2001-2002 Fulbright Scholar to India, Pune University, Pune, Maharashtra Department of Computer Science http://cs.unipune.ernet.in/ On Thu, 23 May 2002, Bill Schottstaedt wrote: > Michael Klingbeil has made many more improvements to the > Mac (MCL) version of CLM: optimization switches, interruptible > run loop, documentation, clm1.lisp (and hence ATS). These > are now in the clm tarball at ccrma-ftp. Needless to say, > thank you! > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From g.niestijl at rra.nl Mon May 27 02:18:36 2002 From: g.niestijl at rra.nl (Gerrit Niestijl) Date: 27 May 2002 11:18:36 +0200 Subject: [CM] Snd + alsa: how use digital in Message-ID: Hi, Recently I installed a sound card with digital in (with cmi8738 chip) in my linux system with alsa. With 'arecord -D hw:0.2' I can succesfully record from my digital input. How can I do the same with with Snd? The digital inputs do not appear on the record window. I compiled Snd with alsa support. -- Gerrit From bbattey at u.washington.edu Mon May 27 03:30:24 2002 From: bbattey at u.washington.edu (bbattey at u.washington.edu) Date: Mon, 27 May 2002 03:30:24 -0700 (PDT) Subject: [CM] Broken?: with-psound on Mac Message-ID: Sorry to keep being the bearer of seemingly-bad news! Has anyone been using CLM2 with-psound recently? Running this simple example in MCL/MPW, modeled after examples I could find in the documentation: (with-psound () (simpfm 0 4 '(0 220 1 440))) I get: ? mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors!mus_write: no file descriptors! Bret Battey, DMA http://BatHatMedia.com ---------------------------------------------------------------------- Center for Digital Arts and Experimental Media University of Washington, Seattle http://www.washington.edu/dxarts/ 2001-2002 Fulbright Scholar to India, Pune University, Pune, Maharashtra Department of Computer Science http://cs.unipune.ernet.in/ From michael at klingbeil.com Mon May 27 11:17:55 2002 From: michael at klingbeil.com (Michael Klingbeil) Date: Mon, 27 May 2002 14:17:55 -0400 Subject: [CM] CLM-on-Mac improvements In-Reply-To: References: Message-ID: MPW with optimization can be extremely slow to compile large instruments. Given enough time the compile probably will complete. (for example I tried this on piano.ins -- it took forever to compile but it did eventually finish successfully). However you can just turn off optimization: (definstrument (myinstrument :c-options "") ...) In some instances I found that running with optimization would result in about 90% speed increase at runtime (for example with fm-violin.clm running v.ins and reverb) so I thought it might be a worthwhile default. Perhaps the default should be no optimization since it can be so slow to compile. I think the compile time is somewhat reduced using slightly less agressive optimization. For example: (definstrument (myinstrument :c-options "-opt speed,nointer,norep,unroll") The interruptable run loop in the new CLM MacOS build will result in some slowdown, so if you don't turn on optimization, the new CLM MacOS build will end up being slightly slower than before. I suppose the interruptable run loop could be another compile time option. I think the ultimate solution to any MacOS problems is to use CLM on Linux... :( >*Something* in the new CLM build appears to be causing severe compile >difficulties with one of my instruments (mac/mcl). It is a very fat (not phat, >but fat) instrument, broken up into about 10 macro calls. Prior to this last >update, it took 40-60 seconds to compile on my computer. With the new >version, I'm not actually sure it can compile at all: I give up after 15 >minutes. > >Specifically, CLM executes the MrC -shared_lib_export on -opt >speed,unroll,unswitch (etc.) command, ToolServer launches... but >ToolServer never succesfully completes its work. > >At first I assumed this was a bug in my code that was not being trapped >properly and causing an infinite loop in MrC. So I commented out all of my >macro calls. Compile worked. I added in the macros one by one. The >compile time kept expanding, exponentially it seems, with each addition. >Until it exceeded 15 minutes... > >At which time I gave up and compiled it with the old CLM. > >I could send the instrument to someone if that would help, since I'm not >sure where to go from here in trying to track down the problem. > >-=Bret > > >Bret Battey, DMA http://BatHatMedia.com >---------------------------------------------------------------------- >Center for Digital Arts and Experimental Media >University of Washington, Seattle http://www.washington.edu/dxarts/ > >2001-2002 Fulbright Scholar to India, Pune University, Pune, Maharashtra >Department of Computer Science http://cs.unipune.ernet.in/ > > > >On Thu, 23 May 2002, Bill Schottstaedt wrote: > >> Michael Klingbeil has made many more improvements to the >> Mac (MCL) version of CLM: optimization switches, interruptible >> run loop, documentation, clm1.lisp (and hence ATS). These >> are now in the clm tarball at ccrma-ftp. Needless to say, >> thank you! >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> > > > >_______________________________________________ >Cmdist mailing list >Cmdist at ccrma.stanford.edu >http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From nando at ccrma.Stanford.EDU Mon May 27 15:31:31 2002 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: Mon, 27 May 2002 15:31:31 -0700 (PDT) Subject: [CM] Snd + alsa: how use digital in In-Reply-To: Message-ID: > Recently I installed a sound card with digital in (with cmi8738 chip) > in my linux system with alsa. With 'arecord -D hw:0.2' I can succesfully record > from my digital input. How can I do the same with with Snd? The > digital inputs do not appear on the record window. I compiled Snd with alsa support. You could try to set up an environment variable before starting snd to point to that particular device. This is the way snd reacts to env variables: - searched for in the following order: SNDLIB_ALSA_PLAYBACK_DEVICE defines the name of the playback device SNDLIB_ALSA_CAPTURE_DEVICE defines the name of the capture device SNDLIB_ALSA_DEVICE defines the name of the playback and capture device use the first two if the playback and capture devices are different or the third if they are the same. So you could try: SNDLIB_ALSA_DEVICE="hw:0,2" snd if you are using bash as your shell This should use the digital i/o as the input output device. It would also be possible to concatenate several devices using a definition in the .asoundrc file but that would involve understanding its arcane configuration language, which I don't. The current snd alss 0.9 code only looks at the first device it finds (normally hw:0,0). -- Fernando From bbattey at u.washington.edu Thu May 30 03:10:13 2002 From: bbattey at u.washington.edu (bbattey at u.washington.edu) Date: Thu, 30 May 2002 03:10:13 -0700 (PDT) Subject: [CM] CLM-on-Mac improvements In-Reply-To: Message-ID: Michael Klinbeil wrote: >MPW with optimization can be extremely slow to compile large >instruments. Given enough time the compile probably will complete. Thanks, Michael. Sure enough, my large instrument does compile in circa 23 minutes. (Though the gain at instrument runtime is modest in this case: it only reduces the runtime on a test sample from 12 minutes to 11 minutes.) I can see arguments both ways regarding whether optimization should be the default behavior. I suspect it will be most convenient if the optimization is off by default, since most compiles are executed while debugging. So one will want to easily debug and quickly execute compilations for testing, then execute a more complex command for compiling with optimization -- once -- after the instrument is debugged. Also, on the highly likely scenario that someone doesn't read the documentation of the optimization option (to come? or did I miss it?), and optimization was standard, they might throw up their hands in despair at the long compile times and bail out on CLM. > I think the ultimate solution to any MacOS problems is to use CLM on > Linux... :( Alas! The analysis/composition tool I've been creating is also highly reliant on Rick's Mac-only CM plotter for displaying the results coming out of the system (fed in part by CLM analysis instruments). Ah, the ever- elusive cross-platform holy grail... Just can't win for the losing... ;-) -=Bret From taube at uiuc.edu Thu May 30 08:58:20 2002 From: taube at uiuc.edu (Rick Taube) Date: Thu, 30 May 2002 08:58:20 -0700 Subject: [CM] CLM-on-Mac improvements References: Message-ID: <001f01c207f2$d3217320$171e7e82@music.uiuc.edu> > Alas! The analysis/composition tool I've been creating is also highly > reliant on Rick's Mac-only CM plotter for displaying the results coming out > of the system (fed in part by CLM analysis instruments). Ah, the ever- > elusive cross-platform holy grail... Just can't win for the losing... ;-) > i will get something plotter-like working in linux, but not before cm is working in scheme