[CM] Supercollider and CM
Tue, 10 May 2005 07:36:09 -0500
is there any advantage to generating sc scores as text files other than
being able directly see/edit the results? If not, then implementing a
lisp version of the 'dumposc' OSC utility is the way to go since the
osc layer needs to be there in any case in order to do realtime
supercollider, or to (possibly) interact with other osc aware
applications in the future. with a dumposc function you could get a
text file for those cases when you need to see/edit contents and we
would not have to populate the sources with duplicate write-event
methods that also have to be maintained. if you wanted to generate
text files all the time, you could simply use 'set-sc-output-hook!' to
set a personal hook that translates the .osc file after its written and
then execs supercollider with it.
does a 'dumposc' function seem like a reasonable solution to you?
> hi everyone,
> I've been using SC for quite a bit of time, and there are a couple of
> things that may be good to do. Some of this is a little biased on the
> way I had CM and SC working together, but I think they are worth
> First, I think it makes sense to have the scores write out text files
> (or at least have the option of doing this) in a similar way that the
> CM - CSound interface works. It is good to be able to edit output,
> and this can't be easily done with the osc binary files. Is this
> already possible?
> Second, there is already a SC class that will convert a text score to
> osc, or play it, or render it in NRT. Score.sc is the class, and
> there are examples in the Score-help file.
> finally, this was a bit of a fake but it worked nicely. The functions
> that Don Craig and I originally wrote to write out score also had the
> pad argument. I changed them awhile ago to take a pad argument, OR, to
> calculate a file duration based on the note objects 'dur' argument. Of
> course this meant that all SynthDefs had to have a dur argument for
> this to work. This is only needed for non-real-time rendering (in
> real-time, the last dummy command should be harmless no matter
> what)... The dummy timestamp was calculated as the greatest starttime
> + duration of all the notes. I like this quite a bit, and it can take
> the guess work out of calculating a possibly unknown file duration.
> Just a couple of suggestions. I'm really glad to see this being
> brought into CM in a more official way!
> I'm also interested in helping out in general. I'm on digest, but if
> there are SC questions I can help with, I will.
> On May 9, 2005, at 12:00 PM, cmdist-request@ccrma.Stanford.EDU wrote:
>> Re: [CM] Supercollider and CM
> Joshua D. Parmenter
> Graduate Student, Music Composition
> "...Some people think a composer's supposed to please them, but in a
> way a composer is a chronicler... He's supposed to report on what he's
> seen and lived."
> -Charles Mingus