19 Dec
2002
19 Dec
'02
1:31 p.m.
On Thursday 19 December 2002 17.51, Frank van de Pol wrote:
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.
On Thu, Dec 19, 2002 at 02:41:47PM +0100, David
Olofson wrote:
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.
On Thursday 19 December 2002 04.33, Tim Hockin
wrote:
Yes.
True, the effective tempo is negative, but think the SPEED control
should be decoupled. 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? - 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. :-) 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 ---