Am 01.05.2013 08:34, schrieb Tim E. Real: > 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.
i don't really want to update the tempo map in the way you say. That would introduce evil locking problems, and still not help me. Buuuut: > my tempo recording clock filtering code couldn't we during every playback record the tempo into a *temporary* tempomap, which is then freed of any lag (offline, that is), and afterwards the real tempomap is replaces by this recording? So there's no live-recording, but in the n-th playback, we always have the (n-1)-th tempomap, which should be the same, right? Can you please me tell me the class, function or even source code line, where incoming tick synth is handled? greetings flo > >> >> >> (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 >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
