[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sc-dev] Re: [sc-users] Synth.play revisited



this is *totally* a dev issue at this point. unless you think the dev list should only be c++. i think it should be questions of common infrastructure
development.

On Tuesday, July 23, 2002, at 08:16 PM, Julian Rohrhuber wrote:

here is a revised version of the Synth.play stuff for sc3.
I have adopted felix suggestion and modified it accordingly.

the group keeping track of the synths is good.

the scheduling stuff should not be in there i think.  it shouldn't
have been in there in sc2 either !!!!

its a job for SystemClock

or if you want beat based scheduling, it could be handled by Tempo.

Tempo.sched( )  // default global tempo

aTempo.sched() // multiple tempos in existence

or if you think we need Tempo as a separate concept, then a BeatScheduler



Of course it doesn't look as simple, but it works fine.
more comments and examples are in Synth.help

I am using a class Instr very similar to crucial Instr, as I hope this
will converge somehow.

if you want them to converge, why did you start from scratch and call it the same class name ;)
and you removed specs entirely.

i think you've put too many responsibilities on the Instr


from your code:
	//copied to here for now.
	//could be in Function actually.
	
	buildControlsFromArgs { arg externalInputs;


how about keeping it in SynthDef (since that's whose domain this is)
as a class method, passing in the function ?

maybe even building a SynthDef from a ugenFunc should be a talent of
SynthDef ? it only needs to know the rates of the args. (and not by guessing
based on the argument names IMHO).

i think that is the approach i will take: remove it from Instr entirely.


right now there is some functionality
in Instr that possibly could move to Patch.

there is some changes in common classes, so either replace those
_or use the class extensions (don't go cmd-y on an unknown message name then..).
the Server file must be replaced, the extension wouldn't work.

some more info is also on http://swiki.hfbk.uni-
hamburg.de:8080/MusicTechnology/431

right now i got Patch playing and mostly on-the-fly patchable. then i ran into certain
issues which require a refactoring.

i will now post where i'm at currently, including where i ran into the hitch.

what works:  Instr writes its def file, Patch plays the Instr.
when gui-ed you see that Patch created some NumberEditor / sliders.
they work like sc .kr !
you can move the slider and hear the result ! wow. welcome to the early 90s.

the potential of the patching system is very good. it is aware of different servers.
you can easily patch one slider or number pattern to multiple servers.

setting float values or patching in different devices in to the patch while
it is playing.


kind of works:
a patch played through another patch. certain issues with stop and starting. it loses its bus def or something. child patches count their output connections,
but don't shut themselves down when it goes to zero.

better to refactor and get a more intelligent PatchCable system going. that will move all the dirty stuff into one object and out of Patch, Player, your day to day
code page etc.

patchCable.setInput(2,float);
patchCable.setInput(2,numberPattern);
patchCable.setInput(2,midiController);

http://crucial-systems.com/SC/patching.tgz

it all goes in your library, there are two Common files that are altered (cause
override has bugs).



____________________
http://crucial-systems.com