Yes, I think this is great, and it would probably be good to add Renderer. But this still doesn't make code absolutely interchangeable, as the client might need to access values on the server that are only available at run-time, for instance polling a randomly generated value.If the client could be made to schedule on the same relative timebase as a NRT internal server, I think this would be the best solution and would solve this problem.
using a SendTrig, the server could advance the time in the scheduler. So the renderer could be made more similar to Scheduler to account for incremental timimg.
Of course I don't really know how to do that, or if implementing it would compromise something else, so easy for me to say... ;-)S. On 27 Nov 2004, at 18:16, Julian Rohrhuber wrote:the class Renderer I had written a while ago is supposed to be a step in this direction. http://swiki.hfbk-hamburg.de:8888/MusicTechnology/639Also I have added helpfiles foe Scheduler and Condition, which could be used similarly.What is still missing in Scheduler is elapsedBeats and schedAbs - if they are there, it could be used just like a Clock.elapsedBeats { ^clock.elapsedBeats } schedAbs { arg beat, item; var delta; delta = clock.beats2secs(beat) - seconds; if(delta < 0) { "scheduled too late.".postln }; this.sched(delta.max(0.0), item); }I suspect this wouldn't work with NRT, as currently NRT is effectively server-side only. I have wondered however if it mightn't be possible to have an NRT mode with the internal server that would allow client and server NRT activity. This would perhaps be ideal, as it could allow for easily interchangeable code, as we had in SC2 with Synth.write and Synth.collect.S. On 27 Nov 2004, at 15:08, Joshua Parmenter wrote:Especially if this was something that could work in NRT also. The loss of OSCresponder in NRT has been talked about a bit. In that sense, it could also be used from a MIDI file that is being fed into SC.Josh ****************************************** Joshua D. Parmenter Graduate Student, Music Composition http://students.washington.edu/joshp"...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 On Nov 27, 2004, at 4:58 AM, Scott Wilson wrote:What would that look like? You would still need to register it somewhere I assume?S. On 27 Nov 2004, at 11:53, James McCartney wrote:I think both MIDI and OSC responders could be gotten rid of and replaced with a mechanism where you fork a thread and wait for a certain kind of event._______________________________________________ sc-users mailing list sc-users@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-users_______________________________________________ sc-users mailing list sc-users@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-users_______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev_______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev-- . _______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev_______________________________________________ sc-dev mailing list sc-dev@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-dev
-- .