not quite. ticks exist to represent integer subdivisions of a beat. this is why the preferred ticks-per-beat values are numbers with large numbers of factors. for example, 1920 is a very good choice. if you use floats, then anyone wanting to subdivide a beat by, say, 12, will find that positional accuracy drifts. why? because 1/12 is irrational and cannot be accurately represented by a floating point value. if, by contrast, you express this 160 ticks, there is no loss of accuracy over any duration at all. why subdivide the beat? i presume this question doesn't need answering! --p ps. laurent - welcome to LAD! thanks for stopping by.

[Oops. Now I've done it all - this one was originally slightly over the 40 kB limit. *hehe*] On Tuesday 04 February 2003 03.04, Laurent de Soras [Ohm Force] wrote: Great! Welcome to the list. :-) Well, I made an awful lot of comments in one post there - but rather that than starting lots of theads... [...] [...] Yeah, I see your point. As soon as the meta-data is *anything* but pure, static data, plugin binaries will need code to generate it somewhere. From that POV, it does look cleaner to have each plugin "class" handle it's own meta-data in a lightweight state, than to pack it into a central plugin factory in each binary. If you have only one plugin per binary, it doesn't matter much, but single file plugin packs are really rather common and useful. It allows plugins to share code efficiently, and thus reduces cache thrashing. It also allows plugins to share "live" data in various ways. Just as an example, you could implement an oscilloscope bank (for testing, debugging and the general "imponance effect", of course :-) where a small plugin is used for tapping audio here and there, and another plugin is used to gather data from all the others and pass it to the GUI. (In our designs, the GUI is normally a physically separate part from the plugin. There are good reasons for this; read on.) [...] Yeah, I've thought about that too. Rather hairy stuff. The only easy way to avoid it is to strictly define what the host should tell the plugin before asking anything, and then just leave it at that. However, that doesn't allow any actual negotiation. OTOH, I'm not sure that's actually a problem. Hosts can still try various system parameters until they have a set of responses for all cases they care about. [...the "sequencer" thread...] Well, I don't get what this thread would be then. I was assuming it was something like the automation sequencer thread found in some VST hosts, but if it's not a sequencer at all...? My point being, when would a host thread that is not a sequencer nor an audio thread ever call a plugin? I don't see why plugins should have to know about the excistense of such things, if they never interact with them directly. Yeah, of course. That's why we want to avoid it at pretty much any cost. Who isn't confused...!? ;-) Yes. They use different GUI toolkits. That means, applications will have to link with different libs, and generally, these libs just don't mix, most importantly because virtually every GUI toolkit wants to take over the main loop and drive the application through callbacks or similar mechanisms. You generally can't have multiple toolkits running in the same process, even if you try running them in different threads. Exactly. If your host is a KDE app using Qt and you're a plugin using GTK+ (the toolkit used by GNOME as well as lots of non-GNOME apps), you're screwed. You GUI can't run in the host's process. Keeping GUIs as separate executables that are installed in parallel with the DSP plugins. For XAP, I'm thinking in terms of using an API very similar to the DSP plugin API. A GUI "plugin" would basically just have control inputs and outputs that match those of the DSP plugin, so the host can connect them like any two plugins, although through an RT/non-RT gateway and IPC, rather than the usual direct sender-to-port event passing. [...integrated GUIs, TDM etc...] Right. The only issue for local, in-process execution is with the GUI contra the host application. GUI and DSP will obviously run in different threads in any RT host, but that's as far apart you can get them. Running plugins on cluster supercomputers and the like just won't work, unless you can run the GUI on one machine and the DSP part on another. Of course, this applies to traditional Unix style server/workstation setups as well. You *can* still have them in the same binary, though, but if you do that, you have to make sure both parts have no external lib references that cannot be resolved in a GUI-only or DSP-only host. That is, you have to load any DSP plugin SDK lib, GUI toolkit libs and whatnot *dynamically*, which means you force extra non-optional and inherently non-portable code into every plugin. If you make GUIs standalone executables, you don't have to worry much about this, as they're really just normal applications, although with a few special command line arguments and the desire to run as clients to the host that spawns them. Well, if you make the GUIs use about the same API as the DSP plugins, this is left to the host and support libs. The host fires up a GUI and gives it a "context handle". The GUI uses an SDK lib to register itself, and doesn't have to worry about how the communication is done. (Shared memory, signals, messages, pipes, TCP/IP or whatever, depending on platform and system configuration.) The plugin will then basically be part of the processing net, and the host can connect it to the DSP plugin in a suitable fashion. (Directly, through the automation sequencer or whatever.) I think that's a bad idea. If all communication is done through the official API - even if some of the data is just raw blocks that only the plugin DSP and GUI understand - you can take advantage of the transport layer that is already there. The host makes it totally thread safe, and even makes the connections for you. DSP plugins don't need any API at all for this, as the normal control API is sufficient. It's also basically a requirement for some platforms. Enforcing a single, specific GUI toolkit simply isn't an option. You can provide something like VSTGUI (or maybe even VSTGUI? remains to see what license they chose...), but you can't *force* people to use it, and expect them to accept the API under those conditions. Lots of people use and love GTK+, Qt and FLTK, and there are a few other alternatives as well. Some just want to do raw low level graphics using SDL - and SDL (as of now) can only handle one window per process, regardless of platform. All of these have one thing in common: They don't mix well, if at all. [...tokens...] I know, but I still think it's a bad idea. Not the token deal in itself, but rather the fact that both hosts and plugins are explicitly aware of this stuff. I think there are cleaner and more flexible ways to do it. You would need a feature that allows control outputs to be marked as "active" or "passive". This allows hosts to control how things are handled. For examlpe, if you have a plugin, it's GUI (another plugin, basically) and an automation sequencer, the normal case would be that the automation sequencer sends recorded events to both the GUI and the DSP plugin. The latter is - as always - just supposed to do it's thing, while the former should track the incoming control changes. Now, if the user grabs a knob in the GUI, the GUI stops tracking input events for that control, marks the corresponding output as active, and starts transmitting instead. The automation sequencer would notice the change and (normally - although this is completely optional) pass the incoming control changes to the DSP plugin, and, if in record mode, record the events in the process. I don't think it gets cleaner and simpler than that - and note that this works just fine even if there is substantial latency between the GUI and the DSP host. The GUI never deals directly with the DSP plugin, but rather just looks at the events it receives, and sends events when it "feels like it". There will be no interleaved changes with my approach, since GUIs never explicitly send events to DSP plugins. In fact, you could say that they don't even know about the excistence of the DSP plugins - and indeed, you *could* run a GUI plugin against an automation sequencer only, if you like. (Not sure what use it would be, but I'm sure someone can think of something. :-) As to priorities, well, you could do that as well, but it's a host thing. In my example above, you'd connect the GUI plugin to the sequencer, and then the sequencer to the DSP plugin. The sequencer would react when the GUI toggles the active/passive "bit" of controls, and decide what to do based on that. The normal action would be to handle active/passive as a sort of punch in/out feature. I think just having active/passive flags on control outputs is both cleaner and more flexible. With tokens, a GUI has to be aware of the DSP plugin, and actually mess "directly" with it, one way or another, whereas the active/passive solution is just a control output feature. When you grab a knob, the control becomes active. When you let go, ti goes passive. DSP plugins could have the active/passive feature as well, although it would probably always be in the active state, and whatever you connect a control out from a DSP plugin to will most probably ignore it anyway. I think it's a good idea to make the feature universal, though, as it makes GUI plugins less special, and allows event processor plugins to be inserted between the GUI and the automation sequencer without screwing things up. It also allows the automation sequencer to appear as a normal plugin, whether it actually is a plugin, or integrated with the host. Yeah. But that makes it C++, since it definitely won't compile with a C compiler. You can do the same by putting things in structs - but indeed, there is a problem with enums and constants. However, namespaces don't really solve this; they just give it a different syntax and some type checking. The latter is nice, of course, but writing SomeNamespace::SomeSymbol instead of SomeNamespace_SomeSymbol... well, what's the point, really? [...VST style dispatcher...] I actually think having to try to *call* a function to find out whether it's supported or not is rather nasty... I'd rather take a look at the version field of the struct and chose what to do on a higher level, possibly by using different wrappers for different plugin versions. Likewise with plugins; if a plugin really supports older hosts, it could select implementations during initialization, rather than checking every host call in the middle of the battle. Yeah, that can be handy, but you might as well do that on the wrapper level. And monitoring multiple entry points isn't all that hard either. Why bother? That's exactly what a switch() becomes when you compile it... Anyway, for plugins, it seems simpler to just fill in a struct and stamp an API version on it, and then not worry more about it. I'd rather have as little extra logic in plugins as possible. [...] Yeah, I'm thinking along those lines as well, but I still think it's a problem with simple/fast plugins. (EQ inserts and the like.) It still becomes significant if you have lots of those in a virtual mixer or similar. I think this separation is a mistake. Of course, we can't have an API for complex monolith synths scale perfectly to modular synth units, but I don't see why one should explicitly prevent some scaling into that range. Not a major design goal, though; just something to keep in mind. Yeah, that's a good point. Good point. Not all plugins process everything one frame at a time. Especially not big monoliths like polyphonic synths... I still think plugins should be able to just have a simple hint to say "I'm in-place safe!" It's easy enough for hosts to check for this and make use of it when it can save cycles. There's nothing to it for plugins, and hosts can just assume that all plugins are in-place broken, if that makes things easier. Yeah, but when you need that, you just don't reuse the input buffers for the outputs. You're using the same callback for in-place processing, only passing the same buffers for some in/out pairs. Yeah, I know. That's part because the lack of a standardized output gain control makes the adding process call essentially useless to most hosts, but the point is still valid. (And it's the main reason why I made the FX plugin "SDK" in Audiality emulate all modes with whatever the plugin provides. I can just pick one of them and still have the plugin work everywhere.) Yeah. It might still be debatable whether or not the extra copying and buffers is a real performance issue, but let's just say, I'm not nearly as interested in these multiple calls now as I was just one or two years ago. I do believe a single "in-place capable" flag would be a rather nice thing to have, though, as it's something you get for free with many FX plugins, and because it's something hosts can make use of rather easilly if they want to. Not an incredible gain, maybe, but the feature costs next to nothing. There have been 256 bit GPUs for a while, although I'm not sure how "256 bit" they really are... Anyway, the point is that since SIMD extensions and memory busses are 128 bit already, it probably won't be long before we see 256 bits. Anyway, I'd think the alignment requirements are really a function of what the plugin uses, than what's available on the platform. However, managing this on a per-plugin basis seems messy and pointless. How about defining buffer alignment as "what works good for whatever extensions that are available on this hardware"...? Would mean 16 in most hosts on current hardware, but hosts would just up it to 32 or something when new CPUs arrive, if it gains anything for plugins that use the new extensions. Yeah, as soon as you have misalignment with the memory bus width, there will be performance issues in some cases, since you can't write to "odd" addresses without reading two memory words, modifying them and writing them back. The cache and memory subsystem normally deals with this through write combining, but obviously, that doesn't work too well unless you're doing contiguous blocks, and there's always a slight hit at the starts and ends of blocks. In real life, it also seems that many CPUs run slightly slower even when write combining *should* theoretically be able to deal with it. (I think early MMX had serious trouble with this, but SSE(2) is probably improved in that regard as well.) Ouch. Like old 68k CPUs... *heh* (Except 030+, which I learned the hard way, looking for bugs that "simply cannot happen"... :-) I think it's platform dependent and subject to change over time, and thus shouldn't be strictly specified in the API. [...] That's one way... I thought a lot about that for MAIA, but I'm not sure I like it. Using events becomes somewhat pointless when you change the rules and use another callback. Function calls are cleaner and easier for everyone for this kind of stuff. Anyway, I'm nervous about the (supposedly real time) connection event, as it's not obvious that any plugin can easilly handly connections in a real time safe manner. This is mostly up to the host, I think, but it's worth keeping this stuff in mind. As soon as something uses events, one has to consider the implications. A situation where inherently non RT safe actions *must* be performed in the process() call effectively makes the API useless for serious real time processing. I'd really rather not see all hosts forced to resort to faking the audio thread to plugins in non-RT threads, just to be able to use "everyday features" without compromising the audio thread. [...] This is what I do in Audiality, and it's probably the way it'll be done in XAP: * There is only one event for controls; RAMP. * The RAMP event brings an "aim point", expressed as <target_value, duration>. * A RAMP event with a duration of 0 instantly sets the control value to 'target_value', and stops any ramping in progress. (There are various reasons for this special case. Most importantly, it's actually required for correct ramping.) * A plugin is expected to approximate linear ramping from the current value to the target value. * A plugin may ignore the duraction field and always handle it as if it was zero; ie all RAMP events are treated as "SET" operations. * What happens if you let a plugin run beyond the last specified "aim point" is UNDEFINED! (For implementational reasons, most plugins will just keep ramping with the same slope "forever".) This is * Easy to handle for senders and receivers. * Involves only one receiver side conditional. (The duration == 0 test.) There are no conditionals on the sender side. * Allows non-ramped outputs to drive ramped inputs and vice versa. * Allows senders to let ramps run across several blocks without new events, if desired. * Makes accurate, click free ramping simple; senders don't have to actively track the current value of controls. * The "aim point" approach avoids rounding error build-up while ramping, since every new RAMP event effectively gives the receiver a new absolute reference. [...ramping...] Yes, that's one part of it. It would have plugins that approximate linear ramping (say, filters that ramp the internal coefficients instead) depend on the block size, which is a bad idea, IMO. Also, it drastically increases event traffic, since senders will have to post new RAMP events *both* for block boundaries *and* the nodes of the curves they're trying to implement. Finally, if plugins are supposed to stop ramping at a specific point, there are two issues: 1) This violates the basic principles of timestamped events to some extent, as you effectively have a single event with two timestamps, each with an explicit action to perform. 2) Plugins will have to implement this, which means they have to enqueue events for themselves, "poll" a lot of internal counters (one per control with ramping support), or similar. I think this is completely pointless, as senders will have to maintain a "solid" chain of events anyway, or there isn't much point with ramping. That is, a sender knows better than the receiver when to do what, and more specifically, it knows what to do at or before each aim point. It just sends a RAMP(value, 0) to stop at the target value, or (more commonly) another normal RAMP event, to continue ramping to some other value. [...voice IDs...] Virtual Voice IDs. Basically the same thing, although with an twist: Each VVID comes with an integer's worth of memory for the plugin to use in any way it wants. A synth can then do something like this: * Host creates a note context for 'vvid': host->vvids[vvid] = alloc_voice(); // If allocation fails, alloc_voice() // returns the index of a dead fake voice. * Host sends an event to voice 'vvid': MY_voice *v = voices[host->vvids[vvid]]; v->handle_event(...); * Host wants to terminate note context 'vvid': MY_voice *v = voices[host->vvids[vvid]]; v->free_when_done = 1; // The voice is now free to go too sleep // and return to the free pool when it's // done with any release phase or similar. That is, your look-up becomes two levels of indexing; first using the VVID in the host managed VVID entry table, and then using your very own index on whatever array you like. Obviously, senders will have to allocate VVIDs from the host, and the host will have to manage an array of VVID entries for plugins to use. If you consider a synth playing a massive composition with lots of continous voice controlling going on, I think this makes a huge difference, since *every* voice event is affected. If you have 128 voices, looking through on average 50% of them (or less if you use a hash table) for a few thousand events per second is wasting a whole lot of cycles. I might have misinterpreted some table. It said Hz, as if it was the unit of the pitch control... I see. (Same as Audiality, although I'm using 16:16 fixed point there, for various reasons.) Anyway, IMHO, assuming that the 12tET scale is somehow special enough to be regarded as the base of a generic pitch unit is a bit narrowminded. What'n wrong with 1.0/octave? That said, I can definitely see the use of something like 1.0/note, but that's a different thing. It just *happens* to map trivially to 12.0/octave linear pitch, but it is in no way equivalent. Units could be selected so that "note pitch" maps directly to linear pitch, so you don't need to perform actual conversion for 12tET (which *is* rather common, after all), but note pitch is still not the same things as linear pitch. [...] This is where it gets hairy. We prefer to think of scale tuning as something that is generally done by specialized plugins, or by whatever sends the events (host/sequencer) *before* the synths. That way, every synth doesn't have to implement scale support to be usable. As it is with VST, most plugins are essentially useless to people that don't use 12tET, unless multiple channels + pitch bend is a sufficient work-around. [...] And a continous pitch controller *could* just use a fixed value for Base Pitch and use Transpose as a linear pitch control, right? Yeah. The only part I don't like is assuming that Base Pitch isn't linear pitch, but effectively note pith, mapped in unknown ways. Syths are supposed to play the *pitch* you tell them. Scale converters integrated in synths are an idea that closely related to keyboard controllers, but doesn't really work for continous pitch controllers. When it comes to controlling their instruments, scales are not relevant to vocalists or players of the violin, fretless bass and whatnot. They just think of a pitch and sing it or play it. The connection with scales is in their brains; not in the instruments. [...] Right, but MIDI is integers, and the range defines the resolution. With floats, why have 2.0 if you can have 1.0...? That's defined by the meter. Anyway, what I'm suggesting is basically that this event should use the same format as the running musical time "counter" that any tempo or beat sync plugin would maintain. It seems easier to just count ticks, and then convert to beats, bars or whatever when you need those units. Yes. And bars and beats is just *one* valid unit for musical time. There's also SMPTE, hours/minutes/seconds, HDR audio time and other stuff. Why bars and beats of all these, rather than just some linear, single value representation? Could be seconds or ticks, but the latter make more sense as it's locked to the song even if the tempo is changed. Why? If you want more info, just convert "linear musical time" into whatever units you want. The host should provide means of translating back and forth, querying the relevant timeline. Accuracy is *not* infinite. In fact, you'll have fractions with more decimals that float or double can handle even in lots of hard quantized music, and the tick subdivisions used by most sequencers won't produce "clean" float values for much more than a few values. Whether or not this is a real problem is another matter. It would be for editing operations inside a sequencer, but if you're only playing back stuff, you're fine as long as you stay sample accurate. And if you record something from an event processor plugin, you're restricted to sample accurate timing anyway, unless you use non-integer event timestamps. [...] The host would of course know the range of each control, so the only *real* issue is that natural control values mean more work for hosts. There's another problem, though: In some cases, there are no obvious absolute limits. For this reason, we'd like to support "soft limits", that are only a recommendation or hint. Of course, that *could* be supported with hardcoded [0, 1] as well, just having frags indicating whether the low and high are hard limits or not. Yeah. Doing it in one place (the host SDK), once and for all, sounds better to me, though, and happens to be doable with the same information hosts need to construct GUIs for GUI-less plugins. A thought: You can actually have it both ways. For things that the lin/log, range, unit etc approach cannot cover, plugins can provide callbacks for conversion. If the standard hints fit, the host SDK provides all the host needs. If not, the host SDK forwards the requests to the plugin. Yes, of course. Ok. Then it's not what I thought - and not all that interesting either, IMHO. What's wrong with text and/or raw data controls? Speaking of GUIs (as external processes), these would effectively function like any plugins when connected to the host, and as such, they'd have their control values saved as well. So, just have some outputs for tab index and whatnot, and those will be saved as well. BTW, this makes me realize something that's prehaps pretty obvious, but should be pointed out: When an output is connected, the plugin must send an inital event to set the connected input to the current output value. (Other wise nothing will happen until the output *changes* - which might not happen at all.) What I just realized is that this gives us a perfect bonus feature. You can read the current output values from any plugins by just reconnecting the outputs and running process() once. That is, if you only want to save the current values at some point, you don't have to connect all outputs and process all data they generate. Just connect and take a peek when you need to. [...] Actually, I was thinking about the fact that GUIs talk directly to their DSP parts. I just don't like the idea of multiple senders being connected to the same input at the same time, no matter how it's maintained. And for other reasons, I don't like the idea of GUIs talking directly to DSP plugins at all, since it doesn't gain you anything if the GUI is out-of-process. It seems easier and cleaner to make the GUI part act more like a plugin than a host, and it also opens up a lot of possibilities without explicit API support. For example, you could implement visualization plugins as *only* GUI "plugins". The host could just do it's usual gateway thing it does for GUIs that belong to DSP plugins, but without the special connection management part. Just dump the gateway representation of the plugin in the net, and let the user hook it up as if it was a normal DSP plugin. If there's audio, it'll be async streaming back and forth, just like with events. Latency is "as low as possible" (ie no buffer queues), so this isn't usable for out-of-process audio processing, but it *is* usable for visualization. //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 ---