Josh has pinned down the main points here, I'll just add a bit more
chat...
2008/12/28 Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
The engine needs to have the following capabilities:
Play a buffer "soundfile.wav" out of a single channel n with gain g
Play a buffer "soundfile.wav" out of channels [n1,n2,n3, ...] with
gains
[g1,g2,g3, ...]
Play a buffer "soundfile.wav" out of ALL channels with gain g
Provide a reference to playback instances so they can be killed,
have gains
updated, etc.
This above is all easily done, and I am guessing you have an idea
about how
to do it.
Yes. Damon, you don't specify whether your wav files are mono or
multichannel, which will have a slight bearing on how you code the
synthdefs, but either way it's pretty easy. Keep in mind that
SuperCollider's synthdefs need to know in advance how many channels
they work with, so you'd typically create a SynthDef for 1-channel,
then a SynthDef for 2-channel, then a SynthDef for 3-channel, etc.
Luckily, you can write that all at once using a loop such as
maxnumchannels.do{|numchannels|
// Here write code to specify a SynthDef for numchannels
}
Development Plan:
Develop synthDefs for the capabilities above that can be called
with args
above. The synthDef should "die" once playback is done.
Why should the SynthDef 'die'? Just curious... If you use arguments
correctly, and build fairly modular SynthDefs, you can use them
over and
over again... Or - do you mean that once the playback is done that
the Synth
you created (a Synth is the playing of a SynthDef) frees itself? If
it is
this, then either create an envelope that is the duration of the
sample with
a doneAction of 2, or wrap the PlayBuf output into a
FreeSelfWhenDone UGen.
Yes, I'm sure this is what is meant: the *instances* of the players
(i.e. the Synths, not the SynthDefs) should automatically free
themselves.
Josh's two approaches are correct. In the bleeding-edge version of SC
(see e.g. the new 3.3alpha) we have added doneAction to PlayBuf, so
you can add "doneAction: 2" to the PlayBuf directly if you want.
"Install" those synthDefs (not sure of terminology here)
permanently on
scserver so they will be available at server startup. Not sure how
to do
this.
.load the SynthDef. This writes out a binary representation of the
SynthDef
that is stored on disk. Then, the SynthDef is loaded when the
Server boots
Yes, each SynthDef can be stored on disk as a platform-independent
file *.scsyndef (you can copy them from machine to machine if you
want). As long as the server can find them in its search path, they'll
be immediately available whenever the server boots.
Create new synthDef instances on the server by sending OSC messages
from our
Java app. I hope to do this with JavaOSC or JCollider.
'Instances' of the SynthDef are called Synths, or are created with
the
'/s_new' OSC tag. Any OSC capable app can do this. Is there any
reason not
to use the SuperCollider language app? If there is, the next step is
easy...
Send back a reference to each new synthDef for remote Java control
of that
instance. Not sure how to do this.
a = Synth(\synthDefName, [\arg1, arg, \arg2, arg ... \argN, arg]);
'a' is the reference.
Configure scserver to run at Mac OS startup. Not sure how to do this.
If you use the SuperCollider app, then place it in your startup
items. OR -
make a standalone app and make that a startup item. Then, once ti
boots, you
can have it execute code by altering Main.sc (and since you are
altering
Main.sc, I suggest making a stand-alone). Tell it to boot the
server, and
once the server boots, execute your code.
If you don't use SuperCollider.app, then you need to figure out a
similar
way to do this.
Well, you usually want to launch scsynth with some command-line
arguments, so the easiest Mac way is to write a little command-line
script containing text such as
#!/bin/bash
/path/to/scsynth -u 57110
Then make sure the script is executable, and then you can add the
script to your Startup Items.
Dan
--
http://www.mcld.co.uk
_______________________________________________
sc-users mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/