From bil at ccrma.Stanford.EDU Mon Nov 7 12:38:42 2011 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Mon, 7 Nov 2011 12:38:42 -0800 Subject: [CM] Snd 12.6 Message-ID: <20111107203717.M71440@ccrma.Stanford.EDU> Snd 12.6 s7 is faster. removed the --with-doubles configuration switch. changed s7_make_closure args (see s7.h). added procedure-name and s7_procedure_name. checked: sbcl 1.0.52|3, gtk 3.2.1|3.3.2, fth 1.2.9, cmucl 20c Thanks!: Michael Edwards, Geoff Lee, Mike Scholz, Rick Taube. From schemelab at gmail.com Fri Nov 11 19:55:06 2011 From: schemelab at gmail.com (Terrence Brannon) Date: Fri, 11 Nov 2011 22:55:06 -0500 Subject: [CM] Grace Beginner Message-ID: Hello, I have an Alesis Q49 midi keyboard connected via USB to my computer which is running Grace. I have successfully configured Audio -> Midi Out and Audio -> Midi In and I managed to get some sal demos playing. However, I'd like to try composing a few songs myself via my midi keyboard. I've looked at the online copy of the book ( http://web.archive.org/web/20050312064421/http://pinhead.music.uiuc.edu/~hkt/nm/00/contents.html ) and it doesnt seem to cover the basics of making simple songs in full detail. If anyone could point to some tutorials on this subject I would appreciate it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjkoskin at kolumbus.fi Thu Nov 17 17:22:40 2011 From: mjkoskin at kolumbus.fi (Matti Koskinen) Date: Fri, 18 Nov 2011 03:22:40 +0200 Subject: [CM] cm rts? Message-ID: <09A998ED-16ED-4C51-8DF6-FB78B184F3EB@kolumbus.fi> hi all, it's been very quiet here, so I hope Rick could answer my question. After reading the sad news about McCarthy I tried lisp again. So far I've succeed building cm-2.10 with Clozure CL (64-bit) on osx lion, and got also the portmidi part working. Had to clean my linux-box and install win xp in order to use rtpMIDI (www.tobias--erichsen.de/rtpMIDI.html) and with that I can connect to osx network midi. Works, Grace works fine, also the test-no-cm.lisp in portmidi works, I can send to keyboard and back. In cm output works as well. But recording in cm needs rts, and the rts folder in sf is empty. Is there a place to download rts? It was quite an ordeal to get right packages to get portmidi. working. Latest cffi gave cryptic messages, luckily old posts here helped to find a version of cffi, and the things cleared. The thing I'm interested in lisp, is that in pastebin I found ga-music.lisp code. That was also a pain in the butt to get it to compile. Didn't occur that population in ccl was already in use and compiling ga-music gave also cryptic errors. Then as a last resort I checked with apropos population, and it's defined in many flavors in ccl. Changed the name and the file works. The format of the definition of notes is somewhat unclear yet, but hope to change it to cm's definitions, so I can record first with midi a phrase and the run ga on it and play back. But rts is needed, also in the cm2 documentation there's port midi-receive! but that doesn't exist. tia -matti From taube at illinois.edu Fri Nov 18 04:46:27 2011 From: taube at illinois.edu (Heinrich Taube) Date: Fri, 18 Nov 2011 06:46:27 -0600 Subject: [CM] cm rts? In-Reply-To: <09A998ED-16ED-4C51-8DF6-FB78B184F3EB@kolumbus.fi> References: <09A998ED-16ED-4C51-8DF6-FB78B184F3EB@kolumbus.fi> Message-ID: <09811E8F-CB05-4E86-8D48-BA7B2F7C7E58@illinois.edu> On Nov 17, 2011, at 7:22 PM, Matti Koskinen wrote: > hi all, > > it's been very quiet here, so I hope Rick could answer my question. yes its very quiet, but the elves are still typing. we are within a few days of audio plugins working and a metronome based scheduler ready for testing. > > But recording in cm needs rts, and the rts folder in sf is empty. Is > there a place to download rts? odd, i will poke around and see if i can find it. or perhaps its just hidden at sf ill take a look this weekend. > works. The format of the definition of notes is somewhat unclear > yet, but hope to change it to cm's definitions, so I can record > first with midi a phrase and the run ga on it and play back. But rts > is needed, also in the cm2 documentation there's port midi-receive! > but that doesn't exist. i think midi-receive was defined by the rts package which you cant find. if your code is not object based or huge you might consider moving it to s7 scheme. s7 rocks. its very fast and has many of the nicer cltl features. you could then use the osc and midi io in grace which work. > > tia > > -matti > > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist From mjkoskin at kolumbus.fi Fri Nov 18 06:42:11 2011 From: mjkoskin at kolumbus.fi (Matti Koskinen) Date: Fri, 18 Nov 2011 16:42:11 +0200 Subject: [CM] cm rts? In-Reply-To: <09811E8F-CB05-4E86-8D48-BA7B2F7C7E58@illinois.edu> References: <09A998ED-16ED-4C51-8DF6-FB78B184F3EB@kolumbus.fi> <09811E8F-CB05-4E86-8D48-BA7B2F7C7E58@illinois.edu> Message-ID: <423D7777-E4E7-4596-9E87-B7A95C176932@kolumbus.fi> On Nov 18, 2011, at 2:46 PM, Heinrich Taube wrote: > > On Nov 17, 2011, at 7:22 PM, Matti Koskinen wrote: > >> hi all, >> >> it's been very quiet here, so I hope Rick could answer my question. > > > yes its very quiet, but the elves are still typing. we are within a few days of audio plugins working and a metronome based scheduler ready for testing. > >> >> But recording in cm needs rts, and the rts folder in sf is empty. Is there a place to download rts? if found rts from cvs, there it still lies > > odd, i will poke around and see if i can find it. or perhaps its just hidden at sf ill take a look this weekend. > >> works. The format of the definition of notes is somewhat unclear yet, but hope to change it to cm's definitions, so I can record first with midi a phrase and the run ga on it and play back. But rts is needed, also in the cm2 documentation there's port midi-receive! but that doesn't exist. > > i think midi-receive was defined by the rts package which you cant find. if your code is not object based or huge you might consider moving it to s7 scheme. s7 rocks. its very fast and has many of the nicer cltl features. you could then use the osc and midi io in grace which work. My midi-setup works really great with Grace. Once you gave me a scheme-code using osc, and I used it till lion upgrade. Simplesynth can't now read sound fonts. I tried building fluidsynth both with macports and fink but they need jack and osx-jack don't work, well, jack from macports doesn't work either. So I gave up. the ga-code is full of defmethods, declasses etc, so porting to scheme wold take a giant's work. An ccl has a nice ide it's just like working with grace with evaluating by command-E etc. Bad there's no cl2scm-translator, scm2cl there is. Running cl as a subprocess to do its things and then reading the list to grace and scheme would be interesting to try. rts built without errors and but it looks like cm's recv is just set to output error: recv not loaded, although *features* shows :portmidi-recv is there thanks -matti From taube at illinois.edu Fri Nov 18 10:19:48 2011 From: taube at illinois.edu (Heinrich Taube) Date: Fri, 18 Nov 2011 12:19:48 -0600 Subject: [CM] cm rts? In-Reply-To: <423D7777-E4E7-4596-9E87-B7A95C176932@kolumbus.fi> References: <09A998ED-16ED-4C51-8DF6-FB78B184F3EB@kolumbus.fi> <09811E8F-CB05-4E86-8D48-BA7B2F7C7E58@illinois.edu> <423D7777-E4E7-4596-9E87-B7A95C176932@kolumbus.fi> Message-ID: <0527A5BC-D0A7-4406-A70F-D2072F2D420C@illinois.edu> > My midi-setup works really great with Grace. Once you gave me a > scheme-code using osc, and I used it till lion upgrade. Simplesynth > can't now read sound fonts. I tried building fluidsynth both with > macports and fink but they need jack and osx-jack don't work, well, > jack from macports doesn't work either. So I gave up. andrew burnson runs simplesynth on lion so i know it works there...anyway sometime next week you will be able to load apple's DLS plugin (for example) into grace and use that instead of sending data out to simple synth....if you want you can use juce's Plugin Host app to define whatever plugin graphs you want and test them out and then save them to files. then next week you will be able to load those graph file into Grace and send data to them. From taube at illinois.edu Fri Nov 18 15:20:24 2011 From: taube at illinois.edu (Heinrich Taube) Date: Fri, 18 Nov 2011 17:20:24 -0600 Subject: [CM] vst on linux? Message-ID: <482EFF07-211F-46C3-8BBF-87C56CAAAB7E@illinois.edu> i was assuming i could just build juce's plugin host on linux to use with vst plugins but ...can someone tell me if its possible to actually build the vst sdk on linux? i always thought vst was fine there but after downloading the most recent sdk (3) and also the 2.4 version i dont see any linux support , not even a makefile! googling around doesnt yield much confidence.... From nando at ccrma.Stanford.EDU Fri Nov 18 15:50:21 2011 From: nando at ccrma.Stanford.EDU (Fernando Lopez-Lezcano) Date: Fri, 18 Nov 2011 15:50:21 -0800 Subject: [CM] vst on linux? In-Reply-To: <482EFF07-211F-46C3-8BBF-87C56CAAAB7E@illinois.edu> References: <482EFF07-211F-46C3-8BBF-87C56CAAAB7E@illinois.edu> Message-ID: <4EC6EF3D.8060504@localhost> On 11/18/2011 03:20 PM, Heinrich Taube wrote: > i was assuming i could just build juce's plugin host on linux to use > with vst plugins but ...can someone tell me if its possible to > actually build the vst sdk on linux? i always thought vst was fine > there but after downloading the most recent sdk (3) and also the 2.4 > version i dont see any linux support , not even a makefile! googling > around doesnt yield much confidence.... vst support can be made to work on linux, I think you just need one header file and that's it (and then of course you need the software that uses it). But its license is incompatible with free licenses such as the gpl. You can't (legally) distribute software under the gpl that uses the vst header file. That is why you don't see a packaged version of ardour that includes that support. There is a header file out there that claims to be reverse engineered (at least part of the features) but I don't know if it was done cleanly and I have not looked at it in any detail. -- Fernando From mjkoskin at kolumbus.fi Mon Nov 21 16:14:07 2011 From: mjkoskin at kolumbus.fi (Matti Koskinen) Date: Tue, 22 Nov 2011 02:14:07 +0200 Subject: [CM] grace to lisp and back Message-ID: <69F6B463-BE0A-4D34-B8D0-C87F04DDFCF7@kolumbus.fi> Portmidi never worked in lisp cm, so I tried another approach. Looking at s7.html, there's a chapter about external c-programs to load as dynamic lib. I added the cload part in s7.c and built grace from source. All went well an I modified a socket-program found from the net. Now grace can send and receive messages in udp. In Clozure sockets are already available, and some lisp in CL and scheme in grace, and now the two can communicate (very basic, but works). Now I can send from grace a lisp s-expression and lisp evaluates it correctly. But the other way round is more difficult. Lists etc. are ok, but I tried to send something like this from lisp e.g.. "(define *cmd* '(define aa '(a b c d)))" to grace. eval-string evaluates the thing, but *cmd* is in uppercase : > *cmd* (DEFINE AA '(A B C D)) now (eval *cmd*) gives error, because DEFINE is in uppercase. The received message is in uppercase, so I convert it first lowercase, but s7 eval sets *cmd* anyway in uppercase. From scheme to lisp there's no problem as lisp handles symbols in uppercase ok. Tested more: outside the function this thing works, I ran it in parts, and then added eval-string back, and now it works there too after running eval-received with eval-string removed and the func only returned the msg in lowercase. Then running eval-strings with returned lowercase msg gave correct results, but first time running eval-string inside the function didn't work. Strange (define (eval-received msg) (let* ((msfg1 #f) (msg-len (string-length msg)) (strlower (make-string msg-len #\null))) (loop for i from 0 below msg-len do (string-set! strlower i (char-downcase (string-ref msg i)))) (print strlower) ;(eval (with-input-from-string strlower (lambda () (read)))))) (eval-string strlower))) -matti From bil at ccrma.Stanford.EDU Tue Nov 22 04:15:31 2011 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Tue, 22 Nov 2011 04:15:31 -0800 Subject: [CM] grace to lisp and back In-Reply-To: <69F6B463-BE0A-4D34-B8D0-C87F04DDFCF7@kolumbus.fi> References: <69F6B463-BE0A-4D34-B8D0-C87F04DDFCF7@kolumbus.fi> Message-ID: <20111122121217.M37976@ccrma.Stanford.EDU> I take it that it is Common Lisp that is putting the string in upper case? In some Lisps, you can set the desired default case or case sensitivity, etc. Some schemes are case insensitive, I think -- I vaguely remember example code that used CONS and whatnot, but I prefer case sensitive source. From mjkoskin at kolumbus.fi Tue Nov 22 05:09:23 2011 From: mjkoskin at kolumbus.fi (Matti Koskinen) Date: Tue, 22 Nov 2011 15:09:23 +0200 Subject: [CM] grace to lisp and back Message-ID: Yes, lisp sends in uppercase, that's why i convert it lowercase before eval. Probably a user error. Now it works. I sent the piano phase from lisp, and keyboard played it without a hitch. Tnx -matti From taube at illinois.edu Tue Nov 22 07:23:11 2011 From: taube at illinois.edu (Heinrich Taube) Date: Tue, 22 Nov 2011 09:23:11 -0600 Subject: [CM] grace to lisp and back In-Reply-To: <69F6B463-BE0A-4D34-B8D0-C87F04DDFCF7@kolumbus.fi> References: <69F6B463-BE0A-4D34-B8D0-C87F04DDFCF7@kolumbus.fi> Message-ID: you could use JUCE classes for this instead of an external lib, look at its StreamingSocket or InterprocessConnection classes. (This is what I used to make GraceCL, that code is unused now but all the socket stuff still exists in src/CommonLisp.cpp and it woked fine with most common lisps...) On Nov 21, 2011, at 6:14 PM, Matti Koskinen wrote: > Portmidi never worked in lisp cm, so I tried another approach. > > Looking at s7.html, there's a chapter about external c-programs to > load as dynamic lib. I added the > cload part in s7.c and built grace from source. All went well an I > modified a socket-program found from the net. > Now grace can send and receive messages in udp. From taube at illinois.edu Tue Nov 22 11:26:17 2011 From: taube at illinois.edu (Heinrich Taube) Date: Tue, 22 Nov 2011 13:26:17 -0600 Subject: [CM] metronomes and live coding Message-ID: Thanks to some really terrific work by Halim Beere, Grace now has some very cool new features. The most important things Halim has done is to add a new metronome facility and to convert the scheduler to be entirely metronome and beat based. If you do nothing then everything works as in the past, except that now you have (at least) one metronome available to use. Metros allow you to do many new things, for example, sprout process to start on a future beat regardless of tempo, move between tempos smoothy keeping all algos in sync, sync processes to different metronomes for poly-tempic things, all manner of phasing and syncing between metros, etc. its easy now to perfom reichs piano phase exactly as it is done in a concert. Halim also made some important changes to sprout() and stop() to support "live coding" . The main thing is that sprout now lets you _replace_ processes currently running in the scheudler with new versions but without altering the run time, sort of like "redefining" a running algorithm on the fly... He has added two very helpful example files that get you going and are lots of fun to work through: Help>Examples>Sal>Metronomes Help>Examples>Sal>Live Coding ill some point when the dust settles ill add these examples to the help>examples>scheme sub-menu too... The Metronome api is already documented, see the new Metronomes section in the Dictionary, and the updated doc on sprout() and stop() too. Metros should work in all ports, ive saved what apps I can make right now here: http://camil.music.uiuc.edu/software/grace/Grace-3.8.0-alpha3-osx.zip http://camil.music.uiuc.edu/software/grace/Grace-3.8.0-alpha3-ubuntu.zip Note that my ubuntu release 2009 is no longer support and audio isnt working in it anymore so I cant test audio or midi there anymore, at least not until after new years when i can hopefully get a new computer (mac with emulator :) ) there is no windows version yet , I can try to get it running there tomrrow. also: The Audio>Plugin menu that exists in this app is disabled for now, more about this in a few days! From aykut_caglayan at yahoo.com Tue Nov 22 15:01:58 2011 From: aykut_caglayan at yahoo.com (Aykut Caglayan) Date: Tue, 22 Nov 2011 15:01:58 -0800 (PST) Subject: [CM] metronomes and live coding In-Reply-To: References: Message-ID: <1322002918.34917.YahooMailNeo@web45702.mail.sp1.yahoo.com> Many thanks to Halim for his effort in making it possible to use CommonMusic as a live-coding language. While I was reading the metro.sal documantation, I transcribed it into the S7 Scheme.? I have pasted the whole document below. PS: i may read/transcribe the livecoding doc in a few days too. -- Aykut Caglayan (PhD) http://aykutcaglayan.blogspot.com/ ;;; -*- syntax: Lisp; font-size: 18; theme: "Emacs"; -*- ; ;; Metronomes ?(Halim Beere, halimbeere at gmail.com) ; ; Metronomes are objects that allow you to change the tempo of running ; processes in real-time. at least one metronome is always active, ; even if you do not specify a metronome the 'default metronome' will ; be in use. ?to access a metronome you use its 'id', the metronom id ; of the default metronome is always 0: ; current beat time of the default metro (metro-beat 0) ; most metronome functions take an optional 'metro' arg that lets you ; specify which metronome should be use. if you don't specify this ; value explicitly you will get whatever metronome is in th global ; varible *metro*. This variable is intiaily set to 0 (the default ; metronome) but you can reset it to any metronome that you create. ; if no metro is specified the metronome in *metro* will be used: (metro-beat ) ; use 'make-metro' to create a new metronome with some initial ; starting tempo. make-metro returns the new metronome's id as its ; value that you save in a variable for referenceing that metro (define mymetro (make-metro 100)) ; you can ask if there is a metro with a given id: (metro? mymetro) (metro? 0) ; you can get the current tempo and beat value of your metronome (metro-tempo mymetro) ; get the tempo of the default metronome: (metro-tempo ) ; you can get a list of all the ids of all the metronomes (metros ) ; if you dont want to include the default metro in the list? (metros #t) ; the default will always be the first in the list so you could also ; do (rest (metros )) ; you can delete a metronome when you are done with it (delete-metro mymetro) (metro? mymetro) (metros ) ; ;; Using Metronomes With Processes? ; ; let's first create a process of running sixteenths, i.e. ?it waits ; one-quarter of a beat after playing each note: (define (dvorak ) ? (process? ? ? with mel = (key '(a4 bf4 a4 g4 f4 e4 d4 bf2 d3 f4 e4 f4 d4 g2 d3? ? ? ? ? ? ? ? ? ? ? ? f4 e4 d4 e4 a2 e4 f4 e4 f4 d4 d3 a3 d4 f4 g4)) ? ? with pat = (make-cycle (concat mel mel (plus 12 mel) (plus 12 mel)))? ? ? with dur ? ? for k = (next pat) ? ? do ? ? (set! dur (if (< k 62) 1 1/4)) ? ? (send "mp:midi" :key k :dur dur) ? ? (wait 1/4))) ? ?? ; sprout the process to start it playing (sprout (dvorak)) ; the 'metro' function adjusts the tempo of a metronome in real-time: ; metro(tempo,time,metro) the frist arg is the new bpm value for the ; metromome, the second arg is the number of seconds for the metronome ; to move from its current tempo to the new tempo. ?the optional third ; arg is the metronome to use, and defaults to the default metronome. ; lets move the reich process from bpm 60 to bpm 90 over 3 seconds: (metro 90 3) ; now move to bpm 400 in 6 seconds (metro 400 6) ; move back to 60 immediately (metro 60 0) ; if a time is not specified, the default is to move the tempo in 0 ; seconds. the following will move to bpm 40 immediately. you can ; also specify seconds with the keyword secs: (metro 40) (metro 40 :secs 0) ; you can also specify moving to a new tempo over a certain number ; of beats. that is, a linear tempo change will occur such that 10 ; beats later we will arrive at the new tempo. (metro 90 :beats 10) ; one can sprout a process as many times as one likes, and? ; each one will be independent from the others. ?sprout ; piano-phase() again, and even though the speed of the process is ; dictated by the metronome tempo, the processes will not be aligned. ; execute the next line several times (sprout (dvorak )) ; setting the tempo will still affect all running processes (metro 10 :secs 4) (metro 90) ; stop all processes (stop ) ; ;; Syncing Processes With Metronomes ; ; when a process is sprouted, it begins playing at the moment sprout() ; is evaluated. however, this will likely be at some fraction of the ; beat. the same happens when we ask for the current beat. the ; liklihood that we will get a round, integer number is slim. Try it: (metro-beat ) ; You got something like 888.74775660822. That would mean that you ; were presently at the 888th beat, and almost 3/4's of the way? ; through it. if you had sprouted a process then, it would ; have started at that point. ; in order to ensure that a process starts on a beat, you need to? ; pass a special function as the ahead value to the sprout. recall ; that sprout has an ahead parameter, which delays the sprouting of ; the process until the indicated time elapses. ; first, let's make a new process (define (downbeats ) ? (process ? ? with Cm = (make-heap '(c4 ef4 g4)) ? ? with chrom = (make-heap '(cs4 d4 e4 f4 fs4 gs4 a4 as4 b4) :for 1) ? ? with pat = (make-cycle (list Cm chrom)) ? ? with dur ? ? for k = (key (next pat)) ? ? do ? ? (if (odds .1) ? ? ? (begin (set! dur 3) ? ? ? ? ? ? ?(send "mp:midi" :key (- k 12) :dur dur)) ? ? ? (begin (set! dur 1) ? ? ? ? ? ? ?(send "mp:midi" :key (+ k (pick 0 12)) :dur dur))) ? ? (wait dur))) ; now let's sprout our new process 2 beats in the future. ; however, it you execute the below at beat 232.7, then the process ; will start at 234.7! ? (sprout (downbeats) 2) (stop ) ; to ensure that the process starts on a downbeat, pass in sync() ; as your ahead value. This way the process will start on a round ; beat number, such as 235.0. (sprout (downbeats ) (sync )) ; sprout it again, and you will see that both processes are aligned ; with the downbeat. (sprout (downbeats ) (sync )) ; sync() itself can take an ahead argument. ?The default value is 1, ; which means the process will start at the NEXT downbeat. ?The above ; sprouts are equivalent to: (sprout (downbeats ) (sync 1)) ; if you give sync() a value of .5, it will start your process on the ; nearest offbeat. ?If you call sprout() at beat 102.23 for example, ; then your process will start at 102.5. ?Calling sprout() at 102.59 ; with sync(.5) will start your process at 103.5. (sprout (downbeats ) (sync 0.5)) ; give sync() a value of 1.75, and it will wait until the next beat ; arrives, then it will start your process at .75 of that beat. (sprout (downbeats ) (sync 1.75)) ; stop the above processes (stop ) ; now sync them to a different metronome (define mymetro (make-metro 100)) (sprout (downbeats ) (sync :metro mymetro)) (sprout (downbeats ) (sync 1/3 :metro mymetro)) (sprout (downbeats ) (sync 2/3 :metro mymetro)) ; stop all processes. (stop ) ; ;; Accouting For Durations With Metronomes ; ; While attack times for all events remain accurate, even while ; changing tempos, the duration values when sending midi data ; are in absolute seconds, not beats. ; Notice that even though the downbeats() process is waiting to play? ; every beat (at bpm 120), the durations are longer than they should? ; be, because "dur: 1" refers to seconds, not beats. (metro 120) (sprout (downbeats ) (sync )) (stop ) ; here is a new process. notice we have the same problem. ; even though our durations and wait values are the same, the dur: ; is in seconds, while wait is in beats. (define (pathetic ) ? (process? ? ? with mel-pat = (make-cycle? ? ? ? ? ? ? ? ? ? ? (key '(b3 cs4 d cs b3 e4 d b3 d4 cs fs e e e? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? g fs fs fs b3 as as as cs4 b3 b b fs e e e g ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fs fs e d e d cs b2 as fs fs3))) ? ? with rhy-pat = (make-cycle '(.5 .5 1 2 .25 .25 .25 .25 1 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25)) ? ? for k = (next mel-pat) ? ? for d = (next rhy-pat) ? ? do ? ? (send "mp:midi" :key k :dur d) ? ? (wait d))) ; sprout it and notice how long the notes sustain. (sprout (pathetic ) (sync )) (stop ) ; To correct for this we will use metro-dur() when indicating ; the durations of midi notes. (define* (pathetic (m *metro*) ) ? (process? ? ? with mel-pat = (make-cycle? ? ? ? ? ? ? ? ? ? ? (key '(b3 cs4 d cs b3 e4 d b3 d4 cs fs e e e? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? g fs fs fs b3 as as as cs4 b3 b b fs e e e g ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fs fs e d e d cs b2 as fs fs3))) ? ? with rhy-pat = (make-cycle '(.5 .5 1 2 .25 .25 .25 .25 1 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25)) ? ? for k = (next mel-pat) ? ? for d = (next rhy-pat) ? ? ;for m = (make-metro m) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 0.5 m)) ? ? (wait d))) ; now try sprouting it. Notice this corrects the issue. (sprout (pathetic ) (sync )) ; Even if we make the tempo faster, the durations will become shorter ; to accomodate the tempo. (metro 200) ; or longer durations at a slower tempo (metro 20 4) ; metro-dur() simply returns the amount of time in seconds that it will ; take for a beat amount under the current metronome. at bpm = 20, ; one beat should take 3 seconds. (metro-dur 1) ; of course, you can pass in a custom metronome (metro-dur 1 mymetro) (stop ) ; the same adjustments must be made if you take advantage of the ; "time" ahead parameter when sending a midi event. ?Recall . . . ; this will trigger a midi event immediately. (send "mp:midi" :key 60) ; and this will trigger it 1 second from now (send "mp:midi" :time 1 :key 60) ; Thus, if you use the "time" midi parameter inside of a process, ; it will only work as expected if your metronome is at bpm = 60. ; This is because this is the tempo at which 1 beat is equal to 1 ; second, and "time" (for mp:midi) is in seconds, not beats. ; here is a process that uses the "time" argument. Define it below. (define (time-user ) ? (process? ? ? with pat = (make-cycle '(2 1 .5 .25 .25)) ? ? for rhy = (next pat) ? ? for off = (pick '(.25 .5 .75)) ? ? do ? ? (send "mp:midi" :key (- 60 24) :dur rhy) ? ? (send "mp:midi" :key (- (pick '(67 68 70 72)) 12) :dur rhy) ? ? (send "mp:midi" :time off :key 63 :dur 1) ? ? (send "mp:midi" :time off :key (pick '(67 68 70 72)) :dur 1) ? ? (wait rhy))) ; first set the tempo to bpm = 60, then sprout it. ?It should sound ; as expected. (metro 60) (sprout (time-user ) (sync )) ; however, if we change the tempo to bpm = 90, the rhythm sounds off. ; This is because of the issue described above. (metro 90) ; set the tempo back to 60 (metro 60) (stop ) ; let's redefine our process to use metro-dur() and fix this (define* (time-user (m *metro*)) ? (process? ? ? with pat = (make-cycle '(2 1 .5 .25 .25)) ? ? for rhy = (next pat) ? ? for off = (pick '(.25 .5 .75)) ? ? do ? ? (send "mp:midi" :key (- 60 24) :dur (metro-dur rhy m)) ? ? (send "mp:midi" :key (- (pick '(67 68 70 72)) 12) :dur (metro-dur rhy m)) ? ? (send "mp:midi" :time off :key 63 :dur (metro-dur 1)) ? ? (send "mp:midi" :time off :key (pick '(67 68 70 72)) :dur (metro-dur 1)) ? ? (wait rhy))) ; try sprouting now (sprout (time-user ) (sync )) ; and change the tempo (metro 90) (metro 40 5) (stop ) ; ;; Using Multiple Metronomes ; ; let's use two different processes while using two different metros ; we'll redefine our dvorak() process with a few slight adjustments, ; including the use of metro-dur() (define* (dvorak (m *metro*)) ? (process? ? ? with mel = (plus (key '(a4 bf4 a4 g4 f4 e4 d4 bf2 d3 f4 e4 f4 d4 g2 d3? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?f4 e4 d4 e4 a2 e4 f4 e4 f4 d4 d3 a3 d4 f4 g4)) 9) ? ? with pat = (make-cycle (concat mel mel (plus 12 mel) (plus 12 mel)))? ? ? with dur ? ? for k = (next pat) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 1/4 m)) ? ? (wait 1/4))) ; Check that we already have a custom metronome existing (metro? mymetro) ; or (metros ) ; set the default metro and sprout our pathetic() process (metro 80) (sprout (pathetic ) (sync )) ; now, set mymetro to the same tempo (metro 80 :metro mymetro) ; sprout our dvorak() process using this metronome (sprout (dvorak mymetro) (sync :metro mymetro)) ; notice that the two metronomes are not aligned. ?We created them at ; different times, and set their tempos at different times, so we ; can't expect them to be in sync. ; we can SYNC these two metronomes by calling metro-sync(). (metro-sync mymetro) ; metro-sync() takes a metronome that will be pushed or pulled in order ; to align a beat with another master-metronome. the master-metro is ; by default the global *metro*. ; force the metronomes out of sync for a moment. (metro 20 :metro mymetro) (metro 80 :metro mymetro) ; now we'll sync them again. (metro-sync mymetro 10 :master-metro *metro*) ; above, you can see how I indicated the master-metro. if you want to ; sync to a metro other than the global, this is how you indicate it. ; the second number (10) means that the two metronomes will complete ; the sync 10 beats later (10 beats according to the master-metro). ; ;; Change Tempo while maintaining alignment ; ; Notice that changing the tempo normally will cause the ; metronome to go out of alignment with the other metro. ?See here: . (metro 40 2 :metro mymetro) ; bring the tempo back up (metro 80 2 :metro mymetro) ; If we change the tempo using the "tempo:" keyword in metro-sync(), ; we can prevent the metronomes from going out of alignment. This will ; guarantee that by the time mymetro has reached its goal tempo, its ; beats will still align with the master metronome. this slowdown will ; take place over 5 beats (metro-sync mymetro 5 :tempo 40 :master-metro *metro*) ; now we can speed up mymetro back to normal tempo and still ; maintain alignment with the other metro. This speed up take ; place over 2 beats. (metro-sync mymetro 2 :tempo 80) ; note that if we want to alter the global metronome, we should ; indicate what the master metronome will be. ?If we do NOT indicate ; the master metronome, metro-sync() will automatically choose the ; first created user metronome as master. While this may seem strange, ; if we only have two metronomes (the user metronome, and the global), ; then it will correctly choose the only existing user metro. ; notice: (metro-sync *metro* :tempo 40) ; Note that the transistion time for the above tempo change and sync ; was over the course of 1 beat. ?1 is the default value if none is ; specified. ; But to be clear, you will probably want to explicitly indicate ; the master-metro if *metro* is the one to be altered. (metro-sync *metro* :tempo 80 :master-metro mymetro) ; beats can be indicated by keyword (metro-sync *metro* :beats 4 :tempo 40) ; one can indicate seconds instead, if desired (metro-sync *metro* :secs 2 :tempo 80) ; metro-sync makes no presumption that the tempos of the two ; metronomes are equal, or are related by being twice as fast or slow. ; The tempos can be completely unrelated. ?all that this function ; ensures is that after a certain number of beats, there will be ; a coinciding beat between the two metros. ? ; for example, we know that the global metro is at bpm = 80. ?if ; we set mymetro to bpm = 80 / 3, and sync them over 1 beat, then ; 1 beat later BOTH metros will align AT LEAST for that beat, then ; they will continue on with their respective tempos. (metro-sync mymetro :tempo (/ 80 3)) ; but of course, once these metros align, they are in a 1 to 3 ; relationship. ?Let's try another tempo ratio: (metro-sync mymetro :tempo (* 80 2/3)) (stop ) ; Note that metro-sync(), as well as metro-phase() explained below, ; both return #t when evaluated, as displayed in your console ; window. Both functions will return #f if they have decided ; to do nothing. This will happen if you try to execute phases ; or syncs rapidly in succession. trying to sync two metronomes ; before a previous sync was completed will result in no action ; being taken, and #f being returned by the function. ; #f will also be return by metro-sync() if the metronomes are ; already in sync and no adjustment is necessary. ; ;; Playing Reich's Piano Phase Manually ; ; let's define Reich's piano-phase to take advantage of metro-dur(). ; we'll also pass in the metronome we're using as an argument ; so that metro-dur() is using the correct metronome (define* (piano-phase (m *metro*)) ;(&optkey m = *metro*) ? (process? ? ? with pat = (make-cycle '(e4 fs4 b4 cs5 d5 fs4 e4 cs5 b4 fs4 d5 cs5)) ? ? for k = (key (next pat)) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 1/4 m)) ? ? (wait 1/4))) ; first, let's start the processes at the same tempo, and in sync. (metro 100) (metro-sync mymetro :tempo 100) (begin ? (sprout (piano-phase ) (sync )) ? (sprout (piano-phase mymetro) (sync :metro mymetro)))?? ; one can play Reich's piano phase manually by using ; metro-phase(). ?metro-phase() takes two beat values -> the second ; value is the number of beats that would normally occur. this is the ; space into which you will fit a different number of beats as ; indicated by the first value. ; for example. ?metro-phase(5.25, 5, *metro*), means to take the ; global metronome and over what would normally be the next 5 beats, ; speed up the tempo slightly so that 5.25 beats occur instead. (metro-phase 5.25 5) ; *metro* is the default metronome, as usual. ; Here we cause the metronome to slow down slightly, so that fewer ; beats occur (4.75) in the space of 5 beats. (metro-phase 4.75 5) ; this transition take twice as long, and is more gradual. (metro-phase 10.25 10 mymetro) ; this transition is rather sudden (metro-phase 1.25 1 :metro mymetro) ; of course, you can "phase" by any amount you want (metro-phase 32 30 :metro mymetro) ; remember to watch your console window. if you start a phase that ; will take a long time, and you try to phase before the first phase ; is completed, the console window will display #f -> false. (stop ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: metro.scm Type: application/octet-stream Size: 18563 bytes Desc: not available URL: From aykut_caglayan at yahoo.com Tue Nov 22 15:34:56 2011 From: aykut_caglayan at yahoo.com (Aykut Caglayan) Date: Tue, 22 Nov 2011 15:34:56 -0800 (PST) Subject: [CM] metronomes and live coding [live.scm] In-Reply-To: <1322002918.34917.YahooMailNeo@web45702.mail.sp1.yahoo.com> References: <1322002918.34917.YahooMailNeo@web45702.mail.sp1.yahoo.com> Message-ID: <1322004896.23773.YahooMailNeo@web45703.mail.sp1.yahoo.com> below is the live-coding documentation in S7 Scheme ;;; -*- syntax: Lisp; font-size: 16; theme: "Emacs"; -*- ; ;; Live Coding ?(Halim Beere, halimbeere at gmail.com) ; ; To do live coding, two things are needed. ?(1) Sprouting processes ; on the fly and having them sync with other processes already running. ; To do this, see the Metronomes example file. ; And (2) updating an already running process with new behavior. ; By default, Grace will allow you to sprout a single process as many ; times as you like. ?This is by design. ?Define the following ; process, tick-tock(). (define (tick-tock ) ? (process? ? ? with transp = (between -20 20) ? ? for x from 0 ? ? do ? ? (if (= (mod x 2) 0) ? ? ? (send "mp:midi" :key (+ 72 transp) :dur (metro-dur 0.5)) ? ? ? (send "mp:midi" :key (+ (pick '(84 82 80 79)) transp) :dur (metro-dur 0.5))) ? ? (wait .5))) ; now sprout it several times. ?You'll notice that ; several of them will run simultaneously. (sprout (tick-tock ) (sync )) ; stop all processes (stop ) ; behind the scenes each of these processes actually has a default ; id number. ?The default is 0, and Grace does not limit the ; the number of processes that can exist with id 0. ?This is ONLY ; true of the default id. ; Let's sprout tick-tock() with its own unique id. (sprout (tick-tock ) (sync ) 1) ; Now, if we try to sprout tick-tock() AGAIN with the same id (which ; is given above as the number 1), then the new process will replace ; the old process. ?Evaluate the next line several times. (sprout (tick-tock ) :id 1) (stop ) ; For any id (except the default id of 0), Grace will only allow ONE ; process to exist with that id. ?If you try to sprout another process ; with that same id, the old process will be replaced with the new one. ; This will occur even if the processes have different names. ?The name ; doesn't matter. ?Only the id number. ; For instance, define the below process. (define (hymn ) ? (process? ? ? with subpat = (make-cycle '(2 1.5 1 .5)) ? ? with pat = (make-cycle (list 2 2 1 subpat)) ? ? for rhy = (next pat) ? ? do ? ? (send "mp:midi" :key (+ 63 12) :dur (metro-dur rhy)) ? ? (send "mp:midi" :key 63 :dur (metro-dur rhy)) ? ? (send "mp:midi" :key (- (pick '(67 68 70 72)) 12) :dur (metro-dur rhy)) ? ? (send "mp:midi" :key (+ (pick '(67 68 70 72)) 12) :dur (metro-dur rhy)) ? ? (wait rhy))) ; sprout it with id 1. (sprout (hymn ) (sync ) :id 1) ; sprout tick-tock with id 1. (sprout (tick-tock ) (sync ) :id 1) ; Go back and forth above, and notice that each process will wait until ; the other is finished before replacing it. The replace happens ; in time, in other words. ; Sprout with a different id. ?Choose one below (sprout (hymn ) (sync ) :id 2) (sprout (tick-tock ) (sync ) :id 2) ; Now you have two processes running, each with a different id. ; You can selectively stop a process by indicating its id, and stop ; will not touch the other running processes. (stop 1) (stop 2) ; Try this again, but first let's sprout using three custom ids, then? ; a few using the default id. (sprout (tick-tock ) (sync ) :id 1) (sprout (tick-tock ) (sync ) :id 2) (sprout (tick-tock ) (sync ) :id 3) (sprout (tick-tock ) (sync )) (sprout (tick-tock ) (sync )) ; Like above, we can stop just the process with id = 1. (stop 1) ; But we can also stop ONLY the processes that have default ids. ; Recall that the default id is 0, so we call: (stop 0) ; Now only processes id = 2 and id = 3 are running. ; Calling stop() with no arguments will stop all running processes, ; regardless of their ids. (stop ) ; note that ids can also be strings, if desired. ?note that strings ; are converted to numbers behind the scenes, so there is a slight ; chance that a custom numbered id you choose could conflict with ; the id of a string once converted to a number. For example, ; an id of "bass" will become id number 3016415. (string-hash "bass") ; Of course, it is unlikely that you will choose 3016415 as your id, ; but if you ever have strange behavior when using ids, you may ; want to check to see if your string ids are conflicting with your ; numbered ids. ; both sprout and stop can handle strings. (sprout (tick-tock ) :id "soprano") ; replace it (sprout (tick-tock ) :id "soprano") ; stop it (stop "soprano") ; strings are supported to help ids be more memorable and descriptive. ; this may help reduce confusion while live coding! (sprout (hymn ) :id "hymn") (stop "hymn") ; Of course, one of the main reasons to do this is to allow a user ; to update an existing process with new behavior. ?Let's do exactly ; that. ; Define the process again, slightly different from above. (define (tick-tock ) ? (process? ? ? for x from 0 ? ? do ? ? (if (= (mod x 2) 0) ? ? ? (send "mp:midi" :key 72 :dur (metro-dur .5)) ? ? ? (send "mp:midi" :key (pick '(84 82 80 79)) :dur (metro-dur 0.5))) ? ? (wait .5))) ; sprout it. (sprout (tick-tock ) (sync ) :id "tick") ; We could simply alter the code above and re-define the process, but ; the code is duplicated and altered below for illustration purposes. ; Notice that we changed the rhythm of the process. (define (tick-tock ) ? (process ? ? with rhy-pat = (make-cycle '(.5 .25 .25)) ? ? for x from 0 ? ? for dur = (next rhy-pat) ? ? do? ? ? (if (= (mod x 2) 0) ? ? ? (send "mp:midi" :key 72 :dur (metro-dur dur)) ? ? ? (send "mp:midi" :key (pick '(84 82 80 79)) :dur (metro-dur dur))) ? ? (wait dur))) ; Now that we have redefined our process, let's sprout it again with ; the same id -> "tick" (sprout (tick-tock ) :id "tick") ; And one more time, let's alter the process and re-sprout it. (define (tick-tock ) ? (process? ? ? with rhy-pat = (make-cycle '(.25 .25 .125 .125 .125 .125)) ? ? with root = 72 ? ? for x from 0 ? ? for dur = (next rhy-pat) ? ? do? ? ? (if (= (mod x 10) 0) ? ? ? (set! root (+ (pick '(72 75 79)) (pick '(-24 -12 0)))) ? ? ? (set! dur (pick '(.25 .5)))) ? ? (if (= (mod x 2) 0) ? ? ? (send "mp:midi" :key root :dur (* (metro-dur dur) 2)) ? ? ? (send "mp:midi" :key (+ (pick '(84 82 80 79)) (pick '(-24 -12 0))) :dur (metro-dur dur))) ? ? (wait dur))) (sprout (tick-tock ) (sync ) :id "tick") ; sprout another version on top with a new id, using to the metronome ; to keep it in sync (sprout (tick-tock ) (sync ) :id "tock") ; lastly, sprout our old hymn() process with a default id. (sprout (hymn ) (sync )) ; stop the first process (stop "tick") ; stop the second process (stop "tock") ; stop the default process (stop 0) ? -- Aykut Caglayan (PhD) http://aykutcaglayan.blogspot.com/ ________________________________ From: Aykut Caglayan To: "cmdist at ccrma.Stanford.EDU" Cc: "halimbeere at gmail.com" Sent: Wednesday, November 23, 2011 1:01 AM Subject: Re: metronomes and live coding Many thanks to Halim for his effort in making it possible to use CommonMusic as a live-coding language. While I was reading the metro.sal documantation, I transcribed it into the S7 Scheme.? I have pasted the whole document below. PS: i may read/transcribe the livecoding doc in a few days too. -- Aykut Caglayan (PhD) http://aykutcaglayan.blogspot.com/ ;;; -*- syntax: Lisp; font-size: 18; theme: "Emacs"; -*- ; ;; Metronomes ?(Halim Beere, halimbeere at gmail.com) ; ; Metronomes are objects that allow you to change the tempo of running ; processes in real-time. at least one metronome is always active, ; even if you do not specify a metronome the 'default metronome' will ; be in use. ?to access a metronome you use its 'id', the metronom id ; of the default metronome is always 0: ; current beat time of the default metro (metro-beat 0) ; most metronome functions take an optional 'metro' arg that lets you ; specify which metronome should be use. if you don't specify this ; value explicitly you will get whatever metronome is in th global ; varible *metro*. This variable is intiaily set to 0 (the default ; metronome) but you can reset it to any metronome that you create. ; if no metro is specified the metronome in *metro* will be used: (metro-beat ) ; use 'make-metro' to create a new metronome with some initial ; starting tempo. make-metro returns the new metronome's id as its ; value that you save in a variable for referenceing that metro (define mymetro (make-metro 100)) ; you can ask if there is a metro with a given id: (metro? mymetro) (metro? 0) ; you can get the current tempo and beat value of your metronome (metro-tempo mymetro) ; get the tempo of the default metronome: (metro-tempo ) ; you can get a list of all the ids of all the metronomes (metros ) ; if you dont want to include the default metro in the list? (metros #t) ; the default will always be the first in the list so you could also ; do (rest (metros )) ; you can delete a metronome when you are done with it (delete-metro mymetro) (metro? mymetro) (metros ) ; ;; Using Metronomes With Processes? ; ; let's first create a process of running sixteenths, i.e. ?it waits ; one-quarter of a beat after playing each note: (define (dvorak ) ? (process? ? ? with mel = (key '(a4 bf4 a4 g4 f4 e4 d4 bf2 d3 f4 e4 f4 d4 g2 d3? ? ? ? ? ? ? ? ? ? ? ? f4 e4 d4 e4 a2 e4 f4 e4 f4 d4 d3 a3 d4 f4 g4)) ? ? with pat = (make-cycle (concat mel mel (plus 12 mel) (plus 12 mel)))? ? ? with dur ? ? for k = (next pat) ? ? do ? ? (set! dur (if (< k 62) 1 1/4)) ? ? (send "mp:midi" :key k :dur dur) ? ? (wait 1/4))) ? ?? ; sprout the process to start it playing (sprout (dvorak)) ; the 'metro' function adjusts the tempo of a metronome in real-time: ; metro(tempo,time,metro) the frist arg is the new bpm value for the ; metromome, the second arg is the number of seconds for the metronome ; to move from its current tempo to the new tempo. ?the optional third ; arg is the metronome to use, and defaults to the default metronome. ; lets move the reich process from bpm 60 to bpm 90 over 3 seconds: (metro 90 3) ; now move to bpm 400 in 6 seconds (metro 400 6) ; move back to 60 immediately (metro 60 0) ; if a time is not specified, the default is to move the tempo in 0 ; seconds. the following will move to bpm 40 immediately. you can ; also specify seconds with the keyword secs: (metro 40) (metro 40 :secs 0) ; you can also specify moving to a new tempo over a certain number ; of beats. that is, a linear tempo change will occur such that 10 ; beats later we will arrive at the new tempo. (metro 90 :beats 10) ; one can sprout a process as many times as one likes, and? ; each one will be independent from the others. ?sprout ; piano-phase() again, and even though the speed of the process is ; dictated by the metronome tempo, the processes will not be aligned. ; execute the next line several times (sprout (dvorak )) ; setting the tempo will still affect all running processes (metro 10 :secs 4) (metro 90) ; stop all processes (stop ) ; ;; Syncing Processes With Metronomes ; ; when a process is sprouted, it begins playing at the moment sprout() ; is evaluated. however, this will likely be at some fraction of the ; beat. the same happens when we ask for the current beat. the ; liklihood that we will get a round, integer number is slim. Try it: (metro-beat ) ; You got something like 888.74775660822. That would mean that you ; were presently at the 888th beat, and almost 3/4's of the way? ; through it. if you had sprouted a process then, it would ; have started at that point. ; in order to ensure that a process starts on a beat, you need to? ; pass a special function as the ahead value to the sprout. recall ; that sprout has an ahead parameter, which delays the sprouting of ; the process until the indicated time elapses. ; first, let's make a new process (define (downbeats ) ? (process ? ? with Cm = (make-heap '(c4 ef4 g4)) ? ? with chrom = (make-heap '(cs4 d4 e4 f4 fs4 gs4 a4 as4 b4) :for 1) ? ? with pat = (make-cycle (list Cm chrom)) ? ? with dur ? ? for k = (key (next pat)) ? ? do ? ? (if (odds .1) ? ? ? (begin (set! dur 3) ? ? ? ? ? ? ?(send "mp:midi" :key (- k 12) :dur dur)) ? ? ? (begin (set! dur 1) ? ? ? ? ? ? ?(send "mp:midi" :key (+ k (pick 0 12)) :dur dur))) ? ? (wait dur))) ; now let's sprout our new process 2 beats in the future. ; however, it you execute the below at beat 232.7, then the process ; will start at 234.7! ? (sprout (downbeats) 2) (stop ) ; to ensure that the process starts on a downbeat, pass in sync() ; as your ahead value. This way the process will start on a round ; beat number, such as 235.0. (sprout (downbeats ) (sync )) ; sprout it again, and you will see that both processes are aligned ; with the downbeat. (sprout (downbeats ) (sync )) ; sync() itself can take an ahead argument. ?The default value is 1, ; which means the process will start at the NEXT downbeat. ?The above ; sprouts are equivalent to: (sprout (downbeats ) (sync 1)) ; if you give sync() a value of .5, it will start your process on the ; nearest offbeat. ?If you call sprout() at beat 102.23 for example, ; then your process will start at 102.5. ?Calling sprout() at 102.59 ; with sync(.5) will start your process at 103.5. (sprout (downbeats ) (sync 0.5)) ; give sync() a value of 1.75, and it will wait until the next beat ; arrives, then it will start your process at .75 of that beat. (sprout (downbeats ) (sync 1.75)) ; stop the above processes (stop ) ; now sync them to a different metronome (define mymetro (make-metro 100)) (sprout (downbeats ) (sync :metro mymetro)) (sprout (downbeats ) (sync 1/3 :metro mymetro)) (sprout (downbeats ) (sync 2/3 :metro mymetro)) ; stop all processes. (stop ) ; ;; Accouting For Durations With Metronomes ; ; While attack times for all events remain accurate, even while ; changing tempos, the duration values when sending midi data ; are in absolute seconds, not beats. ; Notice that even though the downbeats() process is waiting to play? ; every beat (at bpm 120), the durations are longer than they should? ; be, because "dur: 1" refers to seconds, not beats. (metro 120) (sprout (downbeats ) (sync )) (stop ) ; here is a new process. notice we have the same problem. ; even though our durations and wait values are the same, the dur: ; is in seconds, while wait is in beats. (define (pathetic ) ? (process? ? ? with mel-pat = (make-cycle? ? ? ? ? ? ? ? ? ? ? (key '(b3 cs4 d cs b3 e4 d b3 d4 cs fs e e e? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? g fs fs fs b3 as as as cs4 b3 b b fs e e e g ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fs fs e d e d cs b2 as fs fs3))) ? ? with rhy-pat = (make-cycle '(.5 .5 1 2 .25 .25 .25 .25 1 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25)) ? ? for k = (next mel-pat) ? ? for d = (next rhy-pat) ? ? do ? ? (send "mp:midi" :key k :dur d) ? ? (wait d))) ; sprout it and notice how long the notes sustain. (sprout (pathetic ) (sync )) (stop ) ; To correct for this we will use metro-dur() when indicating ; the durations of midi notes. (define* (pathetic (m *metro*) ) ? (process? ? ? with mel-pat = (make-cycle? ? ? ? ? ? ? ? ? ? ? (key '(b3 cs4 d cs b3 e4 d b3 d4 cs fs e e e? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? g fs fs fs b3 as as as cs4 b3 b b fs e e e g ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fs fs e d e d cs b2 as fs fs3))) ? ? with rhy-pat = (make-cycle '(.5 .5 1 2 .25 .25 .25 .25 1 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .25 .25 .25 .25 .25 .25 .25 .25)) ? ? for k = (next mel-pat) ? ? for d = (next rhy-pat) ? ? ;for m = (make-metro m) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 0.5 m)) ? ? (wait d))) ; now try sprouting it. Notice this corrects the issue. (sprout (pathetic ) (sync )) ; Even if we make the tempo faster, the durations will become shorter ; to accomodate the tempo. (metro 200) ; or longer durations at a slower tempo (metro 20 4) ; metro-dur() simply returns the amount of time in seconds that it will ; take for a beat amount under the current metronome. at bpm = 20, ; one beat should take 3 seconds. (metro-dur 1) ; of course, you can pass in a custom metronome (metro-dur 1 mymetro) (stop ) ; the same adjustments must be made if you take advantage of the ; "time" ahead parameter when sending a midi event. ?Recall . . . ; this will trigger a midi event immediately. (send "mp:midi" :key 60) ; and this will trigger it 1 second from now (send "mp:midi" :time 1 :key 60) ; Thus, if you use the "time" midi parameter inside of a process, ; it will only work as expected if your metronome is at bpm = 60. ; This is because this is the tempo at which 1 beat is equal to 1 ; second, and "time" (for mp:midi) is in seconds, not beats. ; here is a process that uses the "time" argument. Define it below. (define (time-user ) ? (process? ? ? with pat = (make-cycle '(2 1 .5 .25 .25)) ? ? for rhy = (next pat) ? ? for off = (pick '(.25 .5 .75)) ? ? do ? ? (send "mp:midi" :key (- 60 24) :dur rhy) ? ? (send "mp:midi" :key (- (pick '(67 68 70 72)) 12) :dur rhy) ? ? (send "mp:midi" :time off :key 63 :dur 1) ? ? (send "mp:midi" :time off :key (pick '(67 68 70 72)) :dur 1) ? ? (wait rhy))) ; first set the tempo to bpm = 60, then sprout it. ?It should sound ; as expected. (metro 60) (sprout (time-user ) (sync )) ; however, if we change the tempo to bpm = 90, the rhythm sounds off. ; This is because of the issue described above. (metro 90) ; set the tempo back to 60 (metro 60) (stop ) ; let's redefine our process to use metro-dur() and fix this (define* (time-user (m *metro*)) ? (process? ? ? with pat = (make-cycle '(2 1 .5 .25 .25)) ? ? for rhy = (next pat) ? ? for off = (pick '(.25 .5 .75)) ? ? do ? ? (send "mp:midi" :key (- 60 24) :dur (metro-dur rhy m)) ? ? (send "mp:midi" :key (- (pick '(67 68 70 72)) 12) :dur (metro-dur rhy m)) ? ? (send "mp:midi" :time off :key 63 :dur (metro-dur 1)) ? ? (send "mp:midi" :time off :key (pick '(67 68 70 72)) :dur (metro-dur 1)) ? ? (wait rhy))) ; try sprouting now (sprout (time-user ) (sync )) ; and change the tempo (metro 90) (metro 40 5) (stop ) ; ;; Using Multiple Metronomes ; ; let's use two different processes while using two different metros ; we'll redefine our dvorak() process with a few slight adjustments, ; including the use of metro-dur() (define* (dvorak (m *metro*)) ? (process? ? ? with mel = (plus (key '(a4 bf4 a4 g4 f4 e4 d4 bf2 d3 f4 e4 f4 d4 g2 d3? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?f4 e4 d4 e4 a2 e4 f4 e4 f4 d4 d3 a3 d4 f4 g4)) 9) ? ? with pat = (make-cycle (concat mel mel (plus 12 mel) (plus 12 mel)))? ? ? with dur ? ? for k = (next pat) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 1/4 m)) ? ? (wait 1/4))) ; Check that we already have a custom metronome existing (metro? mymetro) ; or (metros ) ; set the default metro and sprout our pathetic() process (metro 80) (sprout (pathetic ) (sync )) ; now, set mymetro to the same tempo (metro 80 :metro mymetro) ; sprout our dvorak() process using this metronome (sprout (dvorak mymetro) (sync :metro mymetro)) ; notice that the two metronomes are not aligned. ?We created them at ; different times, and set their tempos at different times, so we ; can't expect them to be in sync. ; we can SYNC these two metronomes by calling metro-sync(). (metro-sync mymetro) ; metro-sync() takes a metronome that will be pushed or pulled in order ; to align a beat with another master-metronome. the master-metro is ; by default the global *metro*. ; force the metronomes out of sync for a moment. (metro 20 :metro mymetro) (metro 80 :metro mymetro) ; now we'll sync them again. (metro-sync mymetro 10 :master-metro *metro*) ; above, you can see how I indicated the master-metro. if you want to ; sync to a metro other than the global, this is how you indicate it. ; the second number (10) means that the two metronomes will complete ; the sync 10 beats later (10 beats according to the master-metro). ; ;; Change Tempo while maintaining alignment ; ; Notice that changing the tempo normally will cause the ; metronome to go out of alignment with the other metro. ?See here: . (metro 40 2 :metro mymetro) ; bring the tempo back up (metro 80 2 :metro mymetro) ; If we change the tempo using the "tempo:" keyword in metro-sync(), ; we can prevent the metronomes from going out of alignment. This will ; guarantee that by the time mymetro has reached its goal tempo, its ; beats will still align with the master metronome. this slowdown will ; take place over 5 beats (metro-sync mymetro 5 :tempo 40 :master-metro *metro*) ; now we can speed up mymetro back to normal tempo and still ; maintain alignment with the other metro. This speed up take ; place over 2 beats. (metro-sync mymetro 2 :tempo 80) ; note that if we want to alter the global metronome, we should ; indicate what the master metronome will be. ?If we do NOT indicate ; the master metronome, metro-sync() will automatically choose the ; first created user metronome as master. While this may seem strange, ; if we only have two metronomes (the user metronome, and the global), ; then it will correctly choose the only existing user metro. ; notice: (metro-sync *metro* :tempo 40) ; Note that the transistion time for the above tempo change and sync ; was over the course of 1 beat. ?1 is the default value if none is ; specified. ; But to be clear, you will probably want to explicitly indicate ; the master-metro if *metro* is the one to be altered. (metro-sync *metro* :tempo 80 :master-metro mymetro) ; beats can be indicated by keyword (metro-sync *metro* :beats 4 :tempo 40) ; one can indicate seconds instead, if desired (metro-sync *metro* :secs 2 :tempo 80) ; metro-sync makes no presumption that the tempos of the two ; metronomes are equal, or are related by being twice as fast or slow. ; The tempos can be completely unrelated. ?all that this function ; ensures is that after a certain number of beats, there will be ; a coinciding beat between the two metros. ? ; for example, we know that the global metro is at bpm = 80. ?if ; we set mymetro to bpm = 80 / 3, and sync them over 1 beat, then ; 1 beat later BOTH metros will align AT LEAST for that beat, then ; they will continue on with their respective tempos. (metro-sync mymetro :tempo (/ 80 3)) ; but of course, once these metros align, they are in a 1 to 3 ; relationship. ?Let's try another tempo ratio: (metro-sync mymetro :tempo (* 80 2/3)) (stop ) ; Note that metro-sync(), as well as metro-phase() explained below, ; both return #t when evaluated, as displayed in your console ; window. Both functions will return #f if they have decided ; to do nothing. This will happen if you try to execute phases ; or syncs rapidly in succession. trying to sync two metronomes ; before a previous sync was completed will result in no action ; being taken, and #f being returned by the function. ; #f will also be return by metro-sync() if the metronomes are ; already in sync and no adjustment is necessary. ; ;; Playing Reich's Piano Phase Manually ; ; let's define Reich's piano-phase to take advantage of metro-dur(). ; we'll also pass in the metronome we're using as an argument ; so that metro-dur() is using the correct metronome (define* (piano-phase (m *metro*)) ;(&optkey m = *metro*) ? (process? ? ? with pat = (make-cycle '(e4 fs4 b4 cs5 d5 fs4 e4 cs5 b4 fs4 d5 cs5)) ? ? for k = (key (next pat)) ? ? do ? ? (send "mp:midi" :key k :dur (metro-dur 1/4 m)) ? ? (wait 1/4))) ; first, let's start the processes at the same tempo, and in sync. (metro 100) (metro-sync mymetro :tempo 100) (begin ? (sprout (piano-phase ) (sync )) ? (sprout (piano-phase mymetro) (sync :metro mymetro)))?? ; one can play Reich's piano phase manually by using ; metro-phase(). ?metro-phase() takes two beat values -> the second ; value is the number of beats that would normally occur. this is the ; space into which you will fit a different number of beats as ; indicated by the first value. ; for example. ?metro-phase(5.25, 5, *metro*), means to take the ; global metronome and over what would normally be the next 5 beats, ; speed up the tempo slightly so that 5.25 beats occur instead. (metro-phase 5.25 5) ; *metro* is the default metronome, as usual. ; Here we cause the metronome to slow down slightly, so that fewer ; beats occur (4.75) in the space of 5 beats. (metro-phase 4.75 5) ; this transition take twice as long, and is more gradual. (metro-phase 10.25 10 mymetro) ; this transition is rather sudden (metro-phase 1.25 1 :metro mymetro) ; of course, you can "phase" by any amount you want (metro-phase 32 30 :metro mymetro) ; remember to watch your console window. if you start a phase that ; will take a long time, and you try to phase before the first phase ; is completed, the console window will display #f -> false. (stop ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live.scm Type: application/octet-stream Size: 6687 bytes Desc: not available URL: From taube at illinois.edu Tue Nov 22 16:20:33 2011 From: taube at illinois.edu (Heinrich Taube) Date: Tue, 22 Nov 2011 18:20:33 -0600 Subject: [CM] metronomes and live coding In-Reply-To: <121BF59B-4593-4C8D-B7A7-5E1BC15EA6A0@yahoo.fr> References: <121BF59B-4593-4C8D-B7A7-5E1BC15EA6A0@yahoo.fr> Message-ID: <40A6388A-F935-4C77-B085-5E864339B89B@illinois.edu> dont thank me thank halim! ;) On Nov 22, 2011, at 4:05 PM, stephane boussuge wrote: > Absolutely fantastic, great !! > > Thanks !! > > stf > From taube at illinois.edu Tue Nov 22 16:22:23 2011 From: taube at illinois.edu (Heinrich Taube) Date: Tue, 22 Nov 2011 18:22:23 -0600 Subject: [CM] metronomes and live coding In-Reply-To: <1322002918.34917.YahooMailNeo@web45702.mail.sp1.yahoo.com> References: <1322002918.34917.YahooMailNeo@web45702.mail.sp1.yahoo.com> Message-ID: <02271847-8D41-40BB-9C10-AC914539EE4B@illinois.edu> great thanks aykut! it'll add both to the next app i save, probably in a day or two. best, rick On Nov 22, 2011, at 5:01 PM, Aykut Caglayan wrote: > Many thanks to Halim for his effort in making it possible to use > CommonMusic as a live-coding language. From taube at illinois.edu Wed Nov 23 05:07:33 2011 From: taube at illinois.edu (Heinrich Taube) Date: Wed, 23 Nov 2011 07:07:33 -0600 Subject: [CM] windows version Message-ID: <82049323-0073-47AC-B4C9-E735B2A21B2D@illinois.edu> ok ive got a windows build working i think: http://camil.music.uiuc.edu/software/grace/Grace-3.8.0-alpha3-win32.zip From taube at illinois.edu Sun Nov 27 04:18:54 2011 From: taube at illinois.edu (Heinrich Taube) Date: Sun, 27 Nov 2011 06:18:54 -0600 Subject: [CM] audio plugins in grace working Message-ID: <25199215-2866-4419-BCCE-B6CA62CC4D21@illinois.edu> apologies for the longish report, if you are interested in generating real-time audio using AU, VST, ASIO plugins in Grace, read on! -- You can now load 'plugin graphs' and send midi/audio streams to them to generate real-time audio output. Plugin graphs are user defined collections of nodes (plugins and other audio processors) with connections that route audio/midi signals between them. To create a plugin graph right now use JUCE's "Audio Plugin Host" app (shipped in its extras/ folder). Plugin Host will find all the plugins on your machine, let you add and connect plugins together to forms graphs, test graphs out using the app's midi keyboard panel, and save plugin graphs as .filtergraph files (XML graph description). To load a plugin graph in Grace type COMMAND-P or use the Audio > Plugin Graphs > Load Plugin Graph... menu item . You can then route midi to it by just closing (unchecking) all midi output ports: if no midi output ports are open then Grace will automatically send whatever midi you generate straight to any plugin graph. To route midi input to a plugin graph, open the input port and select Audio > Midi In > Send To Plugin. In addition, any audio input Grace receives will automatically be routed to the audio inputs of your plugin graph. You can also open any plugin's GUI editor iand tweek its parameters while it is generating audio! To open a gui editor select it from Audio > Plugin Graphs> Plugin Editors menu. This may take a few second to open if its a huge plugin lilke Kontakt ... I will add more features as time goes on, for example being able to add connectins and send plugin parameter data from Scheme. (Im less inclined to provide a gui graph editor because Plugin Host already does this very well) Obviously to use plugins you have to have plugin support working on your machine... Getting it working ranges from easy to impossible. On Mac its easy and ive saved a new alpha built with AU plugin support. I also have a version of Juce's Plugin Host app that you can use to create AU plugin graphs: Mac: Grace with AU support: http://camil.music.uiuc.edu/software/grace/Grace-3.8.0-alpha4-osx.zip Plugin Host with AU support: http://camil.music.uiuc.edu/software/grace/PluginHostAU-osx.zip Plugin graph replacement for SimpleSynth: http://camil.music.uiuc.edu/software/grace/dls.filtergraph All other types of plugins (VST/ASIO ) on Windows, Linux or Mac will require you to enter into an agreement with Steinberg and build "Audio Plugin Host" and Grace from sources . I was able to build the "Audio Plugin Host" with VST on windows. I tried for several days to build it on linux but gave up. ( If you manage to build it and get it to make a sound then please let me know) Assuming you have VST plugins working in the Plugin Host, then to build grace with VST support enabled all you do is add the new --vst option to premake: premake ... --vst /path/to/VST_3 ... From taube at illinois.edu Sun Nov 27 04:22:26 2011 From: taube at illinois.edu (Heinrich Taube) Date: Sun, 27 Nov 2011 06:22:26 -0600 Subject: [CM] how to create a plugin graph in Plugin Host Message-ID: <5C7FAFA6-C07B-4F1D-A15D-5E9D885DF17A@illinois.edu> Here is how to design and save plugin graphs in JUCE's Audi Plugin Host. Its a terrific little app and the gui is very easy to use. 1. Start the "Plugin Host" app 2. Press Command-P (or select "Edit the list of available plugins..." from the Options menu). This will open the "Available Plugins" window. 3. Click on the Options... button at the bottom of that window and select "Scan for new or updated Audio Unit Plugins..." from the menu that pop up. This will search your plugin paths to gather all the plugins it can find. You only have to do this once, or whenever you add new plugins. 4. Add whatever plugins you want to the main graph editor window by selecting them from the Plugins>Create Plugin>submenus. 6. Drag inputs to outputs to establish audio and midi connections between nodes. 7. Use the editor's keyboard pane at the bottom of the window to test your graph out 8. save the graph to a file (*.filtergraph) and quit the app (this'll release the plugins) 9. load that graph into Grace and use it! --rick From jallan378 at gmail.com Tue Nov 29 06:38:42 2011 From: jallan378 at gmail.com (jallan365) Date: Tue, 29 Nov 2011 06:38:42 -0800 (PST) Subject: [CM] Grace and Fomus on F 14 In-Reply-To: References: <99A5BBF4-0E20-4A23-8AE3-BFBAED9299C9@uiuc.edu> <07B939E3-8A51-4C81-8D24-6DA72723A9F7@uiuc.edu> <1300469131.11461.36.camel@fred> <1300477322.11461.91.camel@fred> <66971AAD-DBC1-4CC1-AE74-1F7CC2C0F76D@uiuc.edu> <4D83D2B9.1000507@localhost> <1300496870.11461.163.camel@fred> Message-ID: <32880818.post@talk.nabble.com> I'm pretty stuck on installing Fomus (1.18) with Grace (3.7.3) on os x 10.6.8. using the instructions that Bill gave below - get boost 1.45, untar into /usr/local/src and run ./bootstrap > - ./bjam install --prefix=/usr/local > - (though this puts things in very strange places - the whole boost > build & install process is very opaque to me) > - mv /usr/local/libboost_* lib/ (see above) > - mkdir /usr/local/include/boost > - mv /usr/local/boost/* /usr/local/include/boost > > - then untar fomus 0.1.15 into /usr/local/src > - ./configure --with-boost=/usr/local > - make install > > - make a file called 'local.conf' in /etc/ld.so.conf.d/ containing the > line '/usr/local/lib' > - run ldconfig > > - start Grace and see the new Fomus in its terminal window > - run a fomus example from Help>Examples>Scheme>Fomus and do a > hokeypokey when it works! I've got as far as - run ldconfig but maybe because I'm not using Fedora/Ubuntu I can't find ldconfig or an equivalent? I know that Fomus is installed properly (did fomus -O and the list of info came up) but I'm still getting the same error message >>>> Error: Fomus: can't find FOMUS library >>>> Error: don't know how to open "fomus1.ly" > I'm not sure how I can get round this, frankly I'm pretty much a novice for all things regarding terminal. I'd really appreciate some help, Fomus is exactly what I need to use for my work and I feel like it's really close! Cheers, Jallan Bill Sack-2 wrote: > > o.k. - i got it sorted here using a local boost and fomus and i'll > outline the steps here in case it helps anyone else who doesn't want > to wait for fedora to update boost to 1.45. > > - get boost 1.45, untar into /usr/local/src and run ./bootstrap > - ./bjam install --prefix=/usr/local > - (though this puts things in very strange places - the whole boost > build & install process is very opaque to me) > - mv /usr/local/libboost_* lib/ (see above) > - mkdir /usr/local/include/boost > - mv /usr/local/boost/* /usr/local/include/boost > > - then untar fomus 0.1.15 into /usr/local/src > - ./configure --with-boost=/usr/local > - make install > > - make a file called 'local.conf' in /etc/ld.so.conf.d/ containing the > line '/usr/local/lib' > - run ldconfig > > - start Grace and see the new Fomus in its terminal window > - run a fomus example from Help>Examples>Scheme>Fomus and do a > hokeypokey when it works! > - write some music. > > b > > On Fri, Mar 18, 2011 at 9:07 PM, David Psenicka > wrote: >> I just compiled fomus 0.1.15 with boost 1.44 on Ubuntu and had no >> issues... >> I'll have to install fc14 somewhere and try to compile it in that >> environment to figure out what's going wrong.? I'm almost sure that >> undefined symbol has to do with the API change in boost 1.44.? I'll post >> a >> solution as soon as I figure this out. >> >> BTW the option "--with-boost=/usr/local" on the ./configure command line >> causes it to link with a local install of boost instead of the distro >> version (the boost libs are in /usr/local/lib)--on my machine it compiled >> against the local boost and worked properly (output a lilypond file and >> displayed it).? To run it I also had to export >> "LD_LIBRARY_PATH=/usr/local/lib". >> >> On Fri, 2011-03-18 at 14:46 -0700, Fernando Lopez-Lezcano wrote: >> >> AFAICT Grace does not link with fomus, I imagine it just calls the fomus >> executable? >> >> Grace loads libfomus.so dynamically at run time (the Grace build doesn't >> link with it at compile time)...? So recompiling Grace shouldn't be >> necessary, it should load and use whatever version of fomus is installed >> (and run without it if it can't find it) >> >> -David >> >> >> >> I just built a fomus 0.1.5 package for fc14 and there is an error when >> trying to run a simple example. With this freshly compiled and installed >> fomus I get an error just running /usr/bin/fomus with a single note .fms >> file. The error appears just after it prints "running LilyPond" (it is >> an underfined symbol in /usr/lib/fomus/lilyout.so). >> >> -- Fernando >> >> >>> On Mar 18, 2011, at 2:42 PM, David Psenicka wrote: >>> >>>> I just noticed you're compiling fomus 0.1.12, which is old and >>>> doesn't have the iostreams fix... Have you tried compiling fomus >>>> 0.1.15 with the distro's boost libraries and headers? 0.1.15 has >>>> bug fixes and should work fine with recent versions of Grace (you >>>> shouldn't have to recompile Grace). If you stick with 0.1.12 then >>>> you'll have to have two versions of Boost on your system to run an >>>> old version of the software. >>>> >>>> If you are compiling against a local Boost install, make sure bjam >>>> installed the header files in the right place (it likes to place >>>> them in a directory that looks something like /usr/local/include/ >>>> boost/boost_1_39 and they actually need to be in /usr/local/include/ >>>> boost). The configure script might also be confused if you have two >>>> versions of boost on your system, I have to try and compile against >>>> a local boost install to see what it's trying to do and how to make >>>> it find the right libraries. >>>> >>>> -David >>>> >>>> On Fri, 2011-03-18 at 14:29 -0400, Bill Sack wrote: >>>>> >>>>> i'm trying a local install of boost 1.39 >>>>> did ./bootstrap and ./bjam install >>>>> this is the output of ./configure in fomus >>>>> >>>>> checking for boostlib>= 1.35... yes >>>>> checking whether the Boost::System library is available... yes >>>>> checking for -l... no >>>>> checking whether the Boost::Filesystem library is available... yes >>>>> configure: error: Could not link against ! >>>>> >>>>> am i missing some part of installing boost? or missing a configure >>>>> flag? >>>>> >>>>> On Fri, Mar 18, 2011 at 1:25 PM, David Psenicka >>>>> wrote: >>>>>> The error message has to do with Boost's iostream library which >>>>> changed >>>>>> quite a bit with version 1.44 (including the API, which would >>>>> cause an >>>>>> undefined symbol error if fomus is linking with the wrong library >>>>>> version)... I think recompiling with the correct Boost library >>>>> headers >>>>>> should fix the problem. The recent fomus release should compile >>>>> with Boost >>>>>> versions before or after 1.44 (though I haven't tested 1.46 >>>>> yet). I'll try >>>>>> compiling with boost 1.44 on my machine and see if I run into any >>>>> problems. >>>>>> >>>>>> -David >>>>>> >>>>>> On Fri, 2011-03-18 at 10:18 -0500, Heinrich Taube wrote: >>>>>> >>>>>> sorry its not working for you. i forwarded your message to david >>>>>> psenicka, perhaps he has some idea. >>>>>> fwiw im using boost_1_45_0/ . i know that boost_1_39_0/ also >>>>> worked >>>>>> for me. its probably not that hard to uninstall/reinstall boost it >>>>>> that is actually the issue. >>>>>> >>>>>> >>>>>> On Mar 18, 2011, at 10:04 AM, Bill Sack wrote: >>>>>> >>>>>>> i did try the new beta - everything seems to work great except >>>>> fomus. >>>>>>> i've done a bit more googling and discovered that this is a >>>>>>> longstanding (since 12/10) unresolved problem with fomus and f14 - >>>>>>> there's a message on the planetccrma list about it that i somehow >>>>>>> overlooked when it was current. >>>>>>> >>>>>>> the issue has nothing to do with Grace or cm at all - i get the >>>>> same >>>>>>> error message trying to run one of the fomus examples in the >>>>>>> documentation (i.e.: outside of cm). >>>>>>> >>>>>>> i still suspect that it has something to do with the version of >>>>> boost >>>>>>> but i don't have the patience to downgrade and recompile right >>>>> now. >>>>>>> >>>>>>> b >>>>>>> >>>>>>> On Thu, Mar 17, 2011 at 4:36 PM, Heinrich Taube >>>>>>> wrote: >>>>>>>> i just tested fomus 0.1.15 in all the betas I can (osx win32 and >>>>>>>> ubuntu) >>>>>>>> using the complex "prime harmonics" example at the end of the >>>>>>>> example file >>>>>>>> you get by selecting: >>>>>>>> Help>Examples>Scheme>Fomus >>>>>>>> >>>>>>>> the example ran eveywhere (really fast on osx and ubuntu!), >>>>>>>> although on >>>>>>>> ubuntu i did not get the pdf viewer opening automatically with >>>>> the >>>>>>>> computed >>>>>>>> score. >>>>>>>> >>>>>>>> so im not sure what the issue on your fedora, are you using the >>>>>>>> fedora beta1 >>>>>>>> i made today? >>>>>>>> >>>>>>>> >>>>>>>> On Mar 17, 2011, at 1:08 PM, Bill Sack wrote: >>>>>>>> >>>>>>>>> i built fomus 1.15 here too and got the same crash when trying >>>>> the >>>>>>>>> example. i wonder if this has something to do with the version >>>>> of >>>>>>>>> boost that's packaged for f14? >>>>>>>>> looks like 1.39 on f 12 >>>>>>>>> and 1.44 on f14 >>>>>>>>> >>>>>>>>> maybe i'll try a locally downgraded version of boost and see >>>>> what >>>>>>>>> happens. >>>>>>>>> >>>>>>>>>> do i need to do something about the lock file or not? maybe i >>>>> could >>>>>>>>>> disable >>>>>>>>>> this on linux , but running two version of grace probably >>>>> isnt a >>>>>>>>>> good >>>>>>>>>> idea >>>>>>>>>> as they will both write to the preference file... >>>>>>>>> >>>>>>>>> would it be hard to have a message echoed to the shell if >>>>> there's a >>>>>>>>> permission issue or some other conflict with the lockfile? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mar 17, 2011, at 8:56 AM, Bill Sack wrote: >>>>>>>>>> >>>>>>>>>>> hello again, >>>>>>>>>>> i'm trying to get Fomus going with Grace on fedora 14. i've >>>>>>>>>>> tried the >>>>>>>>>>> planetccrma packages (cm-grace and fomus), and i've tried a >>>>>>>>>>> locally >>>>>>>>>>> compiled version of fomus-1.12. In both cases the programs >>>>> show >>>>>>>>>>> up in >>>>>>>>>>> the Grace splash screen, but evaluating any of the examples >>>>>>>>>>> crashes >>>>>>>>>>> Grace with this error echoed: >>>>>>>>>>> /usr/bin/Grace: symbol lookup error: /usr/lib/fomus/ >>>>> lilyout.so: >>>>>>>>>>> undefined symbol: >>>>> _ZN5boost9iostreams22file_descriptor_sourceC1Eib >>>>>>>>>>> >>>>>>>>>>> i found an earlier message on this list from D. Phillips with >>>>>>>>>>> the same >>>>>>>>>>> error report, though in his case the problem was apparently >>>>>>>>>>> resolved >>>>>>>>>>> with a reinstall - no such luck in my case. >>>>>>>>>>> >>>>>>>>>>> thanking you in advance, >>>>>>>>>>> b >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> > > _______________________________________________ > Cmdist mailing list > Cmdist at ccrma.stanford.edu > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist > > -- View this message in context: http://old.nabble.com/Grace-and-Fomus-on-F-14-tp31172796p32880818.html Sent from the CCRMA - CMdist mailing list archive at Nabble.com. From dawsonwu at rahul.net Tue Nov 29 09:03:57 2011 From: dawsonwu at rahul.net (Ken Dawson) Date: Tue, 29 Nov 2011 09:03:57 -0800 Subject: [CM] Grace and Fomus on F 14 In-Reply-To: <32880818.post@talk.nabble.com> References: <99A5BBF4-0E20-4A23-8AE3-BFBAED9299C9@uiuc.edu> <07B939E3-8A51-4C81-8D24-6DA72723A9F7@uiuc.edu> <1300469131.11461.36.camel@fred> <1300477322.11461.91.camel@fred> <66971AAD-DBC1-4CC1-AE74-1F7CC2C0F76D@uiuc.edu> <4D83D2B9.1000507@localhost> <1300496870.11461.163.camel@fred> <32880818.post@talk.nabble.com> Message-ID: <4ED5107D.5050509@rahul.net> /sbin/ldconfig is part of the glibc package on Fedora. Make sure you are looking for it in /sbin (not in normal paths). /ken glibc-2.13-2.i686 : The GNU libc libraries Repo : installed Matched from: Filename : /sbin/ldconfig zr /home/dawsonwu> On 11/29/2011 06:38 AM, jallan365 wrote: > > I'm pretty stuck on installing Fomus (1.18) with Grace (3.7.3) on os x > 10.6.8. > using the instructions that Bill gave below > > - get boost 1.45, untar into /usr/local/src and run ./bootstrap >> - ./bjam install --prefix=/usr/local >> - (though this puts things in very strange places - the whole boost >> build & install process is very opaque to me) >> - mv /usr/local/libboost_* lib/ (see above) >> - mkdir /usr/local/include/boost >> - mv /usr/local/boost/* /usr/local/include/boost >> >> - then untar fomus 0.1.15 into /usr/local/src >> - ./configure --with-boost=/usr/local >> - make install >> >> - make a file called 'local.conf' in /etc/ld.so.conf.d/ containing the >> line '/usr/local/lib' >> - run ldconfig >> >> - start Grace and see the new Fomus in its terminal window >> - run a fomus example from Help>Examples>Scheme>Fomus and do a >> hokeypokey when it works! > > I've got as far as > > > - run ldconfig > > but maybe because I'm not using Fedora/Ubuntu I can't find ldconfig or an > equivalent? I know that Fomus is installed properly (did fomus -O and the > list of info came up) but I'm still getting the same error message > > >>>>> Error: Fomus: can't find FOMUS library >>>>> Error: don't know how to open "fomus1.ly" >> > > I'm not sure how I can get round this, frankly I'm pretty much a novice for > all things regarding terminal. I'd really appreciate some help, Fomus is > exactly what I need to use for my work and I feel like it's really close! > Cheers, > Jallan > > > > Bill Sack-2 wrote: >> >> o.k. - i got it sorted here using a local boost and fomus and i'll >> outline the steps here in case it helps anyone else who doesn't want >> to wait for fedora to update boost to 1.45. >> >> - get boost 1.45, untar into /usr/local/src and run ./bootstrap >> - ./bjam install --prefix=/usr/local >> - (though this puts things in very strange places - the whole boost >> build & install process is very opaque to me) >> - mv /usr/local/libboost_* lib/ (see above) >> - mkdir /usr/local/include/boost >> - mv /usr/local/boost/* /usr/local/include/boost >> >> - then untar fomus 0.1.15 into /usr/local/src >> - ./configure --with-boost=/usr/local >> - make install >> >> - make a file called 'local.conf' in /etc/ld.so.conf.d/ containing the >> line '/usr/local/lib' >> - run ldconfig >> >> - start Grace and see the new Fomus in its terminal window >> - run a fomus example from Help>Examples>Scheme>Fomus and do a >> hokeypokey when it works! >> - write some music. >> >> b >> >> On Fri, Mar 18, 2011 at 9:07 PM, David Psenicka >> wrote: >>> I just compiled fomus 0.1.15 with boost 1.44 on Ubuntu and had no >>> issues... >>> I'll have to install fc14 somewhere and try to compile it in that >>> environment to figure out what's going wrong. I'm almost sure that >>> undefined symbol has to do with the API change in boost 1.44. I'll post >>> a >>> solution as soon as I figure this out. >>> >>> BTW the option "--with-boost=/usr/local" on the ./configure command line >>> causes it to link with a local install of boost instead of the distro >>> version (the boost libs are in /usr/local/lib)--on my machine it compiled >>> against the local boost and worked properly (output a lilypond file and >>> displayed it). To run it I also had to export >>> "LD_LIBRARY_PATH=/usr/local/lib". >>> >>> On Fri, 2011-03-18 at 14:46 -0700, Fernando Lopez-Lezcano wrote: >>> >>> AFAICT Grace does not link with fomus, I imagine it just calls the fomus >>> executable? >>> >>> Grace loads libfomus.so dynamically at run time (the Grace build doesn't >>> link with it at compile time)... So recompiling Grace shouldn't be >>> necessary, it should load and use whatever version of fomus is installed >>> (and run without it if it can't find it) >>> >>> -David >>> >>> >>> >>> I just built a fomus 0.1.5 package for fc14 and there is an error when >>> trying to run a simple example. With this freshly compiled and installed >>> fomus I get an error just running /usr/bin/fomus with a single note .fms >>> file. The error appears just after it prints "running LilyPond" (it is >>> an underfined symbol in /usr/lib/fomus/lilyout.so). >>> >>> -- Fernando >>> >>> >>>> On Mar 18, 2011, at 2:42 PM, David Psenicka wrote: >>>> >>>>> I just noticed you're compiling fomus 0.1.12, which is old and >>>>> doesn't have the iostreams fix... Have you tried compiling fomus >>>>> 0.1.15 with the distro's boost libraries and headers? 0.1.15 has >>>>> bug fixes and should work fine with recent versions of Grace (you >>>>> shouldn't have to recompile Grace). If you stick with 0.1.12 then >>>>> you'll have to have two versions of Boost on your system to run an >>>>> old version of the software. >>>>> >>>>> If you are compiling against a local Boost install, make sure bjam >>>>> installed the header files in the right place (it likes to place >>>>> them in a directory that looks something like /usr/local/include/ >>>>> boost/boost_1_39 and they actually need to be in /usr/local/include/ >>>>> boost). The configure script might also be confused if you have two >>>>> versions of boost on your system, I have to try and compile against >>>>> a local boost install to see what it's trying to do and how to make >>>>> it find the right libraries. >>>>> >>>>> -David >>>>> >>>>> On Fri, 2011-03-18 at 14:29 -0400, Bill Sack wrote: >>>>>> >>>>>> i'm trying a local install of boost 1.39 >>>>>> did ./bootstrap and ./bjam install >>>>>> this is the output of ./configure in fomus >>>>>> >>>>>> checking for boostlib>= 1.35... yes >>>>>> checking whether the Boost::System library is available... yes >>>>>> checking for -l... no >>>>>> checking whether the Boost::Filesystem library is available... yes >>>>>> configure: error: Could not link against ! >>>>>> >>>>>> am i missing some part of installing boost? or missing a configure >>>>>> flag? >>>>>> >>>>>> On Fri, Mar 18, 2011 at 1:25 PM, David Psenicka >>>>>> wrote: >>>>>>> The error message has to do with Boost's iostream library which >>>>>> changed >>>>>>> quite a bit with version 1.44 (including the API, which would >>>>>> cause an >>>>>>> undefined symbol error if fomus is linking with the wrong library >>>>>>> version)... I think recompiling with the correct Boost library >>>>>> headers >>>>>>> should fix the problem. The recent fomus release should compile >>>>>> with Boost >>>>>>> versions before or after 1.44 (though I haven't tested 1.46 >>>>>> yet). I'll try >>>>>>> compiling with boost 1.44 on my machine and see if I run into any >>>>>> problems. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> On Fri, 2011-03-18 at 10:18 -0500, Heinrich Taube wrote: >>>>>>> >>>>>>> sorry its not working for you. i forwarded your message to david >>>>>>> psenicka, perhaps he has some idea. >>>>>>> fwiw im using boost_1_45_0/ . i know that boost_1_39_0/ also >>>>>> worked >>>>>>> for me. its probably not that hard to uninstall/reinstall boost it >>>>>>> that is actually the issue. >>>>>>> >>>>>>> >>>>>>> On Mar 18, 2011, at 10:04 AM, Bill Sack wrote: >>>>>>> >>>>>>>> i did try the new beta - everything seems to work great except >>>>>> fomus. >>>>>>>> i've done a bit more googling and discovered that this is a >>>>>>>> longstanding (since 12/10) unresolved problem with fomus and f14 - >>>>>>>> there's a message on the planetccrma list about it that i somehow >>>>>>>> overlooked when it was current. >>>>>>>> >>>>>>>> the issue has nothing to do with Grace or cm at all - i get the >>>>>> same >>>>>>>> error message trying to run one of the fomus examples in the >>>>>>>> documentation (i.e.: outside of cm). >>>>>>>> >>>>>>>> i still suspect that it has something to do with the version of >>>>>> boost >>>>>>>> but i don't have the patience to downgrade and recompile right >>>>>> now. >>>>>>>> >>>>>>>> b >>>>>>>> >>>>>>>> On Thu, Mar 17, 2011 at 4:36 PM, Heinrich Taube >>>>>>>> wrote: >>>>>>>>> i just tested fomus 0.1.15 in all the betas I can (osx win32 and >>>>>>>>> ubuntu) >>>>>>>>> using the complex "prime harmonics" example at the end of the >>>>>>>>> example file >>>>>>>>> you get by selecting: >>>>>>>>> Help>Examples>Scheme>Fomus >>>>>>>>> >>>>>>>>> the example ran eveywhere (really fast on osx and ubuntu!), >>>>>>>>> although on >>>>>>>>> ubuntu i did not get the pdf viewer opening automatically with >>>>>> the >>>>>>>>> computed >>>>>>>>> score. >>>>>>>>> >>>>>>>>> so im not sure what the issue on your fedora, are you using the >>>>>>>>> fedora beta1 >>>>>>>>> i made today? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mar 17, 2011, at 1:08 PM, Bill Sack wrote: >>>>>>>>> >>>>>>>>>> i built fomus 1.15 here too and got the same crash when trying >>>>>> the >>>>>>>>>> example. i wonder if this has something to do with the version >>>>>> of >>>>>>>>>> boost that's packaged for f14? >>>>>>>>>> looks like 1.39 on f 12 >>>>>>>>>> and 1.44 on f14 >>>>>>>>>> >>>>>>>>>> maybe i'll try a locally downgraded version of boost and see >>>>>> what >>>>>>>>>> happens. >>>>>>>>>> >>>>>>>>>>> do i need to do something about the lock file or not? maybe i >>>>>> could >>>>>>>>>>> disable >>>>>>>>>>> this on linux , but running two version of grace probably >>>>>> isnt a >>>>>>>>>>> good >>>>>>>>>>> idea >>>>>>>>>>> as they will both write to the preference file... >>>>>>>>>> >>>>>>>>>> would it be hard to have a message echoed to the shell if >>>>>> there's a >>>>>>>>>> permission issue or some other conflict with the lockfile? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mar 17, 2011, at 8:56 AM, Bill Sack wrote: >>>>>>>>>>> >>>>>>>>>>>> hello again, >>>>>>>>>>>> i'm trying to get Fomus going with Grace on fedora 14. i've >>>>>>>>>>>> tried the >>>>>>>>>>>> planetccrma packages (cm-grace and fomus), and i've tried a >>>>>>>>>>>> locally >>>>>>>>>>>> compiled version of fomus-1.12. In both cases the programs >>>>>> show >>>>>>>>>>>> up in >>>>>>>>>>>> the Grace splash screen, but evaluating any of the examples >>>>>>>>>>>> crashes >>>>>>>>>>>> Grace with this error echoed: >>>>>>>>>>>> /usr/bin/Grace: symbol lookup error: /usr/lib/fomus/ >>>>>> lilyout.so: >>>>>>>>>>>> undefined symbol: >>>>>> _ZN5boost9iostreams22file_descriptor_sourceC1Eib >>>>>>>>>>>> >>>>>>>>>>>> i found an earlier message on this list from D. Phillips with >>>>>>>>>>>> the same >>>>>>>>>>>> error report, though in his case the problem was apparently >>>>>>>>>>>> resolved >>>>>>>>>>>> with a reinstall - no such luck in my case. >>>>>>>>>>>> >>>>>>>>>>>> thanking you in advance, >>>>>>>>>>>> b >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >> >> _______________________________________________ >> Cmdist mailing list >> Cmdist at ccrma.stanford.edu >> http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> >> > From taube at illinois.edu Tue Nov 29 10:51:56 2011 From: taube at illinois.edu (Heinrich Taube) Date: Tue, 29 Nov 2011 12:51:56 -0600 Subject: [CM] Grace and Fomus on F 14 In-Reply-To: <32880818.post@talk.nabble.com> References: <99A5BBF4-0E20-4A23-8AE3-BFBAED9299C9@uiuc.edu> <07B939E3-8A51-4C81-8D24-6DA72723A9F7@uiuc.edu> <1300469131.11461.36.camel@fred> <1300477322.11461.91.camel@fred> <66971AAD-DBC1-4CC1-AE74-1F7CC2C0F76D@uiuc.edu> <4D83D2B9.1000507@localhost> <1300496870.11461.163.camel@fred> <32880818.post@talk.nabble.com> Message-ID: <6B023FFF-2EB5-4C58-9D65-40D94E0E8805@illinois.edu> when you build grace did you specify the --fomus install path to premake? if you did a vanilla 'make install' in fomus it'll put things under / usr/local so I do cd cm premake --sndlib ../sndlib --fomus /usr/local ... make On Nov 29, 2011, at 8:38 AM, jallan365 wrote: > but maybe because I'm not using Fedora/Ubuntu I can't find > ldconfig or an > equivalent? I know that Fomus is installed properly (did fomus -O > and the > list of info came up) but I'm still getting the same error message > > >>>>> Error: Fomus: can't find FOMUS library >>>>> Error: don't know how to open "fomus1.ly" >> > From jwmatthys at yahoo.com Tue Nov 29 19:34:30 2011 From: jwmatthys at yahoo.com (Joel Matthys) Date: Tue, 29 Nov 2011 22:34:30 -0500 Subject: [CM] Grace build error on Ubuntu 64bit Message-ID: <1322624070.19791.6.camel@jwmatthys-hpdv6> I encountered some build errors in the latest svn of Grace. CmSupport.cpp, lines 75 & 82: error: cast from ?void*? to ?juce::uint32? loses precision Replacing uint32 with long allowed the build to continue, and Grace seems to work OK now. Will it still behave as it should? I'm thrilled about the new metro features. Grace + live coding should be a great combo! Joel From juanig at ccrma.Stanford.EDU Wed Nov 30 08:25:08 2011 From: juanig at ccrma.Stanford.EDU (Juan Reyes) Date: Wed, 30 Nov 2011 11:25:08 -0500 Subject: [CM] those birds of the samson box Message-ID: <4ED658E4.9090906@ccrma.stanford.edu> Hi Bill, My apologies for a not so technical question and rather historic. What is the history behind birds.clm (birds.scm) ?. Once again, there seems to be a growing interest in bio-acoustics on some of my students. Thanks a lot, --* Juan From bil at ccrma.Stanford.EDU Wed Nov 30 10:08:56 2011 From: bil at ccrma.Stanford.EDU (Bill Schottstaedt) Date: Wed, 30 Nov 2011 10:08:56 -0800 Subject: [CM] those birds of the samson box In-Reply-To: <4ED658E4.9090906@ccrma.stanford.edu> References: <4ED658E4.9090906@ccrma.stanford.edu> Message-ID: <20111130180652.M46795@ccrma.Stanford.EDU> > What is the history behind birds.clm (birds.scm) ?. Around 1980 I wanted a bird song for "Colony", but realistic-sounding bird songs are not easy to make from scratch. So I got out my bird book, Robbins, Bruun, Zim, Singer "Birds of North America" Golden Press, NY 1966, which had sonograms of most of the songs. The graphs were incredibly small, so I needed a magnifying glass to read them, but in many cases, you could simply copy the data into the frequency and amplitude envelopes of a sine wave instrument, and a pretty good bird song would result. My main collaborator in this research was the AI lab cat named Marathon. She would prowl around the speakers trying to find the birds, which I took as expert approval. bird.clm/scm is a very direct translation of those notelists. Here's the Samson box version of the bird: Instrument(Bird); INTEGER ARRAY Gens[1:3]; REAL ARRAY Frats,ARats[1:3]; INTEGER i,AllOut,FltOut; Pars(<(Name,Beg,Dur,Frq,FrqSkw,Amp,Deg,Rev,FUNCTION FrqF,FUNCTION AmpF,LpCoeff)>); Waiter(Beg); Gens[1]Osc(Pns,AllOut,Zero,Sinemode); IF LpCoeff>0 AND LpCoeff<1 THEN FltSig(Pns,FltOut,AllOut,LpCoeff,1-LpCoeff,0,1) ELSE FltOutAllOut; LocSig(Pns,FltOut,Deg,1,Rev); AddEnv(Pns,Gens[1],"F",Frq,FrqSkw,FrqF); AddEnv(Pns,Gens[1],"A",0,Amp,AmpF); End_Instrument(Pns); The funny characters are left-arrows in the SAIL character set. The low-pass filter was for distance effects. Many years later, I made what I think are better renditions in animals.scm, using Snd to make the sonograms, and some very good recordings from Cornell. There's documentation about that in sndscm.html. Some bird songs are incredibly beautiful when slowed down via granular synthesis.