From bil at ccrma.Stanford.EDU Thu Sep 15 05:06:28 2005 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Thu, 15 Sep 2005 05:06:28 -0700 Subject: [CM] threads in Snd Message-ID: <432963C4.9030407@ccrma> I added the --enable-threads configure switch to Snd; it currently only affects multichannel FIR filtering -- kinda neat if you have a multiprocessor machine! From dlphillips at woh.rr.com Thu Sep 15 06:02:39 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 15 Sep 2005 09:02:39 -0400 Subject: [CM] CM compile problem Message-ID: <432970EF.5030801@woh.rr.com> Greetings: Building yesterday's CVS source for Common Music fails here: ; Compiling "src/gui/eventio.lisp"; ; Error: (during macroexpansion) ; ; Error in function ALIEN::%PARSE-ALIEN-TYPE: Unknown alien type: GTK::PNUM ; ; ; Error: (during macroexpansion) ; ; Error in function ALIEN::%PARSE-ALIEN-TYPE: Unknown alien type: GTK::PNUM ; Loading "bin/cmucl_2004-11_linux-i686/eventio.x86f" Execution of a form compiled with errors: (ALIEN:DEF-CALLBACK COMPOSE_SWITCH_PAGE (C-CALL:VOID (NOTEBOOK (* T)) (PAGE (* T)) (:INT GTK::PNUM) (DATA (* T))) NOTEBOOK PAGE PNUM DATA (IF (< -1 PNUM (LENGTH *CMIO-SOURCE-PAGES*)) (CMIO-NOTEBOOK-SWITCH-PAGE (WIDGET->OBJECT DATA) :COMPOSE (ELT *CMIO-SOURCE-PAGES* PNUM)))) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #P"/home/dlphilp/cm/bin/cmucl_2004-11_linux-i686/eventio.x86f". 1: Return NIL from load of "/home/dlphilp/cm/bin/../src/cm.lisp". 2: [ABORT ] Skip remaining initializations. Debug (type H for help) (C::DO-CALL # 83 84 96 ...) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/byte-interp.lisp. 0] I'm no good at debugging Lisp. Any suggestions ? Btw: CMUCL 2004-11 from the Planet CCRMA repository. Best, dp From taube at uiuc.edu Thu Sep 15 09:03:48 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 15 Sep 2005 11:03:48 -0500 Subject: [CM] CM compile problem In-Reply-To: <432970EF.5030801@woh.rr.com> References: <432970EF.5030801@woh.rr.com> Message-ID: <63897b1a37946044d75f2f8d4f9beef8@uiuc.edu> Sorry! Im in the middle of updating the CMIO window to handle the new systems: Fomus, Portmidi, realtime OSC, Supercollider. (I think todd plans to send a note around when the realtime OSC/SC support has been tested ) ill try to patch eventio.lisp so it loads in cmucl but that window wont be working for about a week or so... > Greetings: > > Building yesterday's CVS source for Common Music fails here: > > ; Compiling "src/gui/eventio.lisp"; > ; Error: (during macroexpansion) > ; > ; Error in function ALIEN::%PARSE-ALIEN-TYPE: Unknown alien type: > GTK::PNUM > ; ; > ; Error: (during macroexpansion) > ; > ; Error in function ALIEN::%PARSE-ALIEN-TYPE: Unknown alien type: > GTK::PNUM > ; Loading "bin/cmucl_2004-11_linux-i686/eventio.x86f" > Execution of a form compiled with errors: > (ALIEN:DEF-CALLBACK COMPOSE_SWITCH_PAGE > (C-CALL:VOID (NOTEBOOK (* T)) (PAGE (* T)) > (:INT GTK::PNUM) (DATA (* T))) > NOTEBOOK > PAGE > PNUM > DATA > (IF (< -1 PNUM (LENGTH *CMIO-SOURCE-PAGES*)) > (CMIO-NOTEBOOK-SWITCH-PAGE (WIDGET->OBJECT > DATA) > :COMPOSE (ELT > > *CMIO-SOURCE-PAGES* > PNUM)))) > [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] > > Restarts: > 0: [CONTINUE] Return NIL from load of > #P"/home/dlphilp/cm/bin/cmucl_2004-11_linux-i686/eventio.x86f". > 1: Return NIL from load of > "/home/dlphilp/cm/bin/../src/cm.lisp". > 2: [ABORT ] Skip remaining initializations. > > Debug (type H for help) > > (C::DO-CALL # 83 84 96 ...) > Source: Error finding source: > Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no > longer exists: > target:code/byte-interp.lisp. > 0] > > > I'm no good at debugging Lisp. Any suggestions ? > > Btw: CMUCL 2004-11 from the Planet CCRMA repository. > > Best, > > dp > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From dlphillips at woh.rr.com Thu Sep 15 10:11:36 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Thu, 15 Sep 2005 13:11:36 -0400 Subject: [CM] CM compile problem In-Reply-To: <63897b1a37946044d75f2f8d4f9beef8@uiuc.edu> References: <432970EF.5030801@woh.rr.com> <63897b1a37946044d75f2f8d4f9beef8@uiuc.edu> Message-ID: <4329AB48.4030702@woh.rr.com> Rick Taube wrote: > Sorry! Im in the middle of updating the CMIO window to handle the new > systems: Fomus, Portmidi, realtime OSC, Supercollider. (I think todd > plans to send a note around when the realtime OSC/SC support has been > tested ) > ill try to patch eventio.lisp so it loads in cmucl but that window > wont be working for about a week or so... Cool, thanks for the note. Is it working on any other implementation ? Best, dp From michael at klingbeil.com Sat Sep 17 14:26:01 2005 From: michael at klingbeil.com (Michael Klingbeil) Date: Sat, 17 Sep 2005 17:26:01 -0400 Subject: [CM] SPEAR - new sinusoidal modeling app Message-ID: Dear list, I just wanted to let you know about some new software that may be of interest. SPEAR (Sinusoidal Partial Editing Analysis and Resynthesis) is an application that implements sinusoidal analysis (MQ/PARSHL style) and a full-featured GUI. It supports flexible selection and immediate manipulation of analysis data, cut and paste, and unlimited undo/redo. Hundreds of simultaneous partials can be synthesized in real-time and documents may contain thousands of individual partials dispersed in time. It also supports a variety of standard file formats for the import and export of analysis data. If you are already working with other analysis/synthesis systems such as ATS, Loris or SNDAN, you can import your analysis data into SPEAR for editing. The native file format is SDIF 1TRC, but you can also export your data into text files. Rick Taube has generously added some functions to CM (currently in CVS -- see spectral.scm) for importing these text files. Native SDIF support for CM is planned for the future. More information and downloads at: http://www.klingbeil.com/spear Currently it is built for MacOS X, MacOS 9 and Windows (probably 2000 or later). If you find it useful, please spread the word, and do let me know if you have suggestions or encounter bugs. Best regards, Michael Klingbeil From taube at uiuc.edu Thu Sep 22 03:53:48 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 22 Sep 2005 05:53:48 -0500 Subject: [CM] Re: reading midi data into cm In-Reply-To: <000001c5bf43$a0280ae0$0300a8c0@home7vdrzzxq9o> References: <000001c5bf43$a0280ae0$0300a8c0@home7vdrzzxq9o> Message-ID: <1880d7f2cb672ff16f1978a78cfdd967@uiuc.edu> hello denis, there are several ways to do this -- perhaps the easiest is to just provide ":class 'midi" to MAP-OBJECTS so only midi objects will be mapped: (map-objects (lambda (x) (+ x 12)) x :slot! 'keynum :class 'midi) you could also skip importing the control changes by specifying ":channel-exclude 11" to import-events (i think 11 is the control-change opcode): (defparameter hk1 (import-events "hk.mid" :meta-exclude t :channel-exclude 11)) --rick On Sep 22, 2005, at 2:02 AM, Denis Fitzpatrick wrote: > I did the following: > ? > (defparameter hk1 (import-events "hk.mid" :meta-exclude true)) > ? > then tried: > ? > (map-objects (lambda (k) (+ k 12)) s2 :slot! 'keynum) > ? > but got: > ? > *** - SLOT-VALUE: The class # > has no > ????? slot named KEYNUM > The following restarts are available: > ABORT????????? :R1????? ABORT > ? > I do this: > (list-objects hk1 :end 5) > and get: > 0. #i(midi-control-change time 0.0 channel 0 controller 7 value 127) > 1. #i(midi-control-change time 0.0 channel 0 controller 10 value 64) > 2. #i(midi-control-change time 0.0 channel 1 controller 7 value 127) > 3. #i(midi-control-change time 0.0 channel 1 controller 10 value 64) > 4. #i(midi-control-change time 0.0 channel 2 controller 7 value 127) > ? > so I guess I need to somehow filter out those events(?) that do not > contain keynum (as later events do) if I want to do some transposing > as per one of the tutorial examples.? Can you point me to something?? > ? > Thanks. > ? > And I have just ordered and am eagerly awaiting ?Notes from the > Metalevel??? which I was turned on to by a recent review in the > Computer Music Journal. > ? > Denis Fitzpatrick > ? From taube at uiuc.edu Thu Sep 22 08:33:14 2005 From: taube at uiuc.edu (Rick Taube) Date: Thu, 22 Sep 2005 10:33:14 -0500 Subject: [CM] ICMC spectral workshop materials available Message-ID: Ive put the materials for the "Spectral Composition and Algorithmic Design" workshop I gave at ICMC two weeks ago on Pinhead for anyone interested: http://pinhead.music.uiuc.edu/~hkt/spectral-workshop-icmc-2005.tar.gz A description of this workshop is still on the icmc2005 website: http://www.icmc2005.org/index.php?selectedPage=120 The tarball includes both a Powerpoint and a PDF version of the overheads. The workshop gave a practical intro to composing with spectral data using free programs. The overheads discuss two remarkable, new software projects: SPEAR, by Michael Klingbeil ( http://www.klingbeil.com/spear ) and FOMUS, by David Psenicka ( http://common-lisp.net/project/fomus/ ) . Several of the examples show how to get SPEAR data into CM. All the music notation examples in the presentations are unedited output of fomus->lilypond. Sources for most if not all the examples are in the sources/ subdir (i have not tested it) enjoy! --rick From marco at trevisani.net Thu Sep 22 09:25:44 2005 From: marco at trevisani.net (marco trevisani) Date: Thu, 22 Sep 2005 12:25:44 -0400 Subject: [CM] clm compiling problem Message-ID: <20050922162544.GA14163@trevisani.net> Hi, I decided to upgrade clm-3 ( i havent done this in about one year now) and i ran into a compilation problem... (first time in 11 years that clm does not compile smoothly out of the box) Here is what i get (i've made attemps with both cmucl and sbcl. Here follows the sbcl output, which is a bit more verbose than cmucl) [ previous steps : ./configure --with-alsa sbcl --load "all.lisp" ] ; using existing configuration file config.h ; Creating "/home/marco/src/clm/old_style/clm-3/libclm.so" ;;ld -shared -whole-archive -o ; /home/marco/src/clm/old_style/clm-3/libclm.so ; /home/marco/src/clm/old_style/clm-3/headers.o ; /home/marco/src/clm/old_style/clm-3/audio.o ; /home/marco/src/clm/old_style/clm-3/io.o ; /home/marco/src/clm/old_style/clm-3/sound.o ; /home/marco/src/clm/old_style/clm-3/clm.o ; /home/marco/src/clm/old_style/clm-3/cmus.o ; /home/marco/src/clm/old_style/clm-3/sc.o -L/usr/X11R6/lib -lX11 ;compiling /home/marco/src/clm/old_style/clm-3/clm-package.lisp ;compiling /home/marco/src/clm/old_style/clm-3/initmus.lisp debugger invoked on a SIMPLE-ERROR in thread #: Error during processing of --eval option "(|LOAD| \"all.lisp\")": Error opening shared object "/home/marco/src/clm/old_style/clm-3/libclm.so": /home/marco/src/clm/old_style/clm-3/libclm.so: undefined symbol: snd_card_next. Any clue? thanks, marco trevisani From immanuell at enfocus.be Fri Sep 23 00:32:30 2005 From: immanuell at enfocus.be (Immanuel Litzroth) Date: Fri, 23 Sep 2005 08:32:30 +0100 Subject: [CM] clm compiling problem In-Reply-To: <20050922162544.GA14163@trevisani.net> (marco trevisani's message of "Thu, 22 Sep 2005 12:25:44 -0400") References: <20050922162544.GA14163@trevisani.net> Message-ID: "marco trevisani" writes: > Hi, > > I decided to upgrade clm-3 ( i havent done this in about one year now) > and i ran into a compilation problem... (first time in 11 years that > clm does not compile smoothly out of the box) > > Here is what i get (i've made attemps with both cmucl and sbcl. Here > follows the sbcl output, which is a bit more verbose than cmucl) > > [ > previous steps : > ./configure --with-alsa > sbcl --load "all.lisp" > ] > > > ; using existing configuration file config.h > ; Creating "/home/marco/src/clm/old_style/clm-3/libclm.so" > ;;ld -shared -whole-archive -o > ; /home/marco/src/clm/old_style/clm-3/libclm.so > ; /home/marco/src/clm/old_style/clm-3/headers.o > ; /home/marco/src/clm/old_style/clm-3/audio.o > ; /home/marco/src/clm/old_style/clm-3/io.o > ; /home/marco/src/clm/old_style/clm-3/sound.o > ; /home/marco/src/clm/old_style/clm-3/clm.o > ; /home/marco/src/clm/old_style/clm-3/cmus.o > ; /home/marco/src/clm/old_style/clm-3/sc.o -L/usr/X11R6/lib -lX11 > > ;compiling /home/marco/src/clm/old_style/clm-3/clm-package.lisp > ;compiling /home/marco/src/clm/old_style/clm-3/initmus.lisp > debugger invoked on a SIMPLE-ERROR in thread # ;{90034A1}>: > Error during processing of --eval option "(|LOAD| \"all.lisp\")": > > Error opening shared object "/home/marco/src/clm/old_style/clm-3/libclm.so": > /home/marco/src/clm/old_style/clm-3/libclm.so: undefined symbol: > snd_card_next. you need to load the alsa library in your lisp or link libclm.so against it. The best way is to link libclm to alsa library, because lispworks has problems with objects that contain undefined references. On CMU and SBCL both ways should work. Immanuel From bil at ccrma.Stanford.EDU Fri Sep 23 04:45:37 2005 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Fri, 23 Sep 2005 04:45:37 -0700 Subject: [CM] clm compiling problem In-Reply-To: <20050922162544.GA14163@trevisani.net> References: <20050922162544.GA14163@trevisani.net> Message-ID: <4333EAE1.7070103@ccrma> Don't run configure yourself --lisp and C have to agree on the current configuration when lisp tries to compile and load anything (an instrument, for example), so lisp has to be the one that calls configure. To get the alsa library, first get back to a clean state (i.e. get rid of config.h and maybe makefile), then start lisp, (pushnew :alsa *features*) and load all.lisp. This will cause lisp to include --with-alsa when it runs configure, and -lasound when it loads stuff. It might help also to (pushnew :reconfigure *features*) -- this forces lisp to run the configure script even if it thinks everything is up-to-date. From taube at uiuc.edu Fri Sep 23 06:18:50 2005 From: taube at uiuc.edu (Rick Taube) Date: Fri, 23 Sep 2005 08:18:50 -0500 Subject: [CM] rts debut Message-ID: <809813b15264c8b03b803b40c743b013@uiuc.edu> Composers might be interested in Hanspeters experience witht the new rts scheduler todd and i have been working on. Im forwarding most of his note with his permission. Begin forwarded message: > From: Hanspeter Kyburz > Date: September 23, 2005 5:20:50 AM CDT > To: Rick Taube > Subject: Re: midishare? > > Hi Rick, > > it was really impressing! We had our last ten day block of experiments > in > the hall of Centre Pompidou in Paris with the dancer (Emio Greco), > video > (Joost Rekveld), light (Pieter Scholten), Max (Wolfgang Heiniger) and > CM > (me). > > One rt-process simulted a virutal ensemble, which will be replaced in > the > concerts by the Ensemble Intercontemporain. The other rt-processes were > sprouted and continously modulated by more or less imprevisible > gestures of > the dancer, but nevertheless were strictly referring harmonically and > rhythmically to the dynamic context of the ensemble's deveopment. I > was most > exciting to watch complex patterns based on descrete elements > depending on > continous realtime control. > > Some people who came by sat there for hours just to follow the > rehearsals. > Boulez also came and stayed there until the late evening, all the time > asking questions about CMs patterns. What a curious guy with his 80 > years! > But above all it was quite a shock for some of the Ircam programmers > [...] > , who were most interested in OpenMCLs > native parallel threads and CMs rt-scheduler. > > With the Vienna Sample Library's sounds we even had a quite realistic > simulation of the ensemble. One machine was just used for data > conditioning, > filtering the incoming sensor data. From my machine CMs Mididata were > sent > via Midishare (4 IAC Ports) to Kontakt (Software Sampler) and directly > to > the another computer's video processing (Jitter). Kontakt's Audio was > sent > from my machine to MAX on Wolfgang's computer. Communication remained > stable > during the whole period of 9 days. > > My whole code has got blown up and is not very transparent at the > moment. As > soon as I have time to comment it, I will send it to you. First I have > to > clean it up and finish the score for the ensemble. Concerts will start > in > Nov 8, 9, 10 and there will be two tours each of a month with several > concerts in 2006. I hope we will have a reasonable video recording of > the > premiere which I can send to you. > [...] From heisters at 0x09.com Fri Sep 23 06:48:22 2005 From: heisters at 0x09.com (Ian Smith-Heisters) Date: Fri, 23 Sep 2005 09:48:22 -0400 Subject: [CM] rts debut In-Reply-To: <809813b15264c8b03b803b40c743b013@uiuc.edu> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> Message-ID: <433407A6.9000007@0x09.com> This is very interesting. Would it be possible to get more information about the dance side of things? My primary interest in c(l)m w/ rts is for use with my dance. -Ian Rick Taube wrote: > Composers might be interested in Hanspeters experience witht the new rts > scheduler todd and i have been working on. Im forwarding most of his > note with his permission. > > Begin forwarded message: > >> From: Hanspeter Kyburz >> Date: September 23, 2005 5:20:50 AM CDT >> To: Rick Taube >> Subject: Re: midishare? >> >> Hi Rick, >> >> it was really impressing! We had our last ten day block of experiments in >> the hall of Centre Pompidou in Paris with the dancer (Emio Greco), video >> (Joost Rekveld), light (Pieter Scholten), Max (Wolfgang Heiniger) and CM >> (me). >> >> One rt-process simulted a virutal ensemble, which will be replaced in the >> concerts by the Ensemble Intercontemporain. The other rt-processes were >> sprouted and continously modulated by more or less imprevisible >> gestures of >> the dancer, but nevertheless were strictly referring harmonically and >> rhythmically to the dynamic context of the ensemble's deveopment. I >> was most >> exciting to watch complex patterns based on descrete elements >> depending on >> continous realtime control. >> >> Some people who came by sat there for hours just to follow the >> rehearsals. >> Boulez also came and stayed there until the late evening, all the time >> asking questions about CMs patterns. What a curious guy with his 80 >> years! >> But above all it was quite a shock for some of the Ircam programmers >> [...] >> , who were most interested in OpenMCLs >> native parallel threads and CMs rt-scheduler. >> >> With the Vienna Sample Library's sounds we even had a quite realistic >> simulation of the ensemble. One machine was just used for data >> conditioning, >> filtering the incoming sensor data. From my machine CMs Mididata were >> sent >> via Midishare (4 IAC Ports) to Kontakt (Software Sampler) and directly to >> the another computer's video processing (Jitter). Kontakt's Audio was >> sent >> from my machine to MAX on Wolfgang's computer. Communication remained >> stable >> during the whole period of 9 days. >> >> My whole code has got blown up and is not very transparent at the >> moment. As >> soon as I have time to comment it, I will send it to you. First I have to >> clean it up and finish the score for the ensemble. Concerts will start in >> Nov 8, 9, 10 and there will be two tours each of a month with several >> concerts in 2006. I hope we will have a reasonable video recording of the >> premiere which I can send to you. >> [...] > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From taube at uiuc.edu Fri Sep 23 07:15:33 2005 From: taube at uiuc.edu (Rick Taube) Date: Fri, 23 Sep 2005 09:15:33 -0500 Subject: [CM] rts debut In-Reply-To: <433407A6.9000007@0x09.com> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> Message-ID: <73a1f7678677f0a6a3183b8b282f9549@uiuc.edu> Hello Ian - Send a note to Hanspeter , perhaps he can explain how he's processing dance - he seems way way out on the curve with this stuff. --rick On Sep 23, 2005, at 8:48 AM, Ian Smith-Heisters wrote: > This is very interesting. Would it be possible to get more information > about the dance side of things? My primary interest in c(l)m w/ rts is > for use with my dance. > > -Ian From heisters at 0x09.com Fri Sep 23 09:17:14 2005 From: heisters at 0x09.com (Ian Smith-Heisters) Date: Fri, 23 Sep 2005 12:17:14 -0400 Subject: [CM] rts debut In-Reply-To: References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> Message-ID: <43342A8A.1070000@0x09.com> I've been very interested in opening up Lisp to do realtime video (raster mostly, as opposed to 3D). However, I haven't even had time to move from SC to SND/CLM yet, so video is a ways off. One thought I had was to use PDP, which started as PureDataPackets, but is now a C library, which it should be possible to interface to with Lisp. A native Lisp solution would of course be preferrable. I would be surprised if there wasn't already a Lisp facility to work with graphics as matrices. It shouldn't be a huge jump to move from there to mjpeg. I emailed Hanspeter with some questions, if he responds I'll ask his permission to further post it to the list. -Ian todd ingalls wrote: > ian, > > This is in part a great deal of my interest as well. > > The first badly hacked version of rt stuff came from me using cm to > communicate to supercollider in response to some motion analysis we are > doing based on real-time motion capture in performance. at that time > things worked well responding to this data. > > anyway, something i would be interested in looking at for the future > would be using the quicktime framegrabber to do some basic video > analysis in openmcl. also maybe a lisp interface to teleo modules or > other type of sensors. > > i would really be interested to hear more from hanspeter as well on what > they are doing - it sounds like they've made quite an impression! > > On Sep 23, 2005, at 6:48 AM, Ian Smith-Heisters wrote: > >> This is very interesting. Would it be possible to get more information >> about the dance side of things? My primary interest in c(l)m w/ rts is >> for use with my dance. >> >> -Ian >> >> Rick Taube wrote: >> >>> Composers might be interested in Hanspeters experience witht the new >>> rts scheduler todd and i have been working on. Im forwarding most of >>> his note with his permission. >>> Begin forwarded message: >>> >>>> From: Hanspeter Kyburz >>>> Date: September 23, 2005 5:20:50 AM CDT >>>> To: Rick Taube >>>> Subject: Re: midishare? >>>> >>>> Hi Rick, >>>> >>>> it was really impressing! We had our last ten day block of >>>> experiments in >>>> the hall of Centre Pompidou in Paris with the dancer (Emio Greco), >>>> video >>>> (Joost Rekveld), light (Pieter Scholten), Max (Wolfgang Heiniger) >>>> and CM >>>> (me). >>>> >>>> One rt-process simulted a virutal ensemble, which will be replaced >>>> in the >>>> concerts by the Ensemble Intercontemporain. The other rt-processes were >>>> sprouted and continously modulated by more or less imprevisible >>>> gestures of >>>> the dancer, but nevertheless were strictly referring harmonically and >>>> rhythmically to the dynamic context of the ensemble's deveopment. I >>>> was most >>>> exciting to watch complex patterns based on descrete elements >>>> depending on >>>> continous realtime control. >>>> >>>> Some people who came by sat there for hours just to follow the >>>> rehearsals. >>>> Boulez also came and stayed there until the late evening, all the time >>>> asking questions about CMs patterns. What a curious guy with his 80 >>>> years! >>>> But above all it was quite a shock for some of the Ircam programmers >>>> [...] >>>> , who were most interested in OpenMCLs >>>> native parallel threads and CMs rt-scheduler. >>>> >>>> With the Vienna Sample Library's sounds we even had a quite realistic >>>> simulation of the ensemble. One machine was just used for data >>>> conditioning, >>>> filtering the incoming sensor data. From my machine CMs Mididata >>>> were sent >>>> via Midishare (4 IAC Ports) to Kontakt (Software Sampler) and >>>> directly to >>>> the another computer's video processing (Jitter). Kontakt's Audio >>>> was sent >>>> from my machine to MAX on Wolfgang's computer. Communication >>>> remained stable >>>> during the whole period of 9 days. >>>> >>>> My whole code has got blown up and is not very transparent at the >>>> moment. As >>>> soon as I have time to comment it, I will send it to you. First I >>>> have to >>>> clean it up and finish the score for the ensemble. Concerts will >>>> start in >>>> Nov 8, 9, 10 and there will be two tours each of a month with several >>>> concerts in 2006. I hope we will have a reasonable video recording >>>> of the >>>> premiere which I can send to you. >>>> [...] >>> >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From taube at uiuc.edu Fri Sep 23 09:58:03 2005 From: taube at uiuc.edu (Rick Taube) Date: Fri, 23 Sep 2005 11:58:03 -0500 Subject: [CM] rts debut In-Reply-To: <43342A8A.1070000@0x09.com> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> Message-ID: <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> > One thought I had was to use PDP, which started as PureDataPackets, > but is now a C library, which it should be possible to interface to > with Lisp. A native Lisp solution would of course be preferrable. depending on what you want to do, writing an ffi for the c lib might actually be the way to go. the cffi project (http://common-lisp.net/project/cffi/) seems to be a good choice for implementing a single generic ffi that will works in most common lisps. or could you send this data via osc? if so the osc support in cm right now might also be worth looking at. --rick From heisters at 0x09.com Fri Sep 23 10:34:02 2005 From: heisters at 0x09.com (Ian Smith-Heisters) Date: Fri, 23 Sep 2005 13:34:02 -0400 Subject: [CM] rts debut In-Reply-To: <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> Message-ID: <43343C8A.3030405@0x09.com> That would be the simplest; to set CM up as an OSC client to a PD-PDP server. But that doesn't avoid the primary obnoxiousness of PD which is that I revile graphical programming for any serious task. Connecting all those damn patch cords drives me crazy. I played with Lisp's FFI this summmer and couldn't quite get a handle on it in the short time I had. That's why I'd tend toward a Lisp-native solution. But maybe that's rather a sign I should buckle down and figure out FFI. There might also be possibilities with GridFlow, which uses ruby and offers some nice RT matrix manipulations. If only I could get paid to work on this stuff; I'll never get anything done working in my spare time ;) -Ian Rick Taube wrote: >> One thought I had was to use PDP, which started as PureDataPackets, >> but is now a C library, which it should be possible to interface to >> with Lisp. A native Lisp solution would of course be preferrable. > > > depending on what you want to do, writing an ffi for the c lib might > actually be the way to go. the cffi project > (http://common-lisp.net/project/cffi/) seems to be a good choice for > implementing a single generic ffi that will works in most common lisps. > > or could you send this data via osc? if so the osc support in cm right > now might also be worth looking at. > > --rick > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From renueden at earthlink.net Fri Sep 23 11:33:07 2005 From: renueden at earthlink.net (Ken) Date: Fri, 23 Sep 2005 11:33:07 -0700 Subject: [CM] rts debut In-Reply-To: <43343C8A.3030405@0x09.com> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> <43343C8A.3030405@0x09.com> Message-ID: <43344A63.9000607@earthlink.net> Ian Smith-Heisters wrote: > That would be the simplest; to set CM up as an OSC client to a PD-PDP > server. But that doesn't avoid the primary obnoxiousness of PD which > is that I revile graphical programming for any serious task. > Connecting all those damn patch cords drives me crazy. > > I played with Lisp's FFI this summmer and couldn't quite get a handle > on it in the short time I had. That's why I'd tend toward a > Lisp-native solution. But maybe that's rather a sign I should buckle > down and figure out FFI. > > There might also be possibilities with GridFlow, which uses ruby and > offers some nice RT matrix manipulations. If only I could get paid to > work on this stuff; I'll never get anything done working in my spare > time ;) > > -Ian > > Rick Taube wrote: > >>> One thought I had was to use PDP, which started as PureDataPackets, >>> but is now a C library, which it should be possible to interface to >>> with Lisp. A native Lisp solution would of course be preferrable. >> >> >> >> depending on what you want to do, writing an ffi for the c lib might >> actually be the way to go. the cffi project >> (http://common-lisp.net/project/cffi/) seems to be a good choice for >> implementing a single generic ffi that will works in most common lisps. >> >> or could you send this data via osc? if so the osc support in cm >> right now might also be worth looking at. >> >> --rick >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > i know the feeling, about time that is. i would love to add opengl classes to cm, so that we could compose real-time 3d graphics with sound. things may open up for me later this year though.... From heisters at 0x09.com Fri Sep 23 11:38:08 2005 From: heisters at 0x09.com (Ian Smith-Heisters) Date: Fri, 23 Sep 2005 14:38:08 -0400 Subject: [CM] rts debut In-Reply-To: <43344A63.9000607@earthlink.net> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> <43343C8A.3030405@0x09.com> <43344A63.9000607@earthlink.net> Message-ID: <43344B90.9020506@0x09.com> Hey, I've got land. We could start a coding cooperative where we farm 4 hours a day and code and make music the rest. I'm only half joking. Ken wrote: > Ian Smith-Heisters wrote: > >> That would be the simplest; to set CM up as an OSC client to a PD-PDP >> server. But that doesn't avoid the primary obnoxiousness of PD which >> is that I revile graphical programming for any serious task. >> Connecting all those damn patch cords drives me crazy. >> >> I played with Lisp's FFI this summmer and couldn't quite get a handle >> on it in the short time I had. That's why I'd tend toward a >> Lisp-native solution. But maybe that's rather a sign I should buckle >> down and figure out FFI. >> >> There might also be possibilities with GridFlow, which uses ruby and >> offers some nice RT matrix manipulations. If only I could get paid to >> work on this stuff; I'll never get anything done working in my spare >> time ;) >> >> -Ian >> >> Rick Taube wrote: >> >>>> One thought I had was to use PDP, which started as PureDataPackets, >>>> but is now a C library, which it should be possible to interface to >>>> with Lisp. A native Lisp solution would of course be preferrable. >>> >>> >>> >>> >>> depending on what you want to do, writing an ffi for the c lib might >>> actually be the way to go. the cffi project >>> (http://common-lisp.net/project/cffi/) seems to be a good choice for >>> implementing a single generic ffi that will works in most common lisps. >>> >>> or could you send this data via osc? if so the osc support in cm >>> right now might also be worth looking at. >>> >>> --rick >>> >>> _______________________________________________ >>> Cmdist mailing list >>> Cmdist at ccrma.stanford.edu >>> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> >> > i know the feeling, about time that is. > > i would love to add opengl classes to cm, so that we could compose > real-time 3d graphics with sound. > > things may open up for me later this year though.... > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3170 bytes Desc: S/MIME Cryptographic Signature URL: From testcase at asu.edu Fri Sep 23 09:06:48 2005 From: testcase at asu.edu (todd ingalls) Date: Fri, 23 Sep 2005 09:06:48 -0700 Subject: [CM] rts debut In-Reply-To: <433407A6.9000007@0x09.com> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> Message-ID: ian, This is in part a great deal of my interest as well. The first badly hacked version of rt stuff came from me using cm to communicate to supercollider in response to some motion analysis we are doing based on real-time motion capture in performance. at that time things worked well responding to this data. anyway, something i would be interested in looking at for the future would be using the quicktime framegrabber to do some basic video analysis in openmcl. also maybe a lisp interface to teleo modules or other type of sensors. i would really be interested to hear more from hanspeter as well on what they are doing - it sounds like they've made quite an impression! On Sep 23, 2005, at 6:48 AM, Ian Smith-Heisters wrote: > This is very interesting. Would it be possible to get more information > about the dance side of things? My primary interest in c(l)m w/ rts is > for use with my dance. > > -Ian > > Rick Taube wrote: >> Composers might be interested in Hanspeters experience witht the new >> rts scheduler todd and i have been working on. Im forwarding most of >> his note with his permission. >> Begin forwarded message: >>> From: Hanspeter Kyburz >>> Date: September 23, 2005 5:20:50 AM CDT >>> To: Rick Taube >>> Subject: Re: midishare? >>> >>> Hi Rick, >>> >>> it was really impressing! We had our last ten day block of >>> experiments in >>> the hall of Centre Pompidou in Paris with the dancer (Emio Greco), >>> video >>> (Joost Rekveld), light (Pieter Scholten), Max (Wolfgang Heiniger) >>> and CM >>> (me). >>> >>> One rt-process simulted a virutal ensemble, which will be replaced >>> in the >>> concerts by the Ensemble Intercontemporain. The other rt-processes >>> were >>> sprouted and continously modulated by more or less imprevisible >>> gestures of >>> the dancer, but nevertheless were strictly referring harmonically and >>> rhythmically to the dynamic context of the ensemble's deveopment. I >>> was most >>> exciting to watch complex patterns based on descrete elements >>> depending on >>> continous realtime control. >>> >>> Some people who came by sat there for hours just to follow the >>> rehearsals. >>> Boulez also came and stayed there until the late evening, all the >>> time >>> asking questions about CMs patterns. What a curious guy with his 80 >>> years! >>> But above all it was quite a shock for some of the Ircam programmers >>> [...] >>> , who were most interested in OpenMCLs >>> native parallel threads and CMs rt-scheduler. >>> >>> With the Vienna Sample Library's sounds we even had a quite realistic >>> simulation of the ensemble. One machine was just used for data >>> conditioning, >>> filtering the incoming sensor data. From my machine CMs Mididata >>> were sent >>> via Midishare (4 IAC Ports) to Kontakt (Software Sampler) and >>> directly to >>> the another computer's video processing (Jitter). Kontakt's Audio >>> was sent >>> from my machine to MAX on Wolfgang's computer. Communication >>> remained stable >>> during the whole period of 9 days. >>> >>> My whole code has got blown up and is not very transparent at the >>> moment. As >>> soon as I have time to comment it, I will send it to you. First I >>> have to >>> clean it up and finish the score for the ensemble. Concerts will >>> start in >>> Nov 8, 9, 10 and there will be two tours each of a month with several >>> concerts in 2006. I hope we will have a reasonable video recording >>> of the >>> premiere which I can send to you. >>> [...] >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Fri Sep 23 11:55:26 2005 From: taube at uiuc.edu (Rick Taube) Date: Fri, 23 Sep 2005 13:55:26 -0500 Subject: [CM] rts debut In-Reply-To: <43344A63.9000607@earthlink.net> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> <43343C8A.3030405@0x09.com> <43344A63.9000607@earthlink.net> Message-ID: <285d8715eef0ecb9f8b755a11be703a3@uiuc.edu> ken -- ive not looked at it but I think OpenMcl aleady has an ffi to the opengl library: ccl/examples/opengl.lisp and /ccl/darwin-headers/gl/ see also http://www.cliki.net/OpenGL%20Bindings and http://www.lisp-p.org/taga/node5.html i think kenny tillman has written an openal interface using cffi. so if time is money then maybe you just got paid :) > i know the feeling, about time that is. > > i would love to add opengl classes to cm, so that we could compose > real-time 3d graphics with sound. > > things may open up for me later this year though.... > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From testcase at asu.edu Fri Sep 23 12:01:15 2005 From: testcase at asu.edu (todd ingalls) Date: Fri, 23 Sep 2005 12:01:15 -0700 Subject: [CM] rts debut In-Reply-To: <43344A63.9000607@earthlink.net> References: <809813b15264c8b03b803b40c743b013@uiuc.edu> <433407A6.9000007@0x09.com> <43342A8A.1070000@0x09.com> <77a2a93980533c98b4b77bce46f512e5@uiuc.edu> <43343C8A.3030405@0x09.com> <43344A63.9000607@earthlink.net> Message-ID: <58f660ce669ec874bd8608f2d6759dc5@asu.edu> i am close to having this done in openmcl (the gl classes) and might work similiarly in other lisps/platforms. when i have something working it would be cool to get some help and feedback if you have the time. On Sep 23, 2005, at 11:33 AM, Ken wrote: >>> >> > i know the feeling, about time that is. > > i would love to add opengl classes to cm, so that we could compose > real-time 3d graphics with sound. > > things may open up for me later this year though.... > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From taube at uiuc.edu Sun Sep 25 10:00:14 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 25 Sep 2005 12:00:14 -0500 Subject: [CM] comp.lang.lisp posting Message-ID: <2d75e4e6d299c6370b8ec1b6b3c7581c@uiuc.edu> Lispy musicians will enjoy a really nice answer to a "whats-so-great-about-Lisp?" flame-bait that was posted on comp.lang.lisp. here is a good link for it: http://bc.tech.coop/blog/050923.html From dlphillips at woh.rr.com Tue Sep 27 05:38:49 2005 From: dlphillips at woh.rr.com (Dave Phillips) Date: Tue, 27 Sep 2005 08:38:49 -0400 Subject: [CM] cmio compile error report Message-ID: <43393D59.5030901@woh.rr.com> Greetings: Just a quick note to remark that compiling eventio.lisp on CMUCL (Planet CCRMA RH9) generates this error: ; Compiling "src/gui/eventio.lisp" ; ; ; File: /home/dlphilp/cm/src/gui/eventio.lisp ; In: DEFMETHOD CMIO-SET-PAGE-DATA (T (EQL :MIDISHARE) T) ; (ELT WIDG3 2) ; Warning: Lisp error during constant folding: ; Error in LISP::SIGNAL-INDEX-TOO-LARGE-ERROR: 2: Index too large. ; ; (ELT WIDG3 4) ; Warning: Lisp error during constant folding: ; Error in LISP::SIGNAL-INDEX-TOO-LARGE-ERROR: 4: Index too large. ; Loading "bin/cmucl_2004-11_linux-i686/eventio.x86f"; ; Compilation unit finished. ; 2 warnings Attempting to run cmio fails with this error: * (cmio) Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER: the function RTS? is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER "" #.(SYSTEM:INT-SAP #x3FFFCDDC) # (14)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/interr.lisp. 0] 0 * I realize the I/O stuff is still being worked on, so this message is merely an update of the compile process here at Studio Dave. I'm looking forward to the new additions. Btw, I tested the Portmidi examples, they worked fine. Alas, I haven't much time for CM these days, but I'll try to keep up with the CVS sources. Best, dp From taube at uiuc.edu Tue Sep 27 06:20:06 2005 From: taube at uiuc.edu (Rick Taube) Date: Tue, 27 Sep 2005 08:20:06 -0500 Subject: [CM] Re: cmio compile error report In-Reply-To: <3884cdce4551eee49dbefa608fece3ad@uiuc.edu> References: <43393D59.5030901@woh.rr.com> <3884cdce4551eee49dbefa608fece3ad@uiuc.edu> Message-ID: <10f9587eeda7a5975d36a4d049fcb85f@uiuc.edu> Dave -- first , thanks so much for the review! ill try to patch the the cmio window later today so it compiles in cmu. the window is getting close to done but is still not functional (i did a major upgrade to all the new stuff). hopefully the window and supercollider realtime can be "announced" in a week's time. it seems as if the latest sbcl may have callbacks on linux. if so that will defintaly be a bettern choice for cm/real time then cmucl. ill post someting to the list if everything checks out. thanks for the bug report! --rick > I realize the I/O stuff is still being worked on, so this message is > merely an update of the compile process here at Studio Dave. I'm > looking forward to the new additions. > > Btw, I tested the Portmidi examples, they worked fine. Alas, I haven't > much time for CM these days, but I'll try to keep up with the CVS > sources. > > Best, > > dp > From mlang at delysid.org Fri Sep 30 02:01:12 2005 From: mlang at delysid.org (Mario Lang) Date: Fri, 30 Sep 2005 11:01:12 +0200 Subject: [CM] The simplest defsynth possible Message-ID: <87ek77expj.fsf@lexx.delysid.org> Hi. Since I am a SC fanatic with a bias towards Lisp, I'd really like to play with CM's SC support, but the fact that SynthDef and scheduling code is separate really turns me off. This is soooo csound! :-/ Ideally, we should be able to define the synth graph in the same language IMO. Below is the probably simplest implementation to do this, as an inspiration. It uses Emacs's interface to SCLang, translating synth definition in Lisp into sclang code and evaluating it in sclang to generate the required def (actually, it already sends it to the server using .store). I see two approaches if someone wants to do this in CM directly: 1: Either do the same as below, but send the string to sclang as a subprocess, simply fork sclang and pass the code to it so it can write the def file or send the def to the server. 2: Emulate the behaviour of SynthDef.writeDef in the macro directly and generate the necessary binary blob. Its actually not *that* complicated, the most important issue is that we don't know the class definitions of sclang in Lisp so we *need* to make defsynth a macro to be able to use arbitrary symbol names. Now, here is the code, with a usage example at the end. Now, wouldnt that be sweet for CM directly? Ideally, the macro should be a little more intelligent, allowing real lisp code inside the definition which is evaluated at macro expansion time. But for a pure graph definition, the system below is enough. (defmacro defsynth (name args &rest body) "Define a synth graph with NAME and ARGS and BODY. Returns NAME as symbol with property 'sclang-code. Use `sclang-store-synth' to actually send the generated code to sclang." (put name 'sclang-code (sclang-format "SynthDef(%o, {%s%s})" name (if args (concat "arg "(mapconcat (lambda (arg) (if (consp arg) (sclang-format "%s=%o" (car arg) (cadr arg)) (sclang-format "%s" arg))) args ", ")";\n") "") (mapconcat #'sclang-lisp-to-sc body "\n"))) `',name) (defun sclang-lisp-to-sc (expr) (cond ((consp expr) (cond (t (sclang-format "%s(%s);" (car expr) (mapconcat #'sclang-lisp-to-sc (cdr expr) ", "))))) (t (format "%S" expr)))) (defun sclang-store-synth (synth) (sclang-eval-string (sclang-format "%s.store" (get synth 'sclang-code)))) ;; USAGE (sclang-store-synth (defsynth fasl ((freq 440) (amp 0.2) (out 0)) (Out.ar out (SinOsc.ar freq 0 amp)))) -- CYa, Mario