|
Part of the issue is approaching the problem as if you were still using Max :-) What I mean is, the Max model depends on firing signals out of the tablet view, which you then filter using speedlim. Doesn't work that way in supercollider. There isn't a way to slow down the callback from a GUI object (or an OSC responder, or MIDI action etc.). It's just a callback, and it's going to fire whenever there is something to do. Right now you are imagining two objects: the GUI, and the synth player. I would suggest refiguring this as three objects: GUI, an object (or even just a set of variables) holding parameters from the GUI in memory, and the synth player. Then the connections are: GUI --> variables (the GUI callback just writes values into the variables) synth player <-- variables (the synth player runs at its own speed, and polls the variables only when needed) I'll use an Event for storage because I prefer keeping related things together (instead of just having them all floating in a disorganized soup). Events are great for adhoc data structures. ~tabletValues = (x: 0, y: 0, pressure: 0); // the action here ONLY changes the state of the system // it does not do anything expensive t.action = { |view, x, y, pressure| ~tabletValues.x_(x).y_(y).pressure_(pressure) }; // this guy controls the pace, using the tablet values on demand synthPlayer = Routine({ loop { Synth(...) // calc controls based on ~tabletValues.x etc. someAmountOfTime.wait; } }); hjh On Dec 3, 2008, at 8:38 PM, Level26 wrote:
: H. James Harkins .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |