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

On Sunday 15 December 2002 06.23, Tim Hockin wrote: Well, my "guess" (not really) is that most plugins will need the audio timestamps, *even* when they deal with musical time. Whenever you actually need to *do* something, you'll need the audio timestamp, because that's effectively real time to you. You can't even tell if an event is within the current block, unless you convert one way or the other. I've considered that, but remember that musical time is absolute and non-wrapping. A float has only 24 bits of accuracy, so it will drop below sample accuracy rather quickly. My events look something like this, so far: typedef struct XAP_event { struct XAP_event *next; XAP_timestamp when; /* When to process */ XAP_ui32 action; /* What to do */ XAP_ui32 target; /* Target Cookie */ XAP_f32 value; /* Value/Ramp Target */ XAP_f32 slope; /* Ramp Target Slope */ XAP_ui32 count; /* Ramp Duration */ XAP_ui32 id; /* VVID */ } XAP_event; You'll need all these fields at once when sending control ramp events to voices, so unions won't help. The struct is exactly 32 bytes, so we're going to end up with 64 byte events if we add anything. On big deal, maybe. (64 bit platforms will need an extra 4 bytes for 'next' anyway.) More importantly, it would mean that everyone that sends events have to calculate *both* timestamps for every event. And what do you do if there is no timeline at all? 0.0? (That would make the timestamp useless, as described before.) Well, you do expect a beat synced effect to track the *beat*, right? Now, if you have two timelines running at different tempi, which one do you track? I'm not sure it's a good idea to ignore this, just because *most* people never do this sort of stuff. I've mentioned that it can be handy when creating soundscapes, and I'd guess there are more applications for it. So, if it doesn't complicate the API significantly, why not just do it right? [...] But telling a beat synced LFO what note value the beat is is ok? (Well, it can't be avoided.) You're forgetting that it's not the *host* that handles this. The host is not necessarily the sequencer, and thus, it may not even know what a timeline is. If you have the timeline interface in the host struct, who tells the host about the timeline...? Why special case it like this? Why not just have Control inputs named TEMPO, TRANSPORT and METER? Then you could also have plugins with corresponding outputs - or just build those outputs into the host, if you don't want to make the sequencer a real plugin. You don't need to request anything from anywhere; just say that you have TEMPO, TRANSPORT and/or METER control - input and/or output. Just as if they were ordinary controls. They need different event types, but that applies to string and raw data controls as well. And this just makes them easier to handle. Yes, but each plugin would be able to know about only one timeline. One may argue that this restriction doesn't matter much, but then again, we could just assume that no one uses multiple timelines at al. Where to draw the line? Anyway, if you throw these things in as normal controls, they become per-Channel for free. They're just ordinary connections, from the internals all the way up to the UI. If your plugin does not work without timeline input, it is broken. Your internal tempo will be 0.0, and your sound position will stand still at 0.0. You won't hear anything about TRANSPORT_START or TRANSPORT_STOP. No meter changes either, obviously. So what? Same things as if the sequencer is stopped. Have a default value for tempo, or something. (Just an f64 control...) Do you expect a synth to play anything but some default frequency, without pitch input? :-) //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 ---