From taube at uiuc.edu Mon Nov 3 14:02:40 2003 From: taube at uiuc.edu (Rick Taube) Date: Mon, 3 Nov 2003 16:02:40 -0600 Subject: [CM] Installing CM under Cygwin on Windows XP In-Reply-To: <012501c39da9$ee644b50$0200a8c0@xp1> Message-ID: <000001c3a256$34234640$811c7e82@music.uiuc.edu> I finally got cygwin installed at home on my old dell. To get CM to compile in Cygwin/clisp, edit the file src/cm.lisp and change the lines #+(and clisp unix) (if (find ':pc386 *features*) to: #+(and clisp unix) (if (or (find ':pc386 *features*) (find ':cygwin *features*)) That's it Ill commit the change to CVS tomorrow morning when Im at work. Ill make a new tarball as soon as I fix a listener.el bug in Emacs/Linux. > -----Original Message----- > From: cmdist-admin at ccrma.Stanford.EDU > [mailto:cmdist-admin at ccrma.Stanford.EDU] On Behalf Of James Ravan > Sent: Tuesday, October 28, 2003 5:19 PM > To: cmdist at ccrma.Stanford.EDU > Subject: Re: [CM] Installing CM under Cygwin on Windows XP > > > > > *** - The value of TOK must be one of DARWIN, LINUX > > > The value is: CYGWIN_NT-5.1 > > > > > > > Well this is certainly a "bug" -- ive only tried cm in > Guile / cygwin > > and it did work there. > > But I don't think this is the problem you originally > posted. That one > > seems like an end of line problem, as Ralf suggested. > > AHA! I think I understand what the original problem was. > CLISP seems to be > reading the terminal in what I call "raw" mode, that is, including > keystrokes like . Depending on where I edited the > load command > with characters, I could get CLISP to return all > sorts of error > messages, including the original one I mentioned. > > So given that, what can I do about the real bug above? And if > anyone else > uses CLISP, what's going on with input editing? > > regards, > -jim > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > From pertid at chello.se Mon Nov 3 11:26:33 2003 From: pertid at chello.se (Per Bergqvist) Date: Mon, 3 Nov 2003 20:26:33 +0100 Subject: [CM] OSX-openmcl - problems using :versions Message-ID: Hi all! I?m using the 'cm-2.4.0.dmg.gz' distr. of CM together with the GUI Emacs. Does anyone else have this problem ? What can I do about it ? The ':versions' feature is great when testing things out and doing automatic backups before any unpredictable new results !! --- Sample session using 'VERSIONS-feature' ------- ;; as in 'intro.cm' using the absolute path ;; "/tmp/" (which in OSX is a (writeable) symlink ;; to "/private/tmp/" directory. ;; Before commands below I?ve successfully made ;; the "test.midi" file in this directory. ;; Upto point No. 3. 'Initializing 10 objects' ;; everything has gone as expected... ? (io "test.midi" :versions true) > Error: Not initializations for MIDI-FILE-STREAM: (:VERSIONS T). > While executing: # > Type :POP to abort. Type :? for other options. 1 > :POP ;; What now ? Can CM visit the file properly ? ;; Is CM insure of what stream-type .midi represents ? ;; At least make sure the path to file is correct: ? (cd) #P"/Users/myuserdir/" ? (cd "/private/tmp/") #P"/private/tmp/" ? (io "/private/tmp/test.midi" :versions true) > Error: Not initializations for MIDI-FILE-STREAM: (:VERSIONS T). > While executing: # > Type :POP to abort. Type :? for other options. 1 > :POP ;; Giving up ! Not the first time ... ? (quit) Process inferior-lisp finished ;; EOF ;;;;;;;;;;;;;;;;;;;;;;;;;; -- Best regards Per Bergqvist Stockholm, Sweden From taube at uiuc.edu Tue Nov 4 06:08:15 2003 From: taube at uiuc.edu (Rick Taube) Date: Tue, 4 Nov 2003 08:08:15 -0600 Subject: [CM] Installing CM under Cygwin on Windows XP In-Reply-To: <021501c3a299$425be300$0200a8c0@xp1> Message-ID: <550DE196-0ED0-11D8-BA63-000A95674CE4@uiuc.edu> Yes, listener.el is meant as a substitute for ilisp. its built on top of inf-lisp. It's to be used with a graphic (non-tty) Emacs or Xemacs and provides a dedicated Listener frame and a Listener menu for all lisp-mode buffer. listener.el gives much better remote evaluation and error aborting than inf-lisp. Im making a new version of listener.el now -- im testing it in emacs/linux xemacs/windows and emacs/xemacs/osx. I spent hours downloading emacs for cygwin only to find that it was just the crappy old terminal version! maybe you have to congidure x windows in cygwin somehow before it works?? Tuesday, Nov 4, 2003, at 00:02 America/Chicago, James Ravan wrote: > Professor, > > Thanks for working out the bug! I editted cm.lisp and finished the > installation process. I also tried executing xcm and that seemed to > work > also! So, can I abandon trying to get ILISP to work? listener.el seems > to be > doing the same sort of thing... > > regards and thanks, > -jim > >> I finally got cygwin installed at home on my old dell. To get CM to >> compile in Cygwin/clisp, edit the file src/cm.lisp and change the >> lines >> >> #+(and clisp unix) >> (if (find ':pc386 *features*) >> >> to: >> >> #+(and clisp unix) >> (if (or (find ':pc386 *features*) >> (find ':cygwin *features*)) >> >> That's it Ill commit the change to CVS tomorrow morning when Im at >> work. >> Ill make a new tarball as soon as I fix a listener.el bug in >> Emacs/Linux. From taube at uiuc.edu Tue Nov 4 06:34:22 2003 From: taube at uiuc.edu (Rick Taube) Date: Tue, 4 Nov 2003 08:34:22 -0600 Subject: [CM] OSX-openmcl - problems using :versions In-Reply-To: Message-ID: Do this to turn on versioning for midi files: (set-midi-file-versions! t) that is, versioning is now on a per file type basis, rahter than on a per-file basis. Somehow these versioning functions got omitted from the dictionary, sorry! Ill try to fix that in the next day or so. > Hi all! > > I?m using the 'cm-2.4.0.dmg.gz' distr. of CM together > with the GUI Emacs. > > Does anyone else have this problem ? > What can I do about it ? > The ':versions' feature is great when testing > things out and doing automatic backups before > any unpredictable new results !! \ From taube at uiuc.edu Tue Nov 4 06:47:00 2003 From: taube at uiuc.edu (Rick Taube) Date: Tue, 4 Nov 2003 08:47:00 -0600 Subject: [CM] OSX-openmcl - problems using :versions In-Reply-To: Message-ID: >> >> I?m using the 'cm-2.4.0.dmg.gz' distr. of CM together >> with the GUI Emacs. btw I recently found (and switched to) a less buggy/better looking version of Emacs for OSX: http://www.mindlube.com/download/files/emacs-osx-10-25-03.dmg it seems to scroll better using the scroll-bar and it handles shell args much better than the one at porkrind. the only thing that it doesnt do is install a link to the Emacs.app as /usr/bin/emacs and the site-lisp directories so you will have to do this by hand. im working on a new doc emacs.html that will hopefully explain the various options for using emacs/xmacs with clm cmn cm etc. From vincent at arkesteijn.net Tue Nov 4 13:42:37 2003 From: vincent at arkesteijn.net (Vincent Arkesteijn) Date: Tue, 4 Nov 2003 22:42:37 +0100 Subject: [CM] multiple sound cards Message-ID: <20031104214237.GA26389@vja.demon.nl> Hi, I decided I'd try to install and play with CLM a bit. I downloaded ftp://ccrma-ftp.stanford.edu/pub/Lisp/clm-2.tar.gz today. Two tiny comments and one request for help: * I normally put all common lisp related stuff in ~/common lisp (note the space). This breaks most calls to cc and ld in all.lisp, since the space is not escaped from the shell when calling cc and ld. I started putting lots of "'" in a lot of calls to concatenate in all.lisp, but there were just too many. So I cheated and moved clm to another directory. * I normally use SBCL (on Linux 2.4). README.clm says (near the start): "If your systems isn't supported yet, load "all.lisp" anyway, ...". So I did that. I was quite surprised to see that it seemed to compile rather well, but a while later I read (all the way at the end of the same file): "SBCL isn't supported yet ...". I would have appreciated to have read that earlier, so could you move this comment someplace closer to the list of supported platforms? [Now switching to CMU CL 18c] * I have two sound cards. /dev/dsp is a Logitech Soundman Games (don't laugh) and /dev/dsp1 is a Soundblaster 16 clone. An excerpt from dmesg: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 SB 3.01 detected OK (220) at 0x220 irq 5 dma 1 SB DSP version is just 3.01 which means that your card is several years old (8 bit only device) or alternatively the sound driver is incorrectly configured. sb: Creative ViBRA16C PnP detected sb: ISAPnP reports 'Creative ViBRA16C PnP' at i/o 0x260, irq 7, dma 3, 5 SB 4.13 detected OK (260) at 0x260 irq 7 dma 3,5 at 0x330 irq 7 dma 0,0 sb: 2 Soundblaster PnP card(s) found. Both cards work well with other software. CLM doesn't seem to like 8-bit cards, so that rules out /dev/dsp (I'm not really complaining about that). After this, I tried to use /dev/dsp1. After reading some of the source, I tried (setf *clm-player* (lambda (name) (sl-dac name 1))) Is that the normal way to select a different sound card? It still complained about little endian short (16 bits) not being available, so apparently it didn't help. Some more reading taught me about mus-audio-systems: * (mus-audio-systems) 1 * This seems to suggest that clm only found my first sound card. Am I correct? I tried to read audio.c and to understand how the sound cards (= audio systems ?) are discovered, but somehow I got lost in all the #ifdef's. Could you pherhaps suggest some more diagnostics I could perform? Regards, Vincent Arkesteijn. From bil at ccrma.Stanford.EDU Wed Nov 5 06:05:19 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 05 Nov 2003 06:05:19 -0800 Subject: [CM] multiple sound cards In-Reply-To: <20031104214237.GA26389@vja.demon.nl> References: <20031104214237.GA26389@vja.demon.nl> Message-ID: <3FA9039F.2050002@ccrma> (mus-audio-describe) will try to report what sound cards it found. 8-bit cards should not be a problem. From ktilton at nyc.rr.com Wed Nov 5 16:43:52 2003 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 05 Nov 2003 19:43:52 -0500 Subject: [CM] ACL/win trick? Message-ID: <3FA99948.80004@nyc.rr.com> I am playing with one of the drum.ins instruments I found on the CCRMA site, so I had a problem with ACL under windows: once a DLL was loaded it was apparently held open or something, so a subsequent compile of the (definstrument...) (or compile-file of the same .ins) would fail on "unable to write file" or something. After that, using the instrument complained about the function no longer being loaded. Anyway, here's the fix I use: (defun unload-instrument (ins-name) (dolist (dll (ff:list-all-foreign-libraries)) (when (search (symbol-name ins-name) (pathname-name dll)) (print `(Unloading foreign library ,dll)) (ff:unload-foreign-library dll)))) Then: (unload-instrument 'djembe) where the finstrument name was actually fm-djembe (SEARCH looks for subsequences) Big warning: since the unloading goes by matching any substring, if I had three or four (the way developers often do) I'd zap them all with the above. So if I do start doing djembesoft and djembezzz and djembe123, I need to "unload" with enough of the name to nail the one I am after. fwiw, kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From vincent at arkesteijn.net Wed Nov 5 06:59:07 2003 From: vincent at arkesteijn.net (Vincent Arkesteijn) Date: Wed, 5 Nov 2003 15:59:07 +0100 Subject: [CM] multiple sound cards In-Reply-To: <3FA9039F.2050002@ccrma> References: <20031104214237.GA26389@vja.demon.nl> <3FA9039F.2050002@ccrma> Message-ID: <20031105145907.GA28285@vja.demon.nl> Thanks for your reply. On Wed, Nov 05, 2003 at 06:05:19AM -0800, Bill Schottstaedt wrote: > (mus-audio-describe) will try to report what sound > cards it found. * (mus-audio-describe) OSS version: 1.9.8 1 card found /dev/music: No such file or directory no synth found -------------------------------- /dev/dsp: mixer recording active stereo current channel source source device level -------- -------- -------- -------- -------- Vol no no yes 0.74 0.74 Synth no no yes 0.75 0.75 Pcm no no yes 0.72 0.72 Line yes no yes 0.75 0.75 Mic yes yes no 0.16 CD yes no yes 0.75 0.75 -------------------------------- /dev/dsp0: defaults: sampling rate: 8000, chans: 1, sample size: 8 bits, block size: 4096 bytes (16 fragments) supported formats: mulaw unsigned byte (default) sample srate channels size min max 1 8 4000 43478 2 8 4000 21739 -------------------------------- /dev/mixer1: mixer recording active stereo current channel source source device level -------- -------- -------- -------- -------- Vol no no yes 0.96 0.96 Bass no no yes 0.75 0.75 Trebl no no yes 0.75 0.75 Synth yes no yes 0.75 0.75 Pcm no no yes 0.93 0.93 Spkr no no no 0.75 Line yes no yes 0.75 0.75 Mic yes yes no 0.16 CD yes no yes 0.75 0.75 Mix no no no 0.00 IGain no no yes 0.75 0.75 OGain no no yes 0.75 0.75 -------------------------------- /dev/dsp1: defaults: sampling rate: 8000, chans: 1, sample size: 8 bits, block size: 4096 bytes (16 fragments) supported formats: mulaw unsigned byte (default) signed little-endian short full duplex sample srate channels size min max 1 8 5000 44100 1 16 5000 44100 2 8 5000 44100 2 16 5000 44100 -------------------------------- NIL * All the mixer settings, their levels and the available word sizes and sample rates seem all right, except for the max sample rates on the first sound card. However, the "1 card found" seems to contradict the rest of the report. Also, it looks like the line that says '/dev/dsp:' should say '/dev/mixer:' instead and the line that says '/dev/dsp0:' should say '/dev/dsp:'. There is no /dev/dsp0 on my system, only: crw-rw---- 1 root audio 14, 3 Aug 20 1999 /dev/dsp crw-rw---- 1 root audio 14, 19 Aug 20 1999 /dev/dsp1 crw-rw---- 1 root audio 14, 0 Aug 20 1999 /dev/mixer crw-rw---- 1 root audio 14, 16 Aug 20 1999 /dev/mixer1 Any ideas? > 8-bit cards should not be a problem. I can't reproduce the "data format 10 (little endian short (16 bits)) not available on /dev/dsp" error message, so I'm not sure what I was doing wrong yesterday. Today, the first violin example in the manual doesn't give me an error message anymore, but no sound either. I assume that could be related to the sound card detection problem? Vincent. From finnendahl at folkwang-hochschule.de Fri Nov 7 03:08:06 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Fri, 7 Nov 2003 12:08:06 +0100 Subject: [CM] cm install fails with cmucl Message-ID: <20031107110806.GA1073@finnendahl.de> Hi, trying to migrate common music from clisp to cmucl, loading cm.lisp dies with: "File-error in function TRUENAME: The file "/Lisp/src/iter.lisp" does not exist." appended is the complete output and the backtrace. "/Lisp" is symlinked to the actual cm directory which contains the latest sources from CVS. -- Orm ---------------------------------------------------------------------- * (load "/Lisp/src/cm.lisp") ; Loading #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp". ; Loading "/Lisp/bin/pkg.x86f". ; Loading "/Lisp/bin/cmu.x86f". ; Loading "/Lisp/bin/clos.x86f". ; Compiling "/Lisp/src/iter.lisp". File-error in function TRUENAME: The file "/Lisp/src/iter.lisp" does not exist. Restarts: 0: [CONTINUE] Return NIL from load of "/Lisp/src/cm.lisp". 1: [ABORT ] Return to Top-Level. Debug (type H for help) (TRUENAME #p"/Lisp/src/iter.lisp") Source: (ERROR 'SIMPLE-FILE-ERROR :PATHNAME PATHNAME :FORMAT-CONTROL ...) 0] Backtrace 0: (TRUENAME #p"/Lisp/src/iter.lisp") 1: (C::TRY-WITH-TYPE #p"/Lisp/src/iter.lisp" "lisp" T) 2: (C::VERIFY-SOURCE-FILES "/Lisp/src/iter.lisp") 3: (COMPILE-FILE "/Lisp/src/iter.lisp" :OUTPUT-FILE "/Lisp/bin/iter.x86f" :ERROR-FILE ...) 4: (NIL "iter") 5: ("Top-Level Form")[:TOP-LEVEL] 6: (COMMON-LISP::SLOLOAD #) 7: (COMMON-LISP::INTERNAL-LOAD #p"/Lisp/src/cm.lisp" #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp" :ERROR :SOURCE) 8: (COMMON-LISP::INTERNAL-LOAD #p"/Lisp/src/cm.lisp" #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp" :ERROR NIL) 9: (LOAD "/Lisp/src/cm.lisp" :VERBOSE NIL :PRINT ...) 10: (INTERACTIVE-EVAL (LOAD "/Lisp/src/cm.lisp")) 11: (COMMON-LISP::%TOP-LEVEL) 12: (COMMON-LISP::RESTART-LISP) 0] From bil at ccrma.Stanford.EDU Fri Nov 7 04:02:10 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 07 Nov 2003 04:02:10 -0800 Subject: [CM] Jack audio support in Snd/sndlib from Kjetil S. Matheussen Message-ID: <3FAB89C2.3000100@ccrma> Kjetil S. Matheussen has contributed Jack audio support to Snd/sndlib. Use the --with-jack configure switch to enable it. (This is in snd-7.tar.gz at ccrma-ftp or the CVS version of Snd). From bil at ccrma.Stanford.EDU Fri Nov 7 04:05:03 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 07 Nov 2003 04:05:03 -0800 Subject: [CM] ACL/win trick? In-Reply-To: <3FA99948.80004@nyc.rr.com> References: <3FA99948.80004@nyc.rr.com> Message-ID: <3FAB8A6F.7020706@ccrma> Thanks for the info -- I'll include it in the CLM tarball, probably in the "windows notes" section of README.clm. From bil at ccrma.Stanford.EDU Fri Nov 7 04:11:30 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 07 Nov 2003 04:11:30 -0800 Subject: [CM] multiple sound cards In-Reply-To: <20031105145907.GA28285@vja.demon.nl> References: <20031104214237.GA26389@vja.demon.nl> <3FA9039F.2050002@ccrma> <20031105145907.GA28285@vja.demon.nl> Message-ID: <3FAB8BF2.1050504@ccrma> The /dev/dsp and /dev/mixer numbers have no direct relation to the sound cards in OSS, and there's no simple way to tell which ones are related. The data format complaint you got probably came about because you set the output device via "(sl-dac name 1)" -- the third arg is the sndlib-style device (i.e. mus-audio-line-out or whatever). I don't know why you're not getting sound, but if you have a program that works, you can use it through *clm-player*. From finnendahl at folkwang-hochschule.de Fri Nov 7 04:27:20 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Fri, 7 Nov 2003 13:27:20 +0100 Subject: [CM] cm.scm Message-ID: <20031107122720.GA2339@finnendahl.de> Hi Rick, there are two weird lines in current cvs of cm.scm: line 71: <<<<<<< cm.scm line 87: >>>>>>> 1.3 -- Orm From rm at fabula.de Fri Nov 7 04:56:28 2003 From: rm at fabula.de (rm at fabula.de) Date: Fri, 7 Nov 2003 13:56:28 +0100 Subject: [CM] cm.scm In-Reply-To: <20031107122720.GA2339@finnendahl.de> References: <20031107122720.GA2339@finnendahl.de> Message-ID: <20031107125628.GF14870@www> On Fri, Nov 07, 2003 at 01:27:20PM +0100, Orm Finnendahl wrote: > Hi Rick, > > there are two weird lines in current cvs of cm.scm: > > line 71: > > <<<<<<< cm.scm > > line 87: > > >>>>>>> 1.3 Looks like some revision control (CVS) conflict to me .... RalfD > -- > Orm > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Fri Nov 7 05:22:38 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 7 Nov 2003 07:22:38 -0600 Subject: [CM] cm.scm In-Reply-To: <20031107122720.GA2339@finnendahl.de> Message-ID: <7521C591-1125-11D8-8782-000A95674CE4@uiuc.edu> Yes, i think messed up cvs somehow. what confuses me is that MY cm.scm does not contain the problem yet 'cvs diff' says that im in sync. and ive been using 'cvs diff' to see if/when im out of sync with the repository and assuming that if there are no diffs then im in sync. maybe thats not what diff is for... (?) Im reading a doc now (thanks tobias) to try to figure out what i did wrong. On Friday, Nov 7, 2003, at 06:27 America/Chicago, Orm Finnendahl wrote: > Hi Rick, > > there are two weird lines in current cvs of cm.scm: > > line 71: > > <<<<<<< cm.scm > > line 87: > >>>>>>>> 1.3 > > -- > Orm > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From marco at ccrma.Stanford.EDU Fri Nov 7 05:24:38 2003 From: marco at ccrma.Stanford.EDU (marco at ccrma.Stanford.EDU) Date: Fri, 7 Nov 2003 09:24:38 -0400 Subject: [CM] cm install fails with cmucl In-Reply-To: <20031107110806.GA1073@finnendahl.de> References: <20031107110806.GA1073@finnendahl.de> Message-ID: <20031107132438.GA1875@trevisani.net> Hi, the cm version in the ccrma ftp repository works fine with cmucl/GNU-Linux Debian(unstable/sid). I should have packaged already (both cmn and cm) but i'm right now too busy in building walls in my new appartment....one more month... ciao, marco 07/11/2003 alle 12:08:06, +0100, Orm Finnendahl [AKA finnendahl] ha scritto/escribi?/wrote: > Hi, > > trying to migrate common music from clisp to cmucl, loading cm.lisp > dies with: > > "File-error in function TRUENAME: The file "/Lisp/src/iter.lisp" does > not exist." > > appended is the complete output and the backtrace. "/Lisp" is > symlinked to the actual cm directory which contains the latest sources > from CVS. > -- ************************************************************************ * marco trevisani * * http://marco.trevisani.net marco at trevisani.net * * Neither MS-Word nor MS-PowerPoint attachments please: * * See http://www.fsf.org/philosophy/no-word-attachments.html * * Gpg Fingerprint = A9CD 12D6 B658 A545 9BD1 77E9 47AD 8753 8110 7070 * ************************************************************************ From rm at fabula.de Fri Nov 7 05:34:44 2003 From: rm at fabula.de (rm at fabula.de) Date: Fri, 7 Nov 2003 14:34:44 +0100 Subject: [CM] cm.scm In-Reply-To: <7521C591-1125-11D8-8782-000A95674CE4@uiuc.edu> References: <20031107122720.GA2339@finnendahl.de> <7521C591-1125-11D8-8782-000A95674CE4@uiuc.edu> Message-ID: <20031107133444.GG14870@www> On Fri, Nov 07, 2003 at 07:22:38AM -0600, Rick Taube wrote: > Yes, i think messed up cvs somehow. what confuses me is that MY cm.scm > does not contain the problem yet 'cvs diff' says that im in sync. and > ive been using 'cvs diff' to see if/when im out of sync with the > repository and assuming that if there are no diffs then im in sync. > maybe thats not what diff is for... (?) > > Im reading a doc now (thanks tobias) to try to figure out what i did > wrong. Hmm, looking at it again: it's not clear whether _you_ did something wrong here. It's not clear to me rom Orm's post whether he downloaded the software or did a CVS checkout. If the later is the case it's most likely that _he_ did some local changes that conflict with the latest checkouts (probably both he and you changed things in the same area of the file). Orm should have gotten some warnings during checkout iff that's the case. RalfD > On Friday, Nov 7, 2003, at 06:27 America/Chicago, Orm Finnendahl wrote: > > >Hi Rick, > > > >there are two weird lines in current cvs of cm.scm: > > > >line 71: > > > ><<<<<<< cm.scm > > > >line 87: > > > >>>>>>>>1.3 > > > >-- > >Orm > > > >_______________________________________________ > >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 finnendahl at folkwang-hochschule.de Fri Nov 7 06:05:40 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Fri, 7 Nov 2003 15:05:40 +0100 Subject: [CM] cm.scm In-Reply-To: <20031107133444.GG14870@www> References: <20031107122720.GA2339@finnendahl.de> <7521C591-1125-11D8-8782-000A95674CE4@uiuc.edu> <20031107133444.GG14870@www> Message-ID: <20031107140540.GB2339@finnendahl.de> Am 07. November 2003, 14:34 Uhr (+0100) schrieb rm at fabula.de: > > Hmm, looking at it again: it's not clear whether _you_ did something > wrong here. It's not clear to me rom Orm's post whether he downloaded > the software or did a CVS checkout. If the later is the case it's most > likely that _he_ did some local changes that conflict with the latest > checkouts (probably both he and you changed things in the same area > of the file). Orm should have gotten some warnings during checkout iff > that's the case. that was the problem. I had edited the prior file some time ago. After deleting cm.scm and rechecking out everything was fine. Sorry... -- Orm From bobcoyne at worldnet.att.net Fri Nov 7 06:09:55 2003 From: bobcoyne at worldnet.att.net (Bob Coyne) Date: Fri, 07 Nov 2003 09:09:55 -0500 Subject: [CM] cm install fails with cmucl References: <20031107110806.GA1073@finnendahl.de> Message-ID: <3FABA7B3.5B05204@worldnet.att.net> What do you get when you do (directory "/Lisp/src/"). I bet it gives an error too. I've noticed that when emacs has an modified, unsaved buffer, it does some symbolic linking thing with the original, resulting in this sort of error from cmucl. Seems like the same sort of problem you're having. Orm Finnendahl wrote: > Hi, > > trying to migrate common music from clisp to cmucl, loading cm.lisp > dies with: > > "File-error in function TRUENAME: The file "/Lisp/src/iter.lisp" does > not exist." > > appended is the complete output and the backtrace. "/Lisp" is > symlinked to the actual cm directory which contains the latest sources > from CVS. > > -- > Orm > > ---------------------------------------------------------------------- > * (load "/Lisp/src/cm.lisp") > ; Loading #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp". > > ; Loading "/Lisp/bin/pkg.x86f". > ; Loading "/Lisp/bin/cmu.x86f". > ; Loading "/Lisp/bin/clos.x86f". > ; Compiling "/Lisp/src/iter.lisp". > > File-error in function TRUENAME: The file "/Lisp/src/iter.lisp" does > not exist. > > Restarts: > 0: [CONTINUE] Return NIL from load of "/Lisp/src/cm.lisp". > 1: [ABORT ] Return to Top-Level. > > Debug (type H for help) > > (TRUENAME #p"/Lisp/src/iter.lisp") > Source: (ERROR 'SIMPLE-FILE-ERROR :PATHNAME PATHNAME :FORMAT-CONTROL ...) > > 0] Backtrace > 0: (TRUENAME #p"/Lisp/src/iter.lisp") > 1: (C::TRY-WITH-TYPE #p"/Lisp/src/iter.lisp" "lisp" T) > 2: (C::VERIFY-SOURCE-FILES "/Lisp/src/iter.lisp") > 3: (COMPILE-FILE "/Lisp/src/iter.lisp" > :OUTPUT-FILE > "/Lisp/bin/iter.x86f" > :ERROR-FILE > ...) > 4: (NIL "iter") > 5: ("Top-Level Form")[:TOP-LEVEL] > 6: (COMMON-LISP::SLOLOAD > #) > 7: (COMMON-LISP::INTERNAL-LOAD #p"/Lisp/src/cm.lisp" > #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp" > :ERROR > :SOURCE) > 8: (COMMON-LISP::INTERNAL-LOAD #p"/Lisp/src/cm.lisp" > #p"/usr/local/lisp/cm-cvs/cm/src/cm.lisp" > :ERROR > NIL) > 9: (LOAD "/Lisp/src/cm.lisp" :VERBOSE NIL :PRINT ...) > 10: (INTERACTIVE-EVAL (LOAD "/Lisp/src/cm.lisp")) > 11: (COMMON-LISP::%TOP-LEVEL) > 12: (COMMON-LISP::RESTART-LISP) > > 0] > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Fri Nov 7 06:33:55 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 7 Nov 2003 08:33:55 -0600 Subject: [CM] cm install fails with cmucl In-Reply-To: <3FABA7B3.5B05204@worldnet.att.net> Message-ID: <6A5499B9-112F-11D8-8782-000A95674CE4@uiuc.edu> If you got the sources from CVS, did you remember to generate the CLTL sources before trying to build? CVS holds scheme code (as much as possible) So to build from CVS for any CLTL you need to do this first: > (load "/lisp/cm-2.4.0/src/stocl") > (gencm) see Step 4 under: http://commonmusic.sourceforge.net/doc/install.html#install_cvs On Friday, Nov 7, 2003, at 08:09 America/Chicago, Bob Coyne wrote: >> >> appended is the complete output and the backtrace. "/Lisp" is >> symlinked to the actual cm directory which contains the latest sources >> from CVS. >> From finnendahl at folkwang-hochschule.de Fri Nov 7 07:04:41 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Fri, 7 Nov 2003 16:04:41 +0100 Subject: [CM] cm install fails with cmucl In-Reply-To: <6A5499B9-112F-11D8-8782-000A95674CE4@uiuc.edu> References: <3FABA7B3.5B05204@worldnet.att.net> <6A5499B9-112F-11D8-8782-000A95674CE4@uiuc.edu> Message-ID: <20031107150440.GD2339@finnendahl.de> Am 07. November 2003, 08:33 Uhr (-0600) schrieb Rick Taube: > If you got the sources from CVS, did you remember to generate the CLTL > sources before trying to build? CVS holds scheme code (as much as > possible) So to build from CVS for any CLTL you need to do this first: > > > (load "/lisp/cm-2.4.0/src/stocl") > > (gencm) > > see Step 4 under: > http://commonmusic.sourceforge.net/doc/install.html#install_cvs That was the problem, sorry again. I wasn't even aware you had to do that in spite our previous discussions and the install docs. This clearly isn't my day. Regarding the build: Loading cm.lisp now starts up fine but dies here after lots of output (hope I didn't mess up again): ; Compiling DEFPARAMETER *PROCESS-OPERATORS*: ; Compiling DEFPARAMETER *PROCESS-OPERATORS*: ; Byte Compiling Top-Level Form: ; Converted PROCESS. ; Compiling DEFMACRO PROCESS: ; Converted DEFPROCESS. ; Compiling DEFMACRO DEFPROCESS: ; Byte Compiling Top-Level Form: ; Compiling "/Lisp/src/objects.lisp". ; Loading "/Lisp/bin/objects.x86f". Error in C::BYTE-FDEFN-FUNCTION-OR-LOSE-XOP: the function PARSE-FOR is undefined. Restarts: 0: [CONTINUE] Return NIL from load of "/Lisp/bin/objects.x86f". 1: Return NIL from load of "/Lisp/src/cm.lisp". 2: [ABORT ] Return to Top-Level. Debug (type H for help) (C::BYTE-FDEFN-FUNCTION-OR-LOSE-XOP # 7 8 74) Source: ; File: target:code/byte-interp.lisp (ERROR 'UNDEFINED-FUNCTION :NAME (FDEFN-NAME FDEFN)) 0] From taube at uiuc.edu Fri Nov 7 07:21:04 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 7 Nov 2003 09:21:04 -0600 Subject: [CM] cm install fails with cmucl In-Reply-To: <20031107150440.GD2339@finnendahl.de> Message-ID: <00A2AE8F-1136-11D8-AC62-000A95674CE4@uiuc.edu> ok this may be a bug. its been awhile since i did (gencm) in cmucl, so ill crank it up and take a look. meanwhile you can build from the tarball at ccrma, which already has the .lisp sources in it. i tested it today in cmucl 18e and cm builds with clm-2 just fine. On Friday, Nov 7, 2003, at 09:04 America/Chicago, Orm Finnendahl wrote: > > Am 07. November 2003, 08:33 Uhr (-0600) schrieb Rick Taube: >> If you got the sources from CVS, did you remember to generate the CLTL >> sources before trying to build? CVS holds scheme code (as much as >> possible) So to build from CVS for any CLTL you need to do this >> first: >> >>> (load "/lisp/cm-2.4.0/src/stocl") >>> (gencm) >> >> see Step 4 under: >> http://commonmusic.sourceforge.net/doc/install.html#install_cvs > > That was the problem, sorry again. I wasn't even aware you had to do > that in spite our previous discussions and the install docs. This > clearly isn't my day. > > Regarding the build: Loading cm.lisp now starts up fine but dies here > after lots of output (hope I didn't mess up again): > > > ; Compiling DEFPARAMETER *PROCESS-OPERATORS*: > ; Compiling DEFPARAMETER *PROCESS-OPERATORS*: > ; Byte Compiling Top-Level Form: > ; Converted PROCESS. > ; Compiling DEFMACRO PROCESS: > ; Converted DEFPROCESS. > ; Compiling DEFMACRO DEFPROCESS: > ; Byte Compiling Top-Level Form: > ; Compiling "/Lisp/src/objects.lisp". > ; Loading "/Lisp/bin/objects.x86f". > > Error in C::BYTE-FDEFN-FUNCTION-OR-LOSE-XOP: the function PARSE-FOR is > undefined. > > Restarts: > 0: [CONTINUE] Return NIL from load of "/Lisp/bin/objects.x86f". > 1: Return NIL from load of "/Lisp/src/cm.lisp". > 2: [ABORT ] Return to Top-Level. > > Debug (type H for help) > > (C::BYTE-FDEFN-FUNCTION-OR-LOSE-XOP # {4875505F}> > 7 > 8 > 74) > Source: > ; File: target:code/byte-interp.lisp > (ERROR 'UNDEFINED-FUNCTION :NAME (FDEFN-NAME FDEFN)) > 0] From taube at uiuc.edu Fri Nov 7 07:35:20 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 7 Nov 2003 09:35:20 -0600 Subject: [CM] cm install fails with cmucl In-Reply-To: <20031107150440.GD2339@finnendahl.de> Message-ID: Orm -- the (gencm) works fine for me in CMUCL 18e/Linux and I was then also able to build the system from the generated sources, again with clm-2. Looking back at your email, I _think_ what may have happend is that it BROKE when you compied the first time -- perhaps the file it broke on nevertheless compiled a bad fasl. I would delete everything in your bin directory and try loading cm.lisp again. Or better yet...go drink a few liters of good german beer! From herbstmondwind at web.de Sat Nov 8 04:45:53 2003 From: herbstmondwind at web.de (daniel mayer) Date: Sat, 8 Nov 2003 13:45:53 +0100 Subject: [CM] OSX-emacs/xemacs Message-ID: <200311081245.hA8CjqQ27316@mailgate5.cinetic.de> An HTML attachment was scrubbed... URL: From mint at franklinmint.fm Fri Nov 7 16:03:16 2003 From: mint at franklinmint.fm (Robert Sayre) Date: Fri, 07 Nov 2003 19:03:16 -0500 Subject: [CM] OSX - OpenMCL .14, build from CVS w/ CLM Message-ID: It *almost* builds, with a little change to openmcl.lisp, since OpenMCL .14 seems to have CLASS-DIRECT-SLOTS (am I mistaken?): Welcome to OpenMCL Version (Alpha: Darwin) 0.14-031018 ? (find-symbol "CLASS-DIRECT-SLOTS" "CCL") CLASS-DIRECT-SLOTS :EXTERNAL Line 58-59 of cm/src/openmcl.lisp currently reads: (defun class-direct-slots (class) (ccl:class-direct-instance-slots class)) could be changed to this: (defun class-direct-slots (class) (ccl:class-direct-slots class)) or this: (defun class-direct-slots (class) (ccl::class-direct-instance-slots class)) Not sure which is better. However, the build fails later on, as it seems to be missing the file cm/src/iter.lisp: ? (load "/Users/myuser/music/cm/src/cm.lisp") ; Loading "/Users/myuser/music/cm/bin/pkg.dfsl". ; Compiling "/Users/myuser/music/cm/src/openmcl.lisp". ; Loading "/Users/myuser/music/cm/bin/openmcl.dfsl". ; Compiling "/Users/myuser/music/cm/src/clos.lisp". ; Loading "/Users/myuser/music/cm/bin/clos.dfsl". ; Compiling "/Users/myuser/music/cm/src/iter.lisp". > Error in process listener(1): File #P"/Users/myuser/music/cm/src/iter.lisp" not found > While executing: CCL::FCOMP-FIND-FILE iter.lisp does not appear to be in CVS. Am I missing something? From martin at 1103.org Sat Nov 8 04:40:10 2003 From: martin at 1103.org (Martin Elster) Date: Sat, 08 Nov 2003 10:40:10 -0200 Subject: [CM] compiling violin on clm-2 RH9 acl Message-ID: <1068295209.2405.11.camel@localhost.localdomain> Greetings all, I am trying to get clm-2 up and running, and I'm having some problems with the v.ins example with Allegro CL 6.2 on Redhat 9. First I load the all.lisp, and it compiles and loads fine. When I try to do (compile-file "v.ins") I get a lot of errors while compiling the C file. "/home/melster/data/lisp/code/music/clm-2/clm_lnxacl_FM_VIOLIN.c" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_FM_VIOLIN.c:10:3: "#" is not a valid filename and then lots of errors about how "macro names must be identifiers", and then lots of syntax errors like this: "/home/melster/data/lisp/code/music/clm-2/clm_lnxacl_FM_VIOLIN.c:236: invalid lvalue in assignment" On CMUCL the error occurs earlier: USER> (load "all.lisp") ; Loading #p"/home/melster/data/lisp/code/music/clm-2/all.lisp". ;; Loading #p"/home/melster/data/lisp/code/music/clm-2/clm-package.x86f". ;; Loading #p"/home/melster/data/lisp/code/music/clm-2/initmus.x86f". ;;; Running /usr/bin/ld... Error in function SYSTEM::LOAD-OBJECT-FILE: Can't open object "/tmp/2422AG1567": "/home/melster/data/lisp/code/music/clm-2/libclm.so: undefined symbol: lisp_call_address" I'm running GCC 3.2.2. Could this be the problem? Is there a version of GCC that might work better? I can post the whole error output if necessary, but it's a couple of pages long. Any tips appreciated. Martin From taube at uiuc.edu Sun Nov 9 05:17:04 2003 From: taube at uiuc.edu (Rick Taube) Date: Sun, 9 Nov 2003 07:17:04 -0600 Subject: [CM] OSX - OpenMCL .14, build from CVS w/ CLM In-Reply-To: Message-ID: <03369EA9-12B7-11D8-9FC2-000A95674CE4@uiuc.edu> > > iter.lisp does not appear to be in CVS. Am I missing something? > if you install from cvs then you need to generate the lisp sources. see step 4 under: http://commonmusic.sf.net/doc/install.html#install_cvs I think ill have to add an explicit check for this in the make script, which i am redesigning anyway to make it a bit easier for people to use. i havent had a chance to build cm in the 0.14 openmcl, once you get it compiled please send me your diff and ill encorporate those changes. From mint at franklinmint.fm Sun Nov 9 10:21:03 2003 From: mint at franklinmint.fm (Robert Sayre) Date: Sun, 09 Nov 2003 13:21:03 -0500 Subject: [CM] OSX - OpenMCL .14, build from CVS w/ CLM In-Reply-To: <03369EA9-12B7-11D8-9FC2-000A95674CE4@uiuc.edu> Message-ID: Ah, I found the other emails about missing iter.lisp after I sent my first email. Sorry for that. Anyway, OpenMCL .14 has class-slots and class-direct-slots, so I changed src/openmcl.lisp accordingly, but now I've run into problems that aren't so simple. I think I'm stuck for now. ? (load "/Users/myuser/music/cm/src/cm.lisp") ; Loading "/Users/myuser/music/cm/bin/pkg.dfsl". ; Loading "/Users/myuser/music/cm/bin/openmcl.dfsl". ... ; Compiling "/Users/myuser/music/cm/src/sco.lisp". ; Loading "/Users/myuser/music/cm/bin/sco.dfsl". > Error in process listener(1): > The class # was specified as: a > super-class of the class #; > but the meta-classes # and > # are incompatible. > While executing: # On 11/9/03 8:17 AM, "Rick Taube" wrote: > > if you install from cvs then you need to generate the lisp sources. see > step 4 under: > > http://commonmusic.sf.net/doc/install.html#install_cvs > > I think ill have to add an explicit check for this in the make script, > which i am redesigning anyway to make it a bit easier for people to > use. i havent had a chance to build cm in the 0.14 openmcl, once you > get it compiled please send me your diff and ill encorporate those > changes. > > > From bil at ccrma.Stanford.EDU Mon Nov 10 04:31:56 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 10 Nov 2003 04:31:56 -0800 Subject: [CM] compiling violin on clm-2 RH9 acl Message-ID: <3FAF853C.8090400@ccrma> > First I load the all.lisp, and it compiles and loads fine. When I try to > do (compile-file "v.ins") I get a lot of errors while compiling the C > file. Please send me the errors, or preferably a backtrace (:zo) at the first. I didn't know ACL 6.2 was available in Linux. > Error in function SYSTEM::LOAD-OBJECT-FILE: > Can't open object "/tmp/2422AG1567": > "/home/melster/data/lisp/code/music/clm-2/libclm.so: undefined symbol: > lisp_call_address" If you change lisps, you need to start from a clean directory -- delete all the .o and .so files to force the C code to be recompiled. lisp_call_address is a part of ACL, so your current libclm.so was compiled in that environment. From martin at 1103.org Mon Nov 10 04:55:25 2003 From: martin at 1103.org (Martin Elster) Date: Mon, 10 Nov 2003 10:55:25 -0200 Subject: [CM] compiling violin on clm-2 RH9 acl In-Reply-To: <3FAF853C.8090400@ccrma> References: <3FAF853C.8090400@ccrma> Message-ID: <1068468924.2308.3.camel@localhost.localdomain> On Mon, 2003-11-10 at 10:31, Bill Schottstaedt wrote: > Please send me the errors, or preferably a backtrace (:zo) at the first. > I didn't know ACL 6.2 was available in Linux. I can't send you a backtrace because acl doesn't go into the debugger on this error. But the errors are at the bottom of this file. > If you change lisps, you need to start from a clean directory -- delete > all the .o and .so files to force the C code to be recompiled. > lisp_call_address is a part of ACL, so your current libclm.so was > compiled in that environment. That's good news. Now I have clm up and running on CMUCL. Thanks! Martin cl-user(8): (compile-file "v.ins") ;;; Compiling file v.ins ; Writing "/home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c" ; Compiling "/home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:10:3: "#" is not a valid filename /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:158:3: "#" is not a valid filename /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:159:3: "#" is not a valid filename /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:171:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:172:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:175:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:176:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:177:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:178:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:180:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:181:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:182:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:183:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:186:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:187:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:190:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:191:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:192:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:193:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:195:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:196:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:197:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:198:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:199:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:200:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:202:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:203:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:204:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:205:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:206:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:207:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:208:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:209:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:210:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:211:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:212:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:213:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:214:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:215:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:216:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:217:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:218:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:219:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:220:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:221:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:222:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:223:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:224:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:225:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:226:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:227:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:228:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:229:11: macro names must be identifiers /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c: In function `clm_lnxacl_fm_violin5': /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:236: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:236: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:236: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:236: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:236: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: `frobber' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: (Each undeclared identifier is reported only once /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: for each function it appears in.) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:242: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:244: `fm_noi' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:250: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:250: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:250: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:250: parse error before numeric constant /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:250: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:253: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:253: `CLM_1349' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:254: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:254: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:254: parse error before "_r" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:258: `frb_env' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:272: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:273: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:273: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:273: parse error before "_r" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:279: `frqf' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:292: `pervib' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:294: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:294: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:294: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:294: parse error before numeric constant /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:294: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:301: `ranvib' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:305: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:305: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:305: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:305: parse error before numeric constant /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:305: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:308: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:308: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:308: parse error before "n" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:308: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:308: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:314: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:314: `ind_noi' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:314: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:314: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:319: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:319: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:319: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:319: parse error before numeric constant /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:319: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:322: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:322: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:322: parse error before "n" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:322: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:322: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:331: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:331: `amp_noi' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:331: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:331: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:336: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:336: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:336: invalid lvalue in assignment /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:336: parse error before numeric constant /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:336: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:339: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:339: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:339: parse error before "n" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:339: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:339: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:348: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:348: `modulate' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:348: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:348: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:350: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:350: `easy_case' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:350: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:350: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:352: `indf1' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:365: `fmosc1' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:371: `coeffs' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:378: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:378: `CLM_1377' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:379: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:379: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:379: parse error before "_r" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:408: `indf2' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:425: `fmosc2' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:433: `indf3' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:450: `fmosc3' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:460: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:461: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:461: syntax error at '#' token /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:461: parse error before "_r" /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:467: `ampf' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:484: `carrier' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:495: `c_l_m__output_' undeclared (first use in this function) /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.c:506: `c_l_m__reverb_' undeclared (first use in this function) ; Creating shared object file "/home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.so" ld: cannot open /home/melster/data/lisp/code/music/clm-2/clm_lnxacl_fm_violin.o: No such file or directory ;;; Writing fasl file v.fasl Warning: No in-package form seen in /home/melster/data/lisp/code/music/clm-2/v.ins. (Allegro Presto will be ineffective when loading a file having no in-package form.) ;;; Fasl write complete #p"v.fasl" t nil cl-user(9): From dlphilp at bright.net Fri Nov 14 08:59:09 2003 From: dlphilp at bright.net (Dave Phillips) Date: Fri, 14 Nov 2003 11:59:09 -0500 Subject: [CM] [OT] Linux soundapps site updated Message-ID: <3FB509DD.4070108@bright.net> Greetings: Yes, it's true, I've finally updated the sites with a new edition for your weekend browsing pleasure. If you don't already know the drill, you can follow these links to the goods: http://linux-sound.org (USA) http://www.linuxsound.at (Europe) http://linuxsound.jp (Japan) Have fun ! Best regards, Dave Phillips From bigswift at ufl.edu Fri Nov 14 08:57:47 2003 From: bigswift at ufl.edu (shreeswifty) Date: Fri, 14 Nov 2003 11:57:47 -0500 (EST) Subject: [CM] Re: [Csnd] [OT] Linux soundapps site updated Message-ID: <122932401.1068829067195.JavaMail.osg@spnode33> YEAH DAVE!!!!!!! On Fri Nov 14 11:59:09 EST 2003, Dave Phillips wrote: > Greetings: > > Yes, it's true, I've finally updated the sites with a new > edition for your weekend browsing pleasure. If you don't already > know the drill, you can follow these links to the goods: > > http://linux-sound.org (USA) > > http://www.linuxsound.at (Europe) > > http://linuxsound.jp (Japan) > > Have fun ! > > Best regards, > > Dave Phillips > > > -- Send bugs reports to csound-bugs at cs.bath.ac.uk > (or to http://www.cs.bath.ac.uk/cgi-bin/csound ) > To unsubscribe, send email to csound-unsubscribe at lists.bath.ac.uk > > Patrick Pagano, B.S. Research And Development Assistant Digital Worlds Institute University Of Florida (352) 294-2070 From finnendahl at folkwang-hochschule.de Sun Nov 16 07:00:36 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Sun, 16 Nov 2003 16:00:36 +0100 Subject: [CM] tempo change in midi files Message-ID: <20031116150035.GA2319@finnendahl.de> Hi, I couldn't find any information about changing the tempo in midi files according to some tempo map. I have a list of note events with time and duration information in musical format (quarters, eigths etc.) and would like to apply different accelerandos and ritardandos to this data. Con someone shed some light on this issue or point me to references? I couldn't find any information in the dictionary etc... -- Orm From bobcoyne at worldnet.att.net Sun Nov 16 11:45:57 2003 From: bobcoyne at worldnet.att.net (Bob Coyne) Date: Sun, 16 Nov 2003 14:45:57 -0500 Subject: [CM] bow in strad.ins Message-ID: <3FB7D3F5.E5F7E9C@worldnet.att.net> I tried the bow instrument in strad.ins and it gets an divide by zero error in cmucl when I try playing it. Is this instrument supposed to work? I've found various others that also don't work and can send a list of them if it would be useful. Also, one other detail that should be covered in the documentation/instructions. To load an instrument in cmucl, you can't just say (load "") because it will load the ".x86f" binary file by default, and this doesn't work. It's necessary, instead, to do (load ".cmucl"). I think this should be mentioned explicitly. From js at aixtraware.de Sun Nov 16 13:01:04 2003 From: js at aixtraware.de (Joachim Schmitz) Date: Sun, 16 Nov 2003 22:01:04 +0100 Subject: [CM] new to snd and sound editing Message-ID: <3FB7E590.7000403@aixtraware.de> Hi, I am new to snd and don't know much about sound-editing, I just want to use it for postprocessing my recordings which I made from my tape and lp collection. Are there any howto's or examples available for example to filter out the cracks on the lp's or to "refresh" bad taperecordings ? any tips are welcome. -- Mit freundlichen Gr??en Joachim Schmitz ...................................................................... AixtraWare eK ..Joachim Schmitz ..www.aixtraware.de ..t: +49-2464-8851 H?sgenstr. 33a .....d-52457 Aldenhoven .............f: +49-2464-905163 From taube at uiuc.edu Sun Nov 16 15:10:36 2003 From: taube at uiuc.edu (Rick Taube) Date: Sun, 16 Nov 2003 17:10:36 -0600 Subject: [CM] tempo change in midi files In-Reply-To: <20031116150035.GA2319@finnendahl.de> Message-ID: <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> Well of course you can apply accel and deaccl to wait values that then affect the timing of the events in the file but i guess this is probably not what you want in ths case. Maybe the thing to do would be to have the process output explilcit tempo changes in addition to midi events, ie (process ... when (change-tempo? ...) output (new midimsg :time (now) msg (make-tempo-change ...) :channel 0 ...) output (new midi :time (now) ... channel 1 ...) wait beat) another soulutino would be to define a seq that holds just your tempo changes and then mix that into the file along with the output from your musical processes: (new seq :name 'tpo :subobjects (make-tempo-map ...)) (events (list #&tpo (my-piece)) "foo.midi") On Sunday, Nov 16, 2003, at 09:00 America/Chicago, Orm Finnendahl wrote: > Hi, > > I couldn't find any information about changing the tempo in midi files > according to some tempo map. I have a list of note events with time > and duration information in musical format (quarters, eigths etc.) and > would like to apply different accelerandos and ritardandos to this > data. > > Con someone shed some light on this issue or point me to references? I > couldn't find any information in the dictionary etc... > > -- > Orm > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From michael at klingbeil.com Sun Nov 16 22:54:34 2003 From: michael at klingbeil.com (Michael Klingbeil) Date: Mon, 17 Nov 2003 01:54:34 -0500 Subject: [CM] midishare In-Reply-To: References: Message-ID: Just tried to get CM running with midishare and had the exact same experience as Johannes describes. I installed both the user and developer packages. I think the midishare installer doesn't install this file. midishare.framework is nowhere to be found on my drive. Back to OS 9 where things actually work... >going on installing the whole env. i have problems with midishare now. >i've tried a bit to find the cause by myself, maybe ths can help to >clarify it: > >the test >(probe-file > "/System/Library/Frameworks/MidiShare.framework/MidiShare")) >returns nil >[midishare is installed in /Applications/ccl/darwin-headers] > >as usual: thanks in advance > >johannes >__ > >Johannes Quint >Rilkestr.55 >D-53225 Bonn >0228 468256 >johannes.quint at web.de >http://private.addcom.de/j.quint/index.htm From bil at ccrma.Stanford.EDU Mon Nov 17 03:58:34 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 17 Nov 2003 03:58:34 -0800 Subject: [CM] bow in strad.ins In-Reply-To: <3FB7D3F5.E5F7E9C@worldnet.att.net> References: <3FB7D3F5.E5F7E9C@worldnet.att.net> Message-ID: <3FB8B7EA.70601@ccrma> > you can't just say (load "") because it will load the ".x86f" > binary file by default, and this doesn't work. It's necessary, instead, > to do (load ".cmucl"). I think this should be mentioned explicitly. It is mentioned in README.clm (ca line 345) -- sbcl has a similar problem. > I tried the bow instrument in strad.ins and it gets > an divide by zero error in cmucl when I try playing it. > Is this instrument supposed to work? I've found various > others that also don't work and can send a list of them > if it would be useful. I'll check it out later today -- thanks for the bug report. Please send me any bugs or problems you encounter. From finnendahl at folkwang-hochschule.de Mon Nov 17 04:01:21 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Mon, 17 Nov 2003 13:01:21 +0100 Subject: [CM] tempo change in midi files In-Reply-To: <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> References: <20031116150035.GA2319@finnendahl.de> <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> Message-ID: <20031117120120.GF1441@finnendahl.de> Hi Rick, Am 16. November 2003, 17:10 Uhr (-0600) schrieb Rick Taube: > > another soulutino would be to define a seq that holds just your tempo > changes and then mix that into the file along with the output from your > musical processes: > > (new seq :name 'tpo :subobjects (make-tempo-map ...)) > > (events (list #&tpo (my-piece)) "foo.midi") Thanks for the hints. As you guessed, I was looking for a solution which writes tempo messages into the file itself (in order to get rid of my workaround doing it in the wait of the process loop). After fiddling around with the sources and reading some of the cm-2.3 docs, the mechanism becomes much clearer. Two questions: 1. Is there a straightforward way to keep time in musical time (from the beginning) rather than absolute time? Musical time should *not* be measured in beats, as the reference of the beats (denominator of time signature) might change. The format I formally (in cl) used were ratios expressing the musical time from the beginning in absolute values (like 1/4 or 127/8). The start of time signatures and tempo changes was expressed in the same format, put into separate sequences and mapped to the data prior to writing it to disk. As far as I understand, time in sequences of cm is expressed as absolute time and I fear that tempo-changes are taken into account in the events routine. 2. Taking your example above and applying that to time-signatures, I run into an error: ;; Definitions: (define time-sig-list '((4 4) (7 8) (4 4))) (define (make-time-sig-map timesiglist) (let ((curr 0)) (loop for x in timesiglist collect (new midimsg :time curr msg (apply #'make-time-signature x)) do (set! curr (+ curr (apply #'/ x)))))) (new seq :name 'tmsig :subobjects (make-time-sig-map time-sig-list)) ;; Tests: (list-subobjects (find-object 'tmsig)) ;; =>guile> ;;; Evaluate (list-subobjects (find-object 'tmsig)) ;; 0. #i(midimsg time 0 msg # data #f) ;; 1. #i(midimsg time 1 msg # data #f) ;; 2. #i(midimsg time 1.875 msg # data #f) ;; guile> (events (list #&tmsig) "/tmp/foo.midi") ;; =>guile> ;;; Evaluate (events (list #&tmsig) "/tmp/foo.midi") ;; : In procedure midi-write-message in expression (midi-write-message (midimsg-msg obj) mf ...): ;; : No applicable method for #< midi-write-message (1)> in call (midi-write-message # # 0 #f) ;; ABORT: (goops-error) ;; guile> -- Orm From bil at ccrma.Stanford.EDU Mon Nov 17 04:06:01 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 17 Nov 2003 04:06:01 -0800 Subject: [CM] new to snd and sound editing In-Reply-To: <3FB7E590.7000403@aixtraware.de> References: <3FB7E590.7000403@aixtraware.de> Message-ID: <3FB8B9A9.8030700@ccrma> > I am new to snd and don't know much about sound-editing, > I just want to use it for postprocessing my recordings which > I made from my tape and lp collection. Are there any howto's > or examples available for example to filter out the cracks > on the lp's or to "refresh" bad taperecordings ? This has been on me "todo list" for years! There are some filtering examples and click removing/smoothing functions scattered around, but nothing that really tries to clean up a recording. I think some cmdisters have mentioned gwc (Gnome Wave Cleaner), and a long time ago Matti Koskinen had some wavelet-based code (if I remember right). Someday I'll have time to look at this problem in detail -- it's not an easy problem, I think, if you want to keep the original's "brightness". (Current functions in Snd include anoi, remove-click, smooth-*, various low-pass filters, and fft-squelch -- see extsnd.hmtl and sndscm.html). From bil at ccrma.Stanford.EDU Mon Nov 17 04:15:45 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 17 Nov 2003 04:15:45 -0800 Subject: [CM] tempo change in midi files In-Reply-To: <20031117120120.GF1441@finnendahl.de> References: <20031116150035.GA2319@finnendahl.de> <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> <20031117120120.GF1441@finnendahl.de> Message-ID: <3FB8BBF1.4020301@ccrma> speaking of ratios and Guile, the Stanford legal office has signed off on giving my ratio implementation to FSF, so the next version of Guile should have ratio support (I'm hoping the CVS version will have it within a matter of days, but this business has already stretched out for several months). From finnendahl at folkwang-hochschule.de Mon Nov 17 04:35:04 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Mon, 17 Nov 2003 13:35:04 +0100 Subject: [CM] tempo change in midi files In-Reply-To: <3FB8BBF1.4020301@ccrma> References: <20031116150035.GA2319@finnendahl.de> <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> <20031117120120.GF1441@finnendahl.de> <3FB8BBF1.4020301@ccrma> Message-ID: <20031117123503.GG1441@finnendahl.de> Am 17. November 2003, 04:15 Uhr (-0800) schrieb Bill Schottstaedt: > speaking of ratios and Guile, the Stanford legal office has > signed off on giving my ratio implementation to FSF, so > the next version of Guile should have ratio support (I'm > hoping the CVS version will have it within a matter of > days, but this business has already stretched out for > several months). Great, that's good news! Thanks not only for the code, but also for initiative going through the legal stuff. About the syntax: Will the ratio implementation be supported directly "behind the scenes" as in common lisp, or is it necessary to specify them as lists like in chapter 2 of SICP? -- Orm From finnendahl at folkwang-hochschule.de Mon Nov 17 04:46:09 2003 From: finnendahl at folkwang-hochschule.de (Orm Finnendahl) Date: Mon, 17 Nov 2003 13:46:09 +0100 Subject: [CM] tempo change in midi files In-Reply-To: References: <20031117120120.GF1441@finnendahl.de> Message-ID: <20031117124608.GH1441@finnendahl.de> Hi Rick, Am 17. November 2003, 06:29 Uhr (-0600) schrieb Rick Taube: > > Tempo changes are NOT taken into account -- they are just data that > gets written to the file and have no effect on the scheduler. good. That makes things much easier. > i think at some point i should rewrite the midiroutines to return > messagses or vectors of messages rather than multiple values... Not necessarily. Me taking a closer look at the sources or an entry in the dictionary should do. Thanks again, Orm From taube at uiuc.edu Mon Nov 17 04:46:41 2003 From: taube at uiuc.edu (Rick Taube) Date: Mon, 17 Nov 2003 06:46:41 -0600 Subject: [CM] tempo change in midi files Message-ID: <17C73A6C-18FC-11D8-A5D5-000A95674CE4@uiuc.edu> > Two questions: > > 1. Is there a straightforward way to keep time in musical time (from > the beginning) rather than absolute time? Musical time should *not* > be measured in beats, as the reference of the beats (denominator of > time signature) might change. The format I formally (in cl) used > were ratios expressing the musical time from the beginning in Offhand I dont see why you cant use ratios to express time -- the scheduler doesnt really care what format "time" values are in, and since you can fiddle with :divisions and tempo changes in midi its not really seconds anyway > as absolute time and I fear that tempo-changes are taken into > account in the events routine. Tempo changes are NOT taken into account -- they are just data that gets written to the file and have no effect on the scheduler. > 2. Taking your example above and applying that to time-signatures, I > run into an error: the function make-time-signature returns TWO values so your loop will have to do somthing like (define (make-time-sig-map timesiglist) (let ((curr 0)) (loop with m and d for x in timesiglist do (multiple-value-setq (m d) (apply #'make-time-signature x)) collect (new midimsg :time curr :msg m :data d) ...) i think at some point i should rewrite the midiroutines to return messagses or vectors of messages rather than multiple values... From anders.vinjar at notam02.no Mon Nov 17 05:07:24 2003 From: anders.vinjar at notam02.no (Anders Vinjar) Date: 17 Nov 2003 14:07:24 +0100 Subject: [CM] tempo change in midi files In-Reply-To: <3FB8BBF1.4020301@ccrma> References: <20031116150035.GA2319@finnendahl.de> <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> <20031117120120.GF1441@finnendahl.de> <3FB8BBF1.4020301@ccrma> Message-ID: This is great news. Ill update guile here when its ready, and when i get some time, finish whats left of the guile-implementation of CMN. -anders >>> "BS" == Bill Schottstaedt writes: BS> speaking of ratios and Guile, the Stanford legal office BS> has signed off on giving my ratio implementation to FSF, BS> so the next version of Guile should have ratio support BS> (I'm hoping the CVS version will have it within a matter BS> of days, but this business has already stretched out for BS> several months). BS> _______________________________________________ Cmdist BS> mailing list Cmdist at ccrma.stanford.edu BS> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From bil at ccrma.Stanford.EDU Tue Nov 18 03:51:17 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Tue, 18 Nov 2003 03:51:17 -0800 Subject: [CM] bow in strad.ins In-Reply-To: <3FB7D3F5.E5F7E9C@worldnet.att.net> References: <3FB7D3F5.E5F7E9C@worldnet.att.net> Message-ID: <3FBA07B5.7030408@ccrma> > I tried the bow instrument in strad.ins and it gets > an divide by zero error in cmucl when I try playing it. This was an addressing bug in cmus.lisp, which I didn't catch because ACL handled the macroexpansion slightly differently from CMUCL, and my auto tests didn't include strad.ins. They do now... From bil at ccrma.Stanford.EDU Tue Nov 18 04:41:39 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Tue, 18 Nov 2003 04:41:39 -0800 Subject: [CM] tempo change in midi files In-Reply-To: <20031117123503.GG1441@finnendahl.de> References: <20031116150035.GA2319@finnendahl.de> <166750AD-188A-11D8-9947-000A95674CE4@uiuc.edu> <20031117120120.GF1441@finnendahl.de> <3FB8BBF1.4020301@ccrma> <20031117123503.GG1441@finnendahl.de> Message-ID: <3FBA1383.2050408@ccrma> > About the syntax: Will the > ratio implementation be supported directly "behind the scenes" as in > common lisp, or is it necessary to specify them as lists like in > chapter 2 of SICP? It will be supported directly -- 3/4 will be recognized as a special thing, not (as now) a synonym for 0.75. From bil at ccrma.Stanford.EDU Wed Nov 19 05:26:06 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 19 Nov 2003 05:26:06 -0800 Subject: [CM] guile and ratios Message-ID: <3FBB6F6E.4030103@ccrma> The CVS guile has the new ratio code; see guile-devel: http://mail.gnu.org/archive/html/guile-devel/2003-11/msg00094.html for the announcement. If you need help getting the CVS Guile to build, let me know -- on my machine I always have to fix one ifdef by hand (involving argz.h or something like that). Also, I actually haven't tried this version of Guile yet, so there may be incompatibilities with Snd. From bil at ccrma.Stanford.EDU Wed Nov 19 06:02:21 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 19 Nov 2003 06:02:21 -0800 Subject: [CM] guile and ratios In-Reply-To: <3FBB6F6E.4030103@ccrma> References: <3FBB6F6E.4030103@ccrma> Message-ID: <3FBB77ED.6020504@ccrma> I forgot to mention: the main change in terms of existing scheme code is that inexact->exact does not necessarily return an integer any more; you'll need to replace all such calls with (inexact->exact (round ...)). From johannes.quint at web.de Wed Nov 19 09:09:45 2003 From: johannes.quint at web.de (Johannes Quint) Date: Wed, 19 Nov 2003 18:09:45 +0100 Subject: [CM] midishare In-Reply-To: <229B019C-1AA3-11D8-ADA3-000A95674CE4@uiuc.edu> Message-ID: <2C7F6464-1AB3-11D8-BEBD-000393B906B6@web.de> On Mittwoch, November 19, 2003, at 04:14 Uhr, Rick Taube wrote: > The midishare I do have installed seems to work well, and I can > connect to external synths as well as to quicktime. hello rick, i've still the same problems with midishare as described sooner. the point is not midishare itself but the connection with cm. j. Johannes Quint Rilkestr.55 D-53225 Bonn 0228 468256 johannes.quint at web.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 481 bytes Desc: not available URL: From drkrause at mindspring.com Sat Nov 22 06:02:30 2003 From: drkrause at mindspring.com (Drew Krause) Date: Sat, 22 Nov 2003 09:02:30 -0500 Subject: [CM] cm midi->csound? Message-ID: <3FBF6C76.70102@mindspring.com> Just wondering, has anyone written a routine in CM that would convert midifiles to csound scores? Since CM has interface functionality for both filetypes, its implementation would probably be fairly straightforward .... Drew Krause From taube at uiuc.edu Sat Nov 22 06:50:58 2003 From: taube at uiuc.edu (Rick Taube) Date: Sat, 22 Nov 2003 08:50:58 -0600 Subject: [CM] cm midi->csound? In-Reply-To: <3FBF6C76.70102@mindspring.com> Message-ID: <48353009-1CFB-11D8-A93E-000A95674CE4@uiuc.edu> this should be working in the current system. You would use import-events to import your MIDI data into CM and then write the sequence(s) back out to a .sco file. the global variable 'midi-channel-names' (src/midi3.scm) is a vector that you can use to associate (up to) 16 csound instruments names ("i1" "i2" "i99" and so on) with midi channels. When a MIDI event is output to a .sco file AND there is an instrument name defined for the MIDI event's channel in midi-channel-names then that i name will get printed in the score followed by four parameters values: ixx start dur hz amp where ixx is the name assigned in midi-channel-names, start is its start time, dur is duration, hz is frequency in herz and amp is 0-1 you may be the first person to use this 'feature' -- if you find it is two restictive the code could be easilty modified to allow you to asscoate an arbitrary print function at each location in midi-channel-names such that your print function will be called with the midi evnt to print an arbitrary i... statement in the score. that way you could write out to any sort of csound instument regardless of what its parameters are. it would be very simple to add this, let me know. Saturday, Nov 22, 2003, at 08:02 America/Chicago, Drew Krause wrote: > Just wondering, has anyone written a routine in CM that would convert > midifiles to csound scores? Since CM has interface functionality for > both filetypes, its implementation would probably be fairly > straightforward .... > > Drew Krause > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From carl.boingie at rcn.com Sat Nov 22 14:49:24 2003 From: carl.boingie at rcn.com (Carl Edwards) Date: Sat, 22 Nov 2003 17:49:24 -0500 Subject: [CM] cm midi->csound? Message-ID: <002301c3b14b$5991b250$88e27ad1@laptop> > Rick said: >You would use import-events to import your MIDI data into > CM and then write the sequence(s) back out to a .sco file Hey, that's great!... if anyone creates an example would you mind posting it to the list? Carl Edwards From bil at ccrma.Stanford.EDU Mon Nov 24 03:09:13 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 24 Nov 2003 03:09:13 -0800 Subject: [CM] snd 7.0 Message-ID: <3FC1E6D9.3060604@ccrma> Snd 7.0 Major changes: added sndins and gfm to sndlib -- both written by Michael Scholz. sndins has faster versions of some of the instruments, and gfm is a Forth implementation of CLM! Kjetil S. Matheussen provided support for the Jack library and snd_conffile.scm, and found many bugs. To include Jack support, use the --with-jack switch to configure. The mix.scm track support was moved into Snd itself with many changes: New: track, tracks, track?, make-track, track-amp, track-tempo, track-dialog, track-position, track-frames, track-speed, track-amp-env, track-track, delete-track, delete-mix, track-color, lock-track, track-chans, copy-mix, copy-track, mix-dialog-mix, track-dialog-track, mix-inverted? a View:Tracks dialog. track-property and mix-click-info in mix.scm. optional track arg to mix-vct, mix-selection, mix-region, mix. Renamed: env-track -> track-amp-env unused-track and new-track -> make-track. track-length -> track-frames. mix-locked -> mix-locked? mix-dragged-hook -> mix-release-hook. mix-anchor -> mix-tag-position. mix-panel -> mix-dialog. Removed: notion of a selected mix (selected-mix, selected-mix-color, select-mix, select-mix-hook). mix-amp|speed|amp-env-changed-hooks and multichannel-mix-hook. 'snd' arg to make-track-sample-reader. the mix-as-list option from various functions. mix-sync (use mix-track). next-mix-sample and next-track-sample (use read-*) mix-frames is no longer settable. moved find-mix to mix.scm a bazillion other changes too boring to mention. Minor stuff: Mike Scholz and I made various additions to libxm (mainly the shape extension and several more struct field accessors). removed the length arg from spectrum in clm2xen. added snd-urls. set-root-window-background in snd-motif.scm. cursor-style and cursor-size can be set globally. added optional filename arg to save-marks and implemented it in Ruby. added recorder-file-hook to set or modify recorder output, file name, and recorder-out-type. peak-env.scm is smarter about peak filenames thanks to Kjetil S. Matheussen. In CLM, the help file creator no longer creates filenames with embedded spaces (thanks to Marco Trevisani). various ACL 6.2/Windows bugfixes thanks to Kenny Tilton. checked glib/gtk 2.3.0, but I haven't yet implemented all the changes in xg.c yet. I'll use the new file-chooser widget in Snd eventually. also checked Ruby 1.8.1 With much help from Michael Scholz, Oded Ben-Tal, Pat Pagano, Craig Sapp, Russell Aspinwall, Marco Trevisani, Kjetil S. Matheussen, Paul Kirk, Kenny Tilton, Jeremiah Benham. From johannes.quint at web.de Mon Nov 24 11:30:31 2003 From: johannes.quint at web.de (Johannes Quint) Date: Mon, 24 Nov 2003 20:30:31 +0100 Subject: [CM] is x a rhythm/a keynum? Message-ID: how can i test, if x is a rhythm (if x is a keynum)? i want to have something like: (defun rhythm-or-keynum (x) (cond ((rhythmp x) "i am a rhythm") ; but rhythmp/keynump doesn't exist ((keynump x) "i am a keynum") (t "no rhythm, no keynum"))) thanks for help j.q. __ Johannes Quint Rilkestr.55 D-53225 Bonn 0228 468256 johannes.quint at web.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 434 bytes Desc: not available URL: From taube at uiuc.edu Tue Nov 25 06:37:18 2003 From: taube at uiuc.edu (Rick Taube) Date: Tue, 25 Nov 2003 08:37:18 -0600 Subject: [CM] is x a rhythm/a keynum? In-Reply-To: Message-ID: you are correct, currently there are no predicates that test for rhythm or keynum. however, depending on how simple your rhythm/keynumber testing needs to be you may be able to use the undertlying functions for this. assuming you are using CLTL try: (defun rhythmp (x) (gethash x *rhythms*)) (defun keynump (x) (and (numberp x) (<= 0 x 127)) limitations; the rhythmp function will fail for things like w-s and the keynump function assumes the standard (midi) scale and doesnt allow note names. On Monday, Nov 24, 2003, at 13:30 America/Chicago, Johannes Quint wrote: > how can i test, if x is a rhythm (if x is a keynum)? > > i want to have something like: > > (defun rhythm-or-keynum (x) > (cond ((rhythmp x) "i am a rhythm") ; but rhythmp/keynump doesn't > exist > ((keynump x) "i am a keynum") > (t "no rhythm, no keynum"))) > > thanks for help > > j.q. > > > > __ > > Johannes Quint > Rilkestr.55 > D-53225 Bonn > 0228 468256 > johannes.quint at web.de From mjkoskin at koti.soon.fi Thu Nov 27 10:26:56 2003 From: mjkoskin at koti.soon.fi (Matti Koskinen) Date: Thu, 27 Nov 2003 20:26:56 +0200 Subject: [CM] cellular automata in cm Message-ID: <3FC641F0.3040909@koti.soon.fi> hi all been a long time since my last post. I vaguely remember that sometime in the past, there was a cellular automata (by T.Kunze?). in cm tarball. Can it still be found, or any other example of CA in CM? thanks -matti From pertid at chello.se Thu Nov 27 17:15:58 2003 From: pertid at chello.se (Per Bergqvist) Date: Fri, 28 Nov 2003 02:15:58 +0100 Subject: [CM] openmcl-darwin-midishare Message-ID: <6C52FD3C-2140-11D8-BFFA-000A9568EE84@chello.se> Hi list! I am trying to get a working copy of CM-2.4.0.dmg.gz with - openmcl- 0.13.7, MacOSX-Jaguar with Midshare-1.86 (for realtime-support), CMN and CLM. (Dec 2002 - Apple DevTools is installed, (not gcc 3.3 update)) Before getting to work, this being the first time experience , building a lisp-image from source, I feel the need for some guidence ! Intro Q:s Reading the CM-install.html, one should understand that you should use the source distribution of of openmcl, since this is the only distribution containing the "darwin-headers"-directory ? I have (I think), successfully installed the appropiate version of [jaguar-interfaces.tar.gz] and [openmcl-midishare.tar.gz] , these are visable within the "darwin-headers"-directory, of the source distribution of 0.13.7. Also, reading the openmcl-docs, it reads under "Building OpenMcl heap image" that - Cite: "...one needs a full Lisp image - as provided by the OpenMCL binary distributions -in order to compile the OpenMCl lisp sources and produce an equivalent Lisp image." Q: Does this mean one should move the "dppccl" and/or "dppccl.image" from the binary distr. to the equivalent source distr, for later compilation? Or should you first compile the files in "lisp-kernel" - "darwin" - then only use the "dppccl.image" from the binary distribution ??!! (thrashing the "dppccl" in the "ccl" directory that earlier compilation created, that is) Other Q:s What are the correct installation of MidiShare and MidiShareDev respectively for OSX ? By default the MidiShare.app gets installed within "Applications Folder" (including a link to ~/user), and MidiShareDev gets installed at root-level, if not alternative directory is chosen at installation. Are these the correct places fro these files to work together, or are they in any case dependent upon "relative placement" within file hierarchy ??!! Thanks a million , all you competent people out there !! What would we do withou You !! From bil at ccrma.Stanford.EDU Fri Nov 28 03:24:21 2003 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 28 Nov 2003 03:24:21 -0800 Subject: [CM] sbcl+clm Message-ID: <3FC73065.7070107@ccrma> I think CLM works now in SBCL (I tried version 0.8.5), in FFI mode (no-ffi mode seems to be flakey). You have to load "ins.sbcl" rather than "ins.fasl". From taube at uiuc.edu Fri Nov 28 05:31:27 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 28 Nov 2003 07:31:27 -0600 Subject: [CM] openmcl-darwin-midishare In-Reply-To: <6C52FD3C-2140-11D8-BFFA-000A9568EE84@chello.se> Message-ID: <2B409F88-21A7-11D8-8132-000A95674CE4@uiuc.edu> On Thursday, Nov 27, 2003, at 19:15 America/Chicago, Per Bergqvist wrote: > Hi list! > > I am trying to get a working copy of CM-2.4.0.dmg.gz > with - openmcl- 0.13.7, MacOSX-Jaguar > with Midshare-1.86 (for realtime-support), CMN and CLM. if you will be working with all these systems together you might find using the current CVS CM sources easier than that old tarball you have-- in preparation for the book's CD Ive totally redone CM's build process to make bundling these systems easier. THe biggest change is that you will not have to hardwire images with varsious groupings of CLM+CM+CMN+MIDISHARE at compile time - you can keep all these sysmtems totally seperate and then jujst load CLM CMN and Midishare fasls into your CM "dynmaically" when you actually want to use them and everything will work. I havent said anything about this to the list yet because im still testing it in all the various lisps but it seems to be working quite well. A few things will change over the next few days but its very close to being 100% complete. I have not updated the install.html page yet: to build from the cvs sources you just restore them to your macihine, boot lisp and do (load "/whatever/cm/src/cm.lisp") and the new build processs will generate .lisp files if it has to, compile, load and (optionally) save an image in one pass. then you can boot this image and load each clm, cmn and midishare when you actually want to work with them. > Before getting to work, this being the first time experience > , building a lisp-image from source, I feel the need for some > guidence ! > I installed the binary distribution of OpenMCL 0.13. I have head that building OpenMCL from its sources is a very involved processs so I would avoid it if at all possible. You certainly dont need to do that to get clm+cmn+cm+midishare. Sorry but I cannot remember how I got darwin-headers -- I may have simply untarred the openmcl source tarball inside the binary folder and gotten it that way or perhaps I created it by hand. > What are the correct installation of MidiShare and MidiShareDev > respectively for OSX ? By default the MidiShare.app gets installed > within "Applications Folder" (including a link to ~/user), and > MidiShareDev gets installed at root-level, if not alternative > directory is chosen at installation. Are these the correct places fro > these > files to work together, or are they in any case dependent upon > "relative placement" within file hierarchy ??!! From what I understand Grame is almost done with their OSX release of Midishare except for a bug they have with the latest Quicktime . Until they release their distribution for OSX, the directions I have on the install.html page are not correct. So I would hold off on midishare until Grame announces it. If you really dont want to wait then I can make my working midishare Frameworks available for you do download. From taube at uiuc.edu Fri Nov 28 05:37:18 2003 From: taube at uiuc.edu (Rick Taube) Date: Fri, 28 Nov 2003 07:37:18 -0600 Subject: [CM] cellular automata in cm In-Reply-To: <3FC641F0.3040909@koti.soon.fi> Message-ID: look for a file called automata.lisp in the examples directory an old distribution (like 1.4.1 ). this file contains an implemenation of cellular automata and some musical examples . most of the code in the file is legacy graphics code for MCL but the underlying cell code should be fairly easy to get going again. send me a working version if you get it going! On Thursday, Nov 27, 2003, at 12:26 America/Chicago, Matti Koskinen wrote: > hi all > > been a long time since my last post. > > I vaguely remember that sometime in the past, there was a cellular > automata (by T.Kunze?). in cm tarball. Can it still be found, or any > other example of CA in CM? > > thanks > > -matti > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From mint at franklinmint.fm Sat Nov 29 21:58:49 2003 From: mint at franklinmint.fm (Robert Sayre) Date: Sun, 30 Nov 2003 00:58:49 -0500 Subject: [CM] OSX - OpenMCL .14, build from CVS w/ CLM In-Reply-To: <20031129201807.O66985@clozure.com> Message-ID: I've gotten CM to build (and work!) on OpenMCL .14... but I did it incorrectly. Below, there is a response to my questions about OpenMCL's MOP from Gary Byers. I made a similar mistake (which Byers corrects) in FINALIZE-CLASS when I built CM.