16 Dec
2002
16 Dec
'02
5:38 p.m.
On Monday 16 December 2002 06.12, Tim Hockin wrote:
I agree. If you care about transport events, you can find out that
you're not moving by other means. (Someone told you TRANSPORT_STOP...)
Uhm... Does anyone know!? ;-)
Still, is the
tempo 0, or whatever it is supposed to be at the
point where the transport is holding?
<My views>
Tempo remains in effect. Transport time is only meaningful to the
sequencer.
This is why you can't figure out how beat sync works.
Why should a plugin care what point in the song you
are
at? Why should a plugin care if the play-pointer moves?
That's the only way you can know where you are, in relation to the
rhythm. Indeed, you could give plugins something like a control that
ramps from 0.0 to 1.0 over each bar or each beat, but why bother to
make it a special case? Plugins can just take the song position and
fmod() it, run it through sin(), or whatever.
The full song position is exactly what you need, only part of the
information is irrelevant to you. So, you just remove it. Best part
is that you can lock to any time period you like, such as 16 quarter
notes.
Audio time (sample-count) runs endlessly (host can
actually stop it
if it can know there is nothing going on at all, perhaps - blocked
on user/MIDI - maybe). Because the sample-counter is tied to the
tick counter directly via tempo, rate, meter, and ppqn (modulo
tempo changes, which can come as events or whatnot)
Actually, it's not. It *can* be, but it can alse be sync'ed with
something external, such as a VCR or an external sequencer.
Either way, by the time you start processing each block, everything
*will* be tied together for the duration represented by that block,
or you wouldn't be able to do anything useful.
plugins don't
need to actually track what tick number they are on, just the
passing of ticks.
Again, what is a tick? One QN? One bar? (Whatever that is.)
If you decide on something for this, you also put an absolute maximum
limit on the period a plugin can deal with. If you get one tick/beat,
you can't lock to bars, unless they're one beat each. If you get one
tick/16th, you can lock to quarter notes.
Edge-dependent plugins, if there is such a
thing,
Anything beat sync'ed is. ("Auto Choppers", many kinds of
arpeggiators, beat sync tremolo, etc etc...)
can see when (samples_per_tick*ppq) samples has
elapsed and
know a beat has happened.
Nope. You must know where to start counting, or you have only tempo
sync; not positional lock.
For example, if you're "chopping" some audio with an envelope that
maps to 8ths, and ticks repeated for every 16th, you'd have a 50%
chance of being off by one 16th.
still jam on
and have tempo and beat sync effects roll, as if you
were looping an empty section in the song. As soon as you start
the sequencer again, though, beat sync effects will instantly
lock to the timeline.
Absolutely essential, IMHO.
Now, I've become very confused. What is it that we are arguing
about? We seem to all be talking in circles, so I'm going
to
describe what I understand and I want to steer the discussion
towards a solution :)
Sounds like a good idea.
* Host sends buffers of N samples to plugins, with a
starting
timestamp
* Things send timestamped events to plugins
* Timestamps are measured in whole audio samples
* Host/timeline must export/deliver:
- SAMPLE RATE (samples/sec - passed at instantiation)
- TEMPO (sec/tick - event?)
I don't think it's a great idea to mix frequency units with period
units in general. Unit should be ticks/<something>; either
ticks/second or ticks/sample. The latter makes more sense to me,
since audio time is the basic unit all plugins must deal with anyway.
- PPQN (ticks/qn - host-global? event? fixed?)
PPQN is irrelevant when dealing with fp timestamps. Just make it 1.0
or something.
- METER (units? - event?)
count / value (Two integers. Normally... :-)
* Plugins can track ticks by adding 1/(rate*tempo) to
a counter and
observing an integral boundary crossing.
Well, that's part of a solution, but see above, about positional sync.
So the questions that remain:
* what am I missing?
The positional sync issue, basically.
* how do external clocks tie in? (I know _nothing_
about them!)
They generally tell the sequencer what position on the timeline it
should be in at regular intervals. Obviously, this means that the
sequencer will have to chase or lock it's idea of musical time to
something that is not related to audio time at all. Thus, the
sequencer can only map musical time to audio time for one block at a
time. The sequencer can't know what will happen in the next cycle.
* units for meter (I don't know enough music
theory to answer
properly)
Well, I suggested the only unit I've seen used - but there might be
more generic formats.
* can we take any of this tracking work away from the
plugins?
Well, if you don't care about musical time, there's no tracking work
at all to do. Just look at the timestamps and process audio.
I've suggested earlier how you would handle TEMPO and POSITION_CHANGE
events. I can post real code, if needed.
This argument is getting tired - lets resolve it..
I suspect that the easiest way would be for some of us to implement
our ideas, so they can be demonstrated and tested in real life
situations.
Seriously - too much of this discussion is a waste of bandwidth,
caused missunderstandings and the general complexity of the problem
space. If we can't get anywhere with english, let's try C, C++ or
whatever.
//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 ---