[linux-audio-dev] XAP Time/Transport - varispeed/shuttle

David Olofson david at olofson.net
Thu Dec 19 12:32:01 UTC 2002


On Thursday 19 December 2002 17.51, Frank van de Pol wrote:
> On Thu, Dec 19, 2002 at 02:41:47PM +0100, David Olofson wrote:
> > On Thursday 19 December 2002 04.33, Tim Hockin wrote:
> > > > The net result is that if tempo is 120 BPM and SPEED is 2.0,
> > > > you get fast forward at 240 BPM.
> > > >
> > > > Of course, you may run backwards and stuff that way as well,
> > > > but don't expect the synths to play sounds backwards... ;-)
> > >
> > > Sounds sane - and that implies negative tempo?
> >
> > Yes.
>
> True, the effective tempo is negative, but think the SPEED control
> should be decoupled.

Yes, of course. It's just a parameter for the sequencer, that tells 
it something about how to apply the tempo map. It could be passed on 
to plugins as well, but they should *not* apply it to the musical 
time data in any way, since the sequencer does that.


> - the SPEED control also affects the effective sample rate (not the
> rate in the processing graph, but the rate at which the audio
> material is played). Depending on the plugin it can decide how to
> implement it, eg. resampling, pitch shifting, adjustment of
> LFO/envelope etc.

Yeah, that would be cool in some situations.


> - tempo is indeed influenced, to keep the model consitent with the
> sample stream and parameter values (for which only the plugin know
> what to do with in case of a change of SPEED, eg. LFO)

Yes. The whole point with giving SPEED to both sequencers and synths 
is to allow parallel scaling of the things that are *not* tempo or 
beat sync'ed.


> - for plugins or hosts that do not support the SPEED, the
> repositioning events are still usefull without the additional
> hinting from the SPEED control.

Again, repositioning events won't work. You have to scale the whole 
timeline, ie *both* position and tempo. If plugins really want to, 
they can still calculate the "nomilal" tempo from the actual TEMPO 
and SPEED. (I can't think of any plugin that should really do this, 
though. Who cares about 120 BPM if you're currently playing at 147.39 
BPM?)


> The SPEED only allows the plugins
> to generate usefull noise in case the user starts fiddling with it.

I would say that my external synths are quite useful when playing 
with half or double speed in Cakewalk, despite them not knowing 
anything about it. In fact, I would strongly advice *against* 
modulating the pitch with SPEED, unless it can be turned off.


> - essential is that the relation between media time and musical
> time is not changed! The whole perception of time is influenced.

Yes. That's why you should have the sequencer fake *everything*; not 
just flood the net with position changes. That would only result in 
skipping and sync loss with any plugins that don't do half of the 
scaling job themselves, based on SPEED.


> A nice real-life example of use for this SPEED control is the pitch
> control function as seen on CD decks and turntables. The DJ uses
> this control to manualy obtain and maintain beat sync between
> sources. Modern CD decks perform the SPEED changes without
> influencing the pitch of the song.

Yeah, this is exactly the effect I have in mind. With beatsync 
effects, you get it for free, but synths, samplers etc that have 
their own ideas about envelope timing and LFO frequencies will need 
to concider SPEED as well. (Should be rather easy with virtual analog 
synths and the like, but it's a lot harder with samplers.)


> When running a MIDI sequencer or drum machine in beat sync with a
> record, the dj (actually a gear jockey :-) simply fiddles with the
> tempo control to keep every thing grooving. The SPEED control I
> proposed would provide the additional abstraction layer to allow
> the plugins to be smart enough to keep the sample and event streams
> running smoothly together.

Yes. I like the idea.


> I have no clue how this would be beneficial to classical or indian
> style of music ;-)

Nor have I - except that the feature would be handy whenever you're 
editing music in a sequencer. Correct FFWD could be a great time 
saver.


> > > It's scary, but I
> > > guess correct...  Do we really want to deal with playing during
> > > shuttles?
> >
> > Yes, I think so. If?you've done some sequencing of music with
> > long notes (strings and stuff), I think you know how frustrating
> > it can be to play 6 bars just to hear if you got that edited note
> > right... :-)
> >
> > If you can just FFWD with playback to the place you're interested
> > in, samples and stuff may be out of sync, but at least, all the
> > notes will be there. (And the beat sync effects will be in sync,
> > BTW. :-)
>
> a plugin _could_ be in sync (of course depends on the plugin).

If you just scale the whole timeline, a tempo or beat sync plugin 
that doesn't track SPEED would be *broken*. It doesn't have to 
receive or understand SPEED to track the scaled timeline, any more 
than it has to when the timeline happens to sync to external SMPTE or 
whatever.


> Think of Sonic Foundry ACID. That is a in fact a sequencer which
> plays samples (looped or not), and performs real-time
> timestreching/pitch adjustment. The XAP API should certainly
> support a plugin with similar capabilities as ACID's
> playback/resampling engine.

Yes - and *that's* when you start sending SPEED to normal plugins. 

SPEED is basically a form of "tempo" for everything that isn't locked 
to musical time. If TEMPO is the speed of musical time, SPEED is the 
speed of time in relation to audio time. That is, where you would 
calculate a duration as

	duration = sample_rate * time;

you do

	duration = sample_rate * time / SPEED;

(Watch out for zero SPEED! If it is to be allowed, that is... Hard to 
get to negative if you don't have 0, though. :-)

Hmm... Great fun implementing bidirectional capable envelope 
generators... ;-) (And again, backwards play can only be half correct 
anyway, if the API is to be realistically possible to implement and 
use.)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list