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

Re: [sc-dev] was Re: [sc-users] [commit] new MIDI helpfile



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.

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/639

Also 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