On September 13, 2013 01:41:03 AM Florian Jung wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > i've found out something which does not amuse me: > > Changing the tempo map while playback > *WILL* glitch. (This includes using the 50%/200% "global tempo" buttons). > > Mutliple reasons for this: > > the audio prefetch thread, well, prefetches things. If you change tempo in > the near future (not yet played, but already prefetched), we're screwed: > > Should we empty and recalculate the prefetch buffer? Then we're playing "on > the bleeding edge" for some time. If your harddisk decides to block for > whatever reason, it will glitch. Or we play back what we have, and ignore > the problem. This will cause audio being out of sync with MIDI until you > stop/start playback. > > This applies to all changes in the near future, including wave-event or > -part movements. > > What should we do? > > > > > Then, what happens if the tempo is changed in the past? The current > position's tick will just continue as usual, but the frame will jump > (because with a different tempomap, tempomap.tick2frame will return > different things) > > But how to inform AudioPrefetch about this? > Actually, AudioPrefetch is accessing the tempo map *without synchronisation* > anyway, so this is bad. We have two options here: 1. Synchronize tempomap > access properly, by keeping TWO copies of the tempo map. Each change to the > AudioThread's tempomap must be mirrored to the Prefetcher (and the > prefetcher is in charge of migrating its own frame pointer, and possibly > discard and recalculate.) However, consequentially, we would have to > synchronize acces to events, parts, too. This would be really hard!) 2. > ignore the problem, and declare that changing the tempomap while playback > is unsupported and *expected to glitch* > > > I want to note that none of the above mentioned is a regression. It didn't > work before, and my audiostreams have the same problem.
Of course. Not to worry. I guarantee no MusE user who had at least one wave part in a song has *ever* changed the tempo - 'cause it simply hasn't worked until now :) But a pure midi song? Yes, go nuts with tempo, it should work OK. > > > 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. 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. [*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. 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
