On Monday 16 December 2002 06.12, Tim Hockin wrote: > > 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.
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...) > 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? Uhm... Does anyone know!? ;-) > 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 ---