On May 1, 2013 01:33:25 AM Florian Jung wrote: > Hi > > I need a way to find out a tick-to-frame mapping, even if we're synced > to an external device, thus not using our built-in tempomap. > > I already know at which frame we are currently and how many frames i > need to retrieve. > I need to know at which tick we are currently (easy), and how many > (sub)ticks will pass during these retrieved frames. Looking further into > future would be even better (it would be great to know the (sub)tick > position we'll be at after 1000-10000 audio frames.) > > How can I get such one? > > I need this already in AudioPrefetch::prefetch. Is there guesswork > involved, because i don't know the tempo yet (in case of external sync)?
Ew, that's a really tough one. You see, originally someone had written the syncing code (you can see it) to try and dynamically update the tempo map as it went along. I found this was not practical as it involved lengthy filtering delays so the tempo map could not really be in immediate 'sync' with the incoming midi clock ticks. I could not find a way around it at the time. So you will see that what I did was remove all that and simply drive the tick position *directly* from the incoming midi clocks. It resulted in *rock* solid performance *guaranteed* not to drift no matter how wildly the incoming midi clock (clock basically means external tempo ) may swing or vary. Unfortunately it means during external sync the tempo map is *not* used at all and is *not* to be used at all. That was the price paid. It is *very* difficult to smooth out the incoming clock pulses and filter them and derive a fairly 'stable' tempo from them - without delay - unless thousands of tempo fluctuations per second are acceptable. Take a look at my tempo *recording* clock filtering options in the Sync Dialog to see what I mean. I offer several options to the user depending on their needs, including no filtering at all for the utmost *accuracy* upon playback of the recorded tempo stream. Ironically I do realize that this very same code *could* be used for dynamically updating the tempo map as it rolls along - which was the original plan way back. Still, even with no filtering I think there would be an inherent delay in the dynamic tempo being 'valid', and there *still* would be slight accuracy/drift problems as it rolls along. That's why my direct-drive-ticks method is still the ultimate method, I think. But if we can find a way to additionally dynamically update the tempo map too as it rolls along, so that stretchers/resamplers can use it, that would be good. So perhaps my tempo recording clock filtering code can ultimately be re-used here. > > > (If not syncing to external clock, i assume i just can use the tempomap > for this, right?) Yep sound correct. I'm not aware of anything else, except the user (!), altering the tempo map during playback. Hope all that made sense. Tim. > > greetings > flo ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
