[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Notes and observations from a large SC project
Am 29.07.2009 um 15:19 schrieb Scott Wilson:
On 29 Jul 2009, at 01:23, Andrea Valle wrote:
Thanks Scott(s)
But are you concerned with node order or asynchronous actions?
IMHO the two most boring aspects of SC :)
- About order: the possibility of auto-ordering the chain of
synths when needed would be a great improvement.
(I'm trying to create a microlanguage over SC to implement it and
forget ordering for fast prototyping)
What sort of syntax do you have in mind.
- About asynchronicity. It's clearly possible to sync (I've asked
about this), but sometimes I'd like to simply have a sync var in
ServerOptions. If true, syncing is always on and you forget Server-
Client.
I suppose you could do this by having a kind of alternative
NetAddr, which spawned a Routine (whenever one doesn't already
exist), and syncs after each message. Not sure it's desirable
behaviour most of the time though.
by the way, i have used this approach a few times with good results.
supercollider is very helpful here with the cooperative multitasking
that makes concurrency and race conditions a minor problem. here is
an example:
condTask = Condition.new;
queueTask = PriorityQueue.new;
routTask = fork { this.prTaskBody };
taskSched { arg delta ... args;
queueTask.put( (delta ? 0.0), args );
condTask.test = true; condTask.signal;
}
prTaskBody {
var task, delta, trnsTime;
inf.do({
while({ queueTask.isEmpty }, {
condTask.test = false; condTask.wait;
});
delta = queueTask.topPriority; // - thisThread.seconds;
task = queueTask.pop;
if( delta > 0, { delta.wait });
trnsTime = thisThread.seconds;
transactions = nil;
try {
if( debugTask, { task.postln });
this.perform( *task );
// server.sync; // not necessary in my case, but this is the
point where an explicit sync could ahppen
} { arg error;
error.reportError;
transactions = nil;
};
if( transactions.notNil, { this.changed( \transactions,
transactions, trnsTime )});
});
}
where each task will generate transactions that basically fill up an
OSCBundle that gets eventually send to the server. OSCBundle is
useful for managing asynchronous messages.
ciao, -sciss-
_______________________________________________
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/