Re: [linux-audio-dev] XAP: a polemic

a tempo-sync-using plugin doesn't care about song position, true. it only cares about tempo at a given point. so yes, its correct to disconnect these. but keep in mind that some other plugins (possibly, or even likely) the same ones) will also care about transport information as well. if you take a look in ardour, you could consider its AudioTrack objects to be disk-based samplers. they operate quite differently depending on whether the transport is rolling or not (generating silence (after a declick!) if not, and streaming data to/from disk if it is). actually, probably not. you generally want to assume that the audio interface runs continuously - many hardware devices generates clicks when started, and in addition, if used in combination with other digital devices, you end up with sync/lock issues. good plan. i suggest forgetting this. VST sets it to 1 PPQN, and treats "QN" as "1 beat", so the information is really quite useless. there's no need for it given TEMPO and METER. they don't, except that they may move time in mysterious ways (stop it, move it at variable rates, move it backwards, etc). after much discussion about this on ardour-dev, we settled on beats per minute, where beats are whatever unit the time signature is using. for some music, the unit is irrelevant, because nothing else uses subdivisions of the beat note value in any coherent way (i.e. you can decide that a beat is a quarter note, or a half note or a whole note, and nothing else will care). for other music, its important that the beat value is known. well, i think you haven't yet defined quite how the plugin gets the information. after the discussion about callbacks, i return to favoring events delivered to a Well Known Control. to flesh out what you suggest about: SAMPLE_RATE (samples/sec, passed at instantiation) TEMPO (samples-per-beat, delivered as an event, see below) METER (beats-per-measure + beat-note-value, delivered as an event) the TEMPO event needs to include: samples-per-beat (as a floating point value) [ time between beats ] ramp slope (possibly 0) [ for accelerando and ritard ] ramp target (irrelevant if ramp slope is zero) [ ditto ] the METER event needs to include beats-per-measure (floating point value) [ 3, 5, 7, 9.5 etc ] beat-note-value (floating point value) [quarter,1/16th, etc] in addition to this, the host/API needs to provide two other functions: "get current time information" - the structure needs to be based on the VST time info structure. it will indicate the sample position of the next beat, and the next bar. it will indicate the state of the transport, including loop information in the way that JACK's time info structure does. it can only be called from the "process" handler of the plugin, because the information is all specific to the current block being processed. "convert musical time" - passed a musical time (B|b|t) and an indicator of which timeline to use, it returns the audio frame at which the event will occur, independent of transport state. if transport state matters, the plugin will have to handle that itself. this function doesn't require host information, but it does require a way to access a (possibly) shared timeline and it needs to be implemented only once :) i haven't followed the rest of the XAP discussion to know how Well Known Controls would be established, but if a plugin needs tempo sync it should go through whatever steps are necessary to define a "tempo" control, which will receive TEMPO and METER events as necessary. we might add a BEAT event, which would be delivered by the host on an intermittent basis, and would contain: beat number tick number sample position this will allow tempo-synced plugins to align to what has been called the tick edge. beats are sufficiently intermittent that this doesn't cause an event overload even if one is sent for every beat. however, there is no need to do this - it would be find to deliver one every time the transport state changes to "moving" so as to resync everybody who cares. --p