Am 13.09.2013 10:43, schrieb Tim E. Real: > Of course. Not to worry.
:) still not amused, because actually I want a production-level DAW. Meh... But I guess "not glitch in live situations" is enough :) >> >> >> My opinion about this is: >> The set of possibly dangerous operations is: >> "changing things in the near future or in the past" and >> "use the global tempo buttons while playing back a wave part" while playing. >> >> I think we should state that MusE MAY glitch, but CANNOT crash in these >> cases. Additionally, we should offer a "glitch-free"-checkbox. If checked, >> all possibly dangerous operations will be disallowed. >> >> In a live situation, these "dangerous operations" should be unneeded. >> In a studio situation, occasinal glitches when the user provokes this are... >> well... acceptable. >> >> Can you agree? > > Sure for now, until we can think of a way to resync that prefetch I suppose. I've working on one: currenty, upon seek MusE waits until AudioPrefetch has completely prefetched everything. We don't have to: we could just precalculate the first segment, and fill the buffer in background, possibly while playing then. And pray, that the harddisk will not block in the meantime. My current attempt is: Upon any tempo manipulation, which is "in the past or in the near future" (todo: need a way of finding this out), tell AudioStream to flush all ringbuffers and seek. Pro: rapid response. Contra: No proper sync (it's impossible during playback!), so audio might be inaccurate by some hundreths of a second Contra: Seek()in on an AudioStream will disrupt him. a "Pop" or "crackle" might be heard for a very short moment. This is the best solution i could think of. > > But I suppose a tougher question is what happens when midi is synced to > external clock? During playback if we compute tempo from clock > (which I do NOT at the moment [*1] - remember I mentioned I drive our > midi tick directly from the clock rather than trying to compute tempo), > then that's a continuously variable streaming tempo coming in. Horror! I have not implemented this, but my idea is: Stretchers always rely on *the previous* tempomap. If your external sync source changes tempo, the first playback *will* be out-of-sync with audio. The second playback (because MusE now has recorded this new tempomap) will be fine. Syncing audiostreams (without any prefetching) to external sync should be easy. However, syncing AudioPrefetch might be hard-or-impossible... Possibly, we should re-think our AudioPrefetch, so that it only delivers sample (read from file, and decode mp3. not more). However, when the stretcher sits outside of AudioPrefetch, the prefetcher must support variable-length prefetches. Which means basically a rewrite of AudioPrefetch (which is merely FilePrefetch then)... > > [*1] > If Rec is on, I DO record the clocks and compute tempo LATER upon Stop. > I ask the user if they wish to replace the current tempo map with the one > computed from the recorded clocks. > The clocks have user-adjustable averaging filter Settings, from 'None' > to heavy. > My point there is say during playback if you want accurate tempo you're > going to have to deal with fairly raw, un-filtered un-averaged external > clocks which leaves you with a very jumpy unpredictable tempo > (midi clock is very jittery, especially if NOT on a dedicated hardware > connection, that is, shared with notes, controllers and so on). > > However, one good thing about having these new stretcher/shifter streams, > is that I hope we can finally begin to make digital Phase Locked Loops for > locking audio to some external synchronization signal. > Such as Midi Time Code (which is in audio/video time not midi clocks). > The common term 'Sync Lock Chasing' is probably a more accurate > description of the locking process here - perfect digital lock is hard to > achieve, there may be some continuous wandering back and forth of the > sync but might be acceptable as long as the /net/ wandering is zero > (continuously a plays game of catch-up and fall-back) and no large swings. > Well, I digress, sync is another story. > > At long last, MusE will get a vari-speed/pitch playback mechanism. > Looking forward to experimenting. > Thanks, I hope we can make it do some neat stuff. So we won't be out of work till 2015 :) flo > > Tim. > > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
