Ron - While I was working on the CtkEvent, I wound up building a class called CtkTimer. In real-time, it uses TempoClock, when the event is asked to render, it keeps track of a variable that represents time to build a score. When I saw your email this morning, it occurred to me that a similar object that responds like a Clock could work in a similar way. I think this is a different issue then the sample accurate scheduling, and I'll think about this a bit more over the weekend... Of course, I think there are other issues that come up when trying to render patterns in NRT... but perhaps we should start a new thread to talk about those!
Best, Josh On Nov 30, 2007, at 8:47 PM, blackrain wrote:
hmm I know of the NRT issues in the event framework to render some things that need a clock. The problem there (as I can tell) is exactly the other way around; scsynth has no TempoClock; May look at first as if we solve one we get the other but I dont think I get the idea. Unless, I am missing something. Ron, did you mean a server side implementation of TempoClock? I have been looking at the lang and server scheduling code; it seems to me that the cleanest approach to implement sample scheduling in scsynth is by creating a new message queue for the new sample scheduled bundles; process these packets in parallel with the osc messages queue in the run loop (using an also new priority queue). This of course implies the creation of several new classes/structs to deal with samples instead of osc timestamps mostly. for example for SC_ScheduledEvent we'd have SC_SampleScheduledEvent something like: struct SC_SampleScheduledEvent { SC_SampleScheduledEvent() : mSample(0), mPacket(0) {} SC_SampleScheduledEvent( struct World *inWorld, Float64 inSample, OSC_Packet *inPacket) : mSample(inSample), mPacket(inPacket), mWorld(inWorld) {} Float64 Sample() { return mSample; } void Perform(); Float64 mSample; OSC_Packet *mPacket; struct World *mWorld; };SampleMsgFifo the new sample MsgFIFO, SamplePriorityQueueT, mSampleSchedulerand so on. The feeder simply pushes messages to the queue where it belongs to based on bundle kind - #bundle or #sbndle. it would be great to hear what you all think about the idea or if I am wrong or missing something. x On Nov 30, 2007 8:50 AM, ronald kuivila <rkuivila@xxxxxxxxxxxx> wrote:Hi, There is an issue with rendering Patterns in NRT - functionality that requires a clock breaks. It is possible that the cleanest design for the revised TempoClock might arise from supporting both synchronization and as fast as possible computation. RJK On Nov 29, 2007, at 8:51 PM, blackrain wrote:awesome, I will start by taking a look at the code and see what we can do =) xOn Nov 29, 2007 5:41 PM, ronald kuivila <rkuivila@xxxxxxxxxxxx> wrote:Hi, Let's definitely work on this. I want to try to hunker down on fixing the earlytermination issues in patterns, so I may need to wait a few weeks toreally get on the case. So if you want to push on, please do and keep me updated. (I have not even looked into how TempoClock is implemented yet.) RJK On Nov 29, 2007, at 5:58 PM, blackrain wrote:Hi Ron, The method you describe in the beginning of your email is 99% close to what I am currently using. Only difference is that I mark the thethread secs at the time of spawning the counter; take a first delta when the first impulse sample arrives. this because of the app where this system works on; I get absolute sample positions of events fromosc messages. You are right, the method has been pretty accurate so far. The blocking TempoClock idea sounds very interesting. it would be good to experiment with it; see the results and system overhead it may imply. if that worked, sendSampleBundle is not needed at all! I would be more than glad to help on testing and/or coding Ron. The implementation I have been outlining is a draft and scheduling packets in the mid and long future is still a problem under that model. You are totally right. Seems to me, what I have described so far only gives us half of whatwe really need. The real problem in scheduling packets to be sample accurate, lays in the fact that our concept of time is still tied tothe SystemClock. Scott's comment about JMC's talk in the Hague, made me think (I wasnt there but dreamed a bit). so here is another possible approach... Why dont we register the Lang as a coreaudio (jack for linux ppl) client? thats all we need to get the interface sample count. we can then implement SampleClock on that here are some of the possibilities: SampleClock.new(device, options) SampleClock.free SampleClock.seconds SampleClock.samples SampleClock.sched and schedAbs etc... Time for SampleClock will advance based on the hw interface sample steps. ie, 1 second will be 44100 steps at a 44.1kHz sample rate. we will be able to use SampleClock just like we use the SystemClock or a TempoClock; the patterns framework, tasks, routines everything will work the same except we can use sendSampleBundle (or a new version ofsendBundle that allows the choice of a scheduling clock for bundles)and be sample accurate. schedule packets all the time we want in the future it wont fail. x On Nov 29, 2007 6:46 AM, ronald kuivila <rkuivila@xxxxxxxxxxxx> wrote:Hi all, Here is a possible approach to long term synchronization: Server sends an incremental samplesComputed number at some interval The OSCresponder subtracts that value from samplesProvidedByClock Clock adds samplesComputedInInterval to samplesProvidedByClock andblocks if that value exceeds maximumComputeAhead If the server andthe language are running on the same machine, you can almost certainly allow maximumComputeAheadto be a negative number corresponding to the maximum server latency(i.e., the server willbe late with its reassurances everything is ok, and the system canmake an allowance for that.) For this to work, the Clock runs a little fast relative to the servers physical sample rate (not at a higher sample rate, just thinks time is passing a delta faster). We don't need a fancy PLL, just setting the clock to prevent starvation is enough. Another question is the amount of clock jitter acceptable at the language end. This really depends on what else is happening. For graphics, 10 msec will be fine, for parallel musical systems("MIDI" by which I mean non-sample accurate performance on anotherserver) you probably want that tightened down to1 msec. If the sample clock variance is +-0.5%, then worst case is1%, so 1 second updates would sufficefor graphics and 1/10 second for MIDI. (I guess we need to fold inthe maximum discrepancy between the language clock and the sample clock to make this fully accurate, but this is a reasonable ballpark figure.) So long term syynchronization boils down to a TempoClock that blocks. This seems a litttle easy to me, so it may be nonsense. If so, tell me why! RJK On Nov 28, 2007, at 7:26 PM, blackrain wrote:Since the lang does not have an idea of how much time it takes asample step for the synth, we give an offset in samples; the synthwill make the bundle effective based on that delta.if we schedule a synth spawn for 1 sec in the future, scsynth willexecute the event in 1 second from the time of request but we have no warranty that 1 second will be exactly 44100 samples from now (@ 44.1kHz). Scheduling a synth spawn 44100 samples from now will be 44100 samples from now. we dont really need to know a sample count in the lang. latency willallow us to play with delta samples times and always land exactlywhere we want. if there was the need, a PLL approach may work to obtain an interface sample count but will probably result a bit expensive; depending of course on the sync rate and the application. in fact, we can still sort of calculate deltas in time (within bounds as the examples I posted) but schedule in samples and we will be sure the result will be there. what I meant about the one sample impulse was in order to sync otherapps that may be connected thru digital audio lines to the synth -this applies to other hosts too. in that case the coreaudio clock for both interfaces (the same digital clock) will advance at the same rate. for a setup like that, all we need is a one sample impulse from the foreign app to tell where play was engaged for example. #sbndle (thinking a bit - still 8 bytes) will not break the current standard implementation.the server will know it is receiving a bundle that states a deltain samples. we can use a Float64 to state deltas and be ale to handle subsample accuracy instead of the usual 64 bit integer used to form time stamps. x On Nov 28, 2007 5:52 PM, Sciss <contact@xxxxxxxx> wrote:maybe you mean a kind of PLL (phase-locked loop) or servo- controlled-clock on the sclang side? so it queries in intervals the currentscsynth clock and adjusts itself accordingly, so that s.latency for #sbundle's stay in a safe range? Am 29.11.2007 um 00:43 schrieb Sciss:sounds interesting, but (maybe it's too late in the night) i don't yet get how the #sbundle approach is working. Am 29.11.2007 um 00:32 schrieb blackrain: [...]All that is needed like Jan states, is a one sample impulse and a responder to tell where the synth is._______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel_______________________________________________ Sc-devel mailing list Sc-devel@xxxxxxxxxxxxxxx http://www.create.ucsb.edu/mailman/listinfo/sc-devel
****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/