On Wednesday 02 June 2010 01:25:28 Gabriel M. Beddingfield wrote: > With respect to real-time temop changing, I've given this subject a > lot of thought and code while working on InConcert.[1] Here's my > thoughts... > > > So the question is, if you change the tempo in the middle of a > > song, at which point does that change take effect? > > Simple answer: immediately. Thanks Gabriel... I was actually leaning towards one of the other options, so that's definitely food for thought :) But everything you wrote makes perfect sense, and I'm starting to think that the "floating reference" approach is indeed the one that makes most sense for klick to implement. As soon as both audio-frame-based clients and BBT-based clients are present and syncing to JACK transport, there's simply no way for the timebase master to keep both in sync. And I doubt that users would expect clients like Ardour to do on-the-fly timestretching when the transport changes tempo - although it would be great if it could... > Furthermore, the issues you mention all have to do with /seeking/. > This only make sense in a "live" situation if the host sequencer has > special support for it anyway. For a simple implementation, you can > mostly ignore seeking. > > Here's a few different ways to approach it: > > 1. Floating Reference/Epoch: This is the first case you > mentioned. When the tempo changes, you recalculate > your BBT/frame reference point. Frame 0 is no longer > 1:1.0... so you will (as a special case) reset the > timeline whenever someone relocates to 0. Is relocating to zero really different enough from seeking to other positions to make it a special case? At the very least, the timeline would also need to be reset when seeking would otherwise result in a negative frame or bar number. The only case I can think of where it would be advantageous to avoid resetting the timeline is when seeking relative to the current position (whatever that means in terms of the UI used), but I'm not sure if that's really a convincing argument. Cheers, Dominic _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
