Juuso Alasuutari &lt;juuso.alasuutari(a)gmail.com&gt; writes: Yes, but I havent researched it a lot. Something like it is good candidate to include in a LV2 host (read Zynjacku). Currently I use self made allocator, a simplified replica of Linux kernel mode slab allocator (that provides atomic allocation). -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Thursday 08 November 2007, Stefano D'Angelo wrote: [...] Yes, that's exactly my point, but I think it needs to deal with arbitrary size chunks to actually be able to serve that purpose in real applications. To avoid plugins effectively allocating private pools (just as if they'd implemented it internally), a host would have to use a proper real time memory manager, and then, whey not just make that available directly to plugins? Because it's never needed. When you free a memory block you're really just saying "I don't need this any more", and you don't care if/when the host does anything about it. BTW, are the blocking allocation calls intended for background threads...? Wouldn't it be more useful with some interface that allows plugins to request memory in a non-blocking manner, and if instant allocation fails, have the host notify the plugin when the memory is available? Basically, a malloc() call that means "If I can't have this memory right away, please expand the pool so I can have it later!" The alternative would be to use the blocking version only in "background" threads, but unless you need background threads anyway, to do actual work, this is just moving complexity into plugins for no gain. If a plugin wants some memory to play around with "in the near future", it shouldn't have to implement it's own asynchronous memory management just to avoid stalling the host's audio thread. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

2007/11/8, David Olofson &lt;david(a)olofson.net&gt;et>: IIRC the TLSF allocator can do that. Maybe because the host might want to keep track of memory allocations (think about debug mode) or maybe it needs a rt-safe allocator too (for example, the host can manage a network of plugins which can be modified while it is running - maybe CLAM does that too)? Ah, ok. Understood :-) Mmmm.. I guess it's not easy to resize the pool in a rt-safe way. And even if you have some background thread doing it when it's needed, I think it's very hard to do that while plugins are running, and so allocating and modifying on that memory. I agree. Stefano

2007/11/9, David Olofson &lt;david(a)olofson.net&gt;et>: Argh! I remember this way too. Maybe I just don't understand, but however doesn't this mean, in practice, allocating all of the memory right from the start? In such case, why should you do something like that? Mmmm... in my opinion someone could contact the TLSF authors and see what can be done. However, I was thinking something like this: IIRC the TLSF allocator uses a bitmap with chunks of different size, covering the whole pool, which is built when the allocator is instantiated. Then, when you request some piece of memory, it starts looking for it from the block of minimum size which could be used, and then continues looking for the next block available (which is by construction equal or bigger in size then the first). The address of the first block can be resolved with a O(1) algorithm. I was thinking that when the memory is "near to saturation", the allocator could malloc() a new pool whose size is equal to that of the first pool (maybe using a background thread) so that the bitmap for the new pool is actually the same. Now the address resolving algorithm should know in some way that the first pool is full for blocks of that size or bigger, so the adress should be resolved in the second pool, and so on. This is just a thought... I never really wrote or worked on an allocator :-) Anyway, getting back to the initial question, I think that we should have two separate extensions, one for RT fixed size allocators and one for "real" RT-safe allocators. Stefano

2007/11/9, David Olofson &lt;david(a)olofson.net&gt;et>: Wonderful ;-P Ah ok, but that would mean being sure that the new pool will be contiguous to the first one. Then, if TLSF works as I remember, you would have to either rearrange the bitamp (which could bring to a big amount of fragmentation too) or have the second bitmap logically equivalent to the first, and that is in practice what I was suggesting, except for the contiguity. :-) Cool :-) Yep. Yes, some clever trick should be found. :-) Maybe one could make use some trick based on the particular geometry of TLSF pools and relative bitmaps. This is a problem as well :-\ [heresy mode on] Maybe change values passed to/returned from the allocation/deallocation calls? [heresy mode off] It's just that I'm a bit a "purist", however I do agree that maybe your suggestion could solve the problem, at least until someone goes deep into TLSF logic. Of course... but also a nice challenging task (which could let you go insane) :-) Fine :-) However I would like to hear something from some plugin developer too. Stefano

2007/11/9, David Olofson &lt;david(a)olofson.net&gt;et>: Maybe I'm just ignorant (probably), but doesn't preallocation mean "allocate but don't use"? Or to better say you malloc() such areas but don't use them with the rt allocator? If this is the case, why would you do that? Wouldn't it be easier and more logical to just use all the allocated memory right from the start? However I was thinking about the situation in which all the allocated memory is full, so either you just can't allocate any more memory or resize the pool. Another newbie question: how do you know how much memory you can need (without user intervention)? I meant a mathematical trick based on the algorithm ;-) The fact is that, IIRC, memory blocks are arranged with some kind of mathematical distribution (linear? quadratic?) by increasing size, so with the bitmap you maybe can know with a couple of instructions what's the maximum allocable size on the pool, or using some other "trick". Glad to know that, I think I will use it in the future and portability is one of my main concerns :-) You said that too :-P See above. Nothing very dangerous actually. I just meant that you could use some more "non standard" parameters to use with allocator functions to do some "trick" :-) Of course. True. Nice solution. I guess, on the top of my ignorance, that those blocks are fixed size, right? (ehm... at first glance Audality seems quite interesting for my project - http://naspro.sourceforge.net -, can I contact you privately about that? or maybe just send me an e-mail) Insanely excellent ;-) [...] Stefano

"Stefano D'Angelo" &lt;zanga.mail(a)gmail.com&gt; writes: Because I dont see need for it. Even worse, I think it will add complexity because each plugin would need to know if it allocated memory during instantiation or afterward. In lv2dynparam I even use additional abstraction that uses single allocation function with mode associated with poll handle. pool is initally in sleey mode (during initialization) and before starting to do real work it switches to atomic (i.e. not sleepy) mode. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Thursday 08 November 2007, Krzysztof Foltman wrote: [...] Unless you're running the plugins on different cores or CPUs, wouldn't separate pools just hurt, no matter what...? Cache locality is the very reason why you *don't* want statically allocated per-plugin buffers for audio transfer and stuff like that. Do you have a specific example where per-plugin pools would improve things? Yeah, that's why I suggested TLSF. :-) Now, there are two issues with the TLSF implementations I know of: 1) They don't support resizing the pool on the fly. 2) They don't support 64 bit environments. The latter should be easy to fix, I think (use sizeof(void *) for alignment, basically), but resizing the pool might require some redesign of the algorithm. I'll need a hard RT memory manager that deals with both of these issues for my EEL scripting engine, so I'm rather interested in this particular issue, whether or not it goes into an LV2 extension. [...] //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

Nedko Arnaudov wrote: I only mean, level 3 host must support the custom GUIs if plugin has them - it was thought to be a kind of incentive for host makers to implement the most crucial features in order to get bragging rights :) There will be less hosts than plugins, so it is important that host makers get it right in the first place. Then, users would drive plugin authors to start making use of "high level" spec features (like, custom GUI or MIDI ports). They would basically bitch and moan until plugin devs start showing parameters in Hertz instead of arbitrary units, until everything has GUIs, until parameters are handled in sample-accurate way etc. That was my experience from Buzz community at least. Users were pushing devs to add more and more advanced features (and devs were pushing oskari to add more advanced features in Buzz machine spec). Of course, what worked there doesn't have to work in open source community. But it might be worth trying. Which is a kind of hell for end users, isn't it? :) (at least to some degree), or determining compatibility should be as simple as possible (ie. plugin says level 3 and host says level 4 - so the plugin will work well in that host). Musicians aren't necessarily technically-minded, and some stuff, even simple to us, may simply scare them off, just because it *seems* complex :) Test suite must happen at some point - I might do some work for that too. It doesn't have to be something big, in simplest case it would just be a set of short programs/plugins full of asserts :) Certification is the possible next step, but not a requirement. The test suite is basically designed to help devs write correct code, not to force them to do so. Encouraging them to do so is more of reputation thing (if someone writes buggy plugins, he will be complained to on mailing lists, irc channels, and his work won't be included in distributions etc). I think whether it will be open or closed source is irrelevant - the main goal of the compliance level is a helpful, structured development process, where: 1) compliance bugs are caught before the plugin is released, eliminating the problem of buggy plugins in circulation (unless the developers don't use the test suite at all, but then it's either their bad decision that will cost them reputation or bad test suite that will cost me reputation) 2) host authors are encouraged to add features in a predictable order (they can always add level 4 features without level 2, but then they can't brag about level 2 compliance) 3) when - say - 100% of hosts support level 1, 50% of hosts support level 2 and 25% of hosts support level 3, the plugin authors would first want to make use of level 2 additions, then level 3 additions etc - basically, concentrate on this kind of work that makes the most of end users happy with them (as in: what's the point of doing level 4 additions when no host does level 4 - except for doing it for fun) Of course, I'm not saying the model would always be used - just it would be the expected case the audio scene could (hopefully) slowly converge to. Krzysztof

On Thu, 2007-11-08 at 14:24 +0000, Krzysztof Foltman wrote: That may be a good idea for the future, but for now it's more important that the core spec is released. After that anyone can define extension sets or compatibility levels. The core spec has taken too long already, if it has to wait for more extensions and other additonal structure it will never ever be finished. That is the sole reason I do any hacking at all. =) --ll

Krzysztof Foltman &lt;wdev(a)foltman.com&gt; writes: AFAIK ATM there is support only for port proprties. enums should be probably in the core spec (as with other "primitive" port types for parameters). logarithmic and user rendered should be probably extensions. There is http://ll-plugins.nongnu.org/lv2/ext/gtk2gui/ and i think drobilla and larsl came with something improved (not gtk specific maybe). ATM I use it through slv2 (with some limitations). glade extension could be cool. it works for me :) extension for this that would be cool! Uhm, as we talked earlier, I'd prefer several levels. Including not-instant change. I think this can be described in the RDF file This looks like new port type to me (another extension). I'll soon need to have this port type for lv2zynadd (low update frequency however). That can be useful, however I personally prefer simple plugins with host providing most of features. Is this feature inteded for custom GUIs, generic ones or both? I think it is this way already with existing GUI (GTK?) extension. Can be useful, no use for apps I work on. I think this is host responsibility. I personally avoid untyped (including blobs) communication between host and plugins. This can be useful. I'd like CC to be bound to parameters. I.e. suggested CC for this parameter is "portamento". Yup :) Pretty useful, some IIRC other ppl in #lad wanted this extension too. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Tue, 2007-11-13 at 13:08 +0000, Krzysztof Foltman wrote: Not sure if there are any. I think it's mostly about getting everything together and writing some docs. Not really. If a new version of a plugin is completely compatible with the old one (e.g. just bugfixes or a nicer GUI) it should have the same URI, and the hosts will treat it as an identical plugin. If not, it should have a different URI and the hosts will treat it as a completely different plugin. There is no way to specify that a plugin is backwards compatible with another one and maybe can use presets for it or be used as a drop-in replacement with suitable port mappings. Maybe an extension could be defined for that if a pressing need arises. There is a GTK+ GUI extension, although not stable. The GUIs are loaded from shared modules listed in the RDF files, just as plugins, so it can be up to the host whether they are loaded in the same process as the plugins or in another IPC/RPC-controlled one. There is no generic loader for them though, that might be useful. Well, IEEE754 doubles have 52 fraction bits so they can be at least as sample accurate as 32 bit integers. I agree that most hosts and plugins will not use sub-sample precision, but one cast per event isn't that expensive. Agreed. This would be a trivial extension, you could just define a port hint that said that a certain control input port should be fed the current BPM value. A complete transport sync mechanism would be more complex but also more useful - think loopers, record/playback plugins, automatic arpeggiators. There are a couple of different extensions in development for sending non-RT-safe commands to plugins. Don't know if there's anything stable yet. There's nothing published anywhere, but I've been bundling SVG 1.0 icons with some plugins and pointing to them with a triple in the RDF data files. The SVN version of Ingen shows them in the plugin menu and on the canvas modules. Wouldn't full-blown GUIs be more suitable for this? I've been using them for things like meters and fancy controls: http://ll-plugins.sourceforge.net/ogg/bling.ogg (the blue thing is a GUI for an LV2 port of Gordon Pearce's Nekobee) There is a Units extension that can be used to define units for ports (linked from the spec page, I think) and the core spec has scalePoints, which allows plugins to define labeled port values (e.g. "0 dB" for the multiplier value 1.0 on a simple gain plugin). See above. I don't think there's anything for this yet, but it shouldn't be hard to do in an extension - there are well-defined mechanisms for adding host and plugin callbacks using "Features". Or maybe it could be done as an input port class. It isn't strictly necessary though, e.g. WhySynth works OK as a DSSI without it and it has lots and lots of control ports. But yeah, it might be nice. Yes, session management will be crucial, especially when we allow arbitrary extensions that may change the plugin state in all sorts of weird ways. I don't think there's anything that does this in a generic way at the moment. LADSPA doesn't really need it since its only I/O method is the ports. Sure, a plugin can theoretically change it's internal state during a session to something that is completely different from what you get if you re-initialise it with the same control input values, but I don't think there are (m)any LADSPA plugins like that at the moment. I want dynamic note names too, so if no one else does that extension I might (at some unspecified time in the far future). Not sure if the plugin needs to be aware of dynamic CC mappings though, that can be handled completely by the host - the plugin just needs to provide defaults. Haven't looked much at this yet. I agree that there probably isn't a pressing need for it, but it would be nice to have. It could also be used for dynamic polyphony in synth plugins, with host access to the individual voices. --ll

On Tue, 2007-11-13 at 15:52 +0000, Krzysztof Foltman wrote: No. It sounds very similar to the input-parameter-has-changed thing - maybe both could be solved by defining a new port class whose buffer pointer points to a bitmask large enough to hold one bit for each plugin port, and using that to indicate when something has "happened" at a port (where the definition of a "happening" depends on the port class) ? There also are extensions in development (I think) that only call plugin callbacks if there actually is relevant input, but I think that was more for message passing and things like that. This definitely sounds very useful. Yes, API stability, which will obviously have to wait until after LV2 is released. Fixed size MIDI events means no SysEx messages though. Obviously there are better mechanisms than SysEx for common things like sample dumps, but it may still be nice to be able to send small chunks of arbitrary data over MIDI without having to translate it to something else when passing it to an LV2 plugin. Yes and no. Since extensions to the core LV2 spec can define new port classes that may need new ways of reading and writing data the GUI <-> plugin communication API needs to be extendable as well. The GUI has a generic port_event(uint32_t index, void* data) function, and the host provides a write_port(uint32_t index, void* data) function. The way it works is that the GUI specifies which plugin ports it wants to receive data from, and requires "Features" for the port classes of those ports and those that it is planning to write to. These Features work like normal lv2:Features - if the host does not support a required Feature it is not allowed to load the GUI - and specify when and how the host should call port_event() and what it should do with data passed to write_port(). The only port class that a GUI host must know how to deal with is control ports, for which it should call port_event() when the port value changes, change the port value when write_port() is called, and interpret the data pointer as a pointer to a single float containing the new value. There is an unpublished Feature like this for MIDI as well, which is implemented in Ingen and my experimental host. That they are defined on a per-preset basis doesn't mean that the host can't handle them, if it also handles the presets. After all, if the host already knows how to save and restore the state of a plugin (which it should to enable session saving) it pretty much knows everything needed for presets. The plugin can define some standard presets in it's data files, but it doesn't have to actually manage them itself. This is how I do it in my experimental host and plugins. --ll

On Tuesday 13 November 2007, Lars Luthman wrote: [...] I would think that users might want some way of "upgrading" their project files to use new plugin versions without just manually ripping out and replacing plugins, but even without some API help, I'd rather not see hosts trying to do this automatically... If you actually don't have the original version of the plugin installed anymore, the host should ask the user how to deal with that (suggesting a newer, partially compatible version of the plugin if there is one), but again, no silent automatic upgrades, please. Too much risk of the new version not working as expected. [...] For now, I decided on 16:16 fixed point timestamps for the top secret Audiality 2 rewrite (DOH!), because the event loop deals in integers (audio sample frames), and because there'll be some integer/fixed point DSP in there. As to sub-sample accurate timestamps, these are required for granular synthesis implemented as separate plugins. It just sounds horrible as soon as you try to generate tones rather than random noise "clouds". Other than that, I'm not sure it has much value outside of marketing... Any other real uses, anyone? (bpm-synced There was quite a bit of discussion on this way back in the MuCoS/MAIA and XAP days, IIRC. Short version, as I remember it: Plugins that want it can have a "music time" input port where they receive sample accurate updates on transport state. Advanced plugins could handle loop points and other jumps as they occur, but your average arpeggiator or similar would probably do reasonably well by just tracking tempo and position. (You need the latter unless you "synchronize" only on note events or similar.) [...] Makes sense to me. An "icon" like this is basically just a small GUI that doesn't take any user input. (Well, it *could*, but shouldn't rely on it, as a host really using it as an icon probably wouldn't care to let it have any input events...) [...] Somewhere around here is where I'd suggest using a "notification" style control interface instead - ie function calls, VST 1 style, or events of some sort. ;-) [...] Just realized that relationship too, but I'm not totally sure about the details yet. I'm probably going to try a 2D addressing approach; some ports may have multiple connections wired to different abstract instances of things (mixer voices, synth voices...) in the plugin. The words "dynamic voice allocation" keeps turning up - but I think it's just an illusion. Strictly speaking, MIDI doesn't have that! Each note number is effectively also a virtual voice ID, and there are only 128 of them per channel, implicitly preallocated as soon as you have a MIDI channel ready for input. Is that (not being able to allocate hundreds or thousands of voices at any time, real time safe) an actual restriction to anyone...? A sequencer would generally have some fixed upper limit to the number of voices it can control, and with the exception of live recording, it can even figure out exactly how many voices it needs to control at once, maximum, for the currently loaded performance. I don't see a real problem here. //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

On Wed, 2007-11-14 at 12:43 +0000, Krzysztof Foltman wrote: These types of "mini-GUIs" could certainly be useful. My point was that there is no need for a separate "icon GUI" extension, something like that pretty much requires a complete widget library to be really useful anyway and the GTK+ extension already supports multiple GUIs per plugin and embedding them on a canvas or in its own window or anywhere the host wants it. The only thing needed to distinguish between small "icon" GUIs and large "editor" GUIs would be some sort of annotation in the RDF data (that hosts would be free to ignore if they wanted to). --ll

On Wednesday 14 November 2007, Krzysztof Foltman wrote: Provided plugins are identified by URIs, and same URI implies 100% compatibility, how do you actually find the new version of the plugin? Then again, in that case, we're really talking about a brand new plugin, but it seems to me that there is some useful grayzone here; plugins that are mostly compatible with their predecessors. New major versions, if you like. Provide a version history in the form of an array of URIs, so hosts can find and deal with this if desired? Just brainstorming a little here... Well, considering we're still talking about 100% compatibility (the new version has the same unique ID), it *should* work - but in reality, it all comes down to the quality of the plugins, or rather, how well they actually maintain this claimed compatibility. Yes... Just putting a warning messagi in some log or something could be a very useful "debugging" tool. If it doesn't sound right, you start by having a look at that log. Right; everyone *thinks* their bug fixed versions are 101% compatible with the old versions - so next thing, hosts start overriding the override feature. :-D [...] Yep, that's what I had in mind. (Absolute time definitely belongs in some optional dedicated timeline interface.) Exactly. And besides, even when you do use the fraction part, you'll normally *only* be interested in the fractional part. Assuming you're implementing sample accurate timing first (why bother with sub-sample otherwise?), you're already at the very sample the event should "land" in, so you just want to know how much to nudge that initial oscillator phace, or whatever you need to do. [...] So, a different interface for control events that just happen to have fractional timestamps? Well, it does the job as far as dedicated granular synth "plugin packs" go, but then you can't mix these ports with other control ports. I was kind of thinking truly modular synthesis here... :-) Yeah, that actually sounds like an interesting application. Just a moment ago, I realized it can be used for things like "multilooping", skipping into samples and the like, similar to the "sampleoffset" command found in some old trackers. That sounds like modular synth stuff again, though. (Implementing advanced looping effects as a separate plugins, instead of building all features you can think of into the sampler, only to still forget half of the ones you actually want.) That is, it's probably going into Audiality 2, but it may not make sense in LV2. [...timeline/transport...] I prefer the latter, actually. If it's just two values, it doesn't really need a dedicated interface, I think. That way, you could even throw in standard event processor plugins to mess with these. Add some suitably colored noise and you've just humanized the arpeggiator. :-) The bad news is that doing this without the right calculations means tempo and position start to disagree, potentially confusing the plugin that tries to track them. OTOH, you can't really assume that integrating tempo gives you position and vice versa anyway... Consider a sequencer that's changing the tempo using linear ramping. Should it send one tempo event per sample frame? If not, should tempo values be instantaneous tempo corresponding to the respective timestamps, or should it be based on integrated position? My vote: Relax the relation and assume that sequencers will generally deal in instantaneous values. Tracking this data means you look at tempo for relative timing, and position for absolute timing, assuming no exact relation between them. In fact, this results in a useful bonus feature: A sequencer could *deliberately* send nominal tempo while advancing position at a different speed, to implement half/double speed without having arpeegiators and whatnot going totally insane. Either way, it's just some values physically, so as far as normal timeline functionality is concerned, the plugins just need to get that information one way or another. Sure. Maybe the plugin should somehow be told what the host expects? (Icon, metering, status, master control(s) etc.) Kind of silly if you render a master volume slider that can't be operated in some hosts. :-) [...very sensible examples elided...] Absolutely - and I think it can be of use outside modular synths as well. Why not render a column of "icon GUIs" instead of just plugin names in the insert effect box? (The host might want to reserve the right to use at least one mouse button for calling up the full GUI there - but then again, you'd probably want that in a modular synth as well...) Indeed; it's just that it brings the interface complexity closer to timestamped events without actually adding more than a small part of the functionality. Indeed, it's optional, but I have this funny idea that features like that are actually meant to be used. ;-) Yep. Well, in the context of Audiality 2, it's actually not the *host* doing any of this, as connections and protocols are mostly opaque. (The host just tells the plugins to make a connection, and that's that. Depending on the protocol, there could be a single float value, an audio buffer, an event queue or whatever in between, with each port having a pointer to it.) This has some implications as to how protocols are implemented, as you can't just shift complexity in any specific direction (that would be, towards the host), as there is normally plugin code on both sides, with just some shared data in between. Yeah, that's why I'd never consider that approach for audio. It has more overhead than timestamped events, can't handle sample accurate timing (*) and doesn't scale well at all. (*) Well, the calls can obviously pass timestamps, but that does exactly nothing to help plugins implement it. Instead, each plugin has to implement it's own internal event system or similar to be able to make use of the timestamps. Meanwhile, with the DSSI/XAP/Audiality approach, you just loop reading events, checking timestames and processing audio. This interface model is a perfect fit for the implementation in most cases. And, it's still easy to quantize event processing as needed if your inner loop has some granularity > 1 sample frame. Now you lost me... In what way does the value type affect this? [...] Indeed, I'm trying hard, but keeping it *too* simple just offloads a heap of issues to the implementations. Polyphonic synth control is a requirement in the case of my application, so I'm trying to figure out some nice solution that, if possible, can also be used for other stuff. Right now, plain 2D indexing seems to be it; one fixed dimension and one dynamic, corresponding to "what ports I provide" and "how many of them", respectively. For example, your average polyphonic synth would have a number of global controls with only one instance of each, and a number of voice controls of which there is one per allocated (potentially virtual) voice. It could also have a number of output mixer controls, where you use the the second dimension for addressing busses - that is, a separate 2D matrix of controls, independent of the one for voices. This should cover most interesting cases, right? Yes, that's what I'm thinking - and unless you're dealing in that kind of numbers, you could either be smart and only allocate exactly as many voices as you'll need, or you just grab a sufficient number of them. Real time MIDI input might actually be the worst realistic case here, and if you want to be *totally* safe, you just grab 128 voices per channel and index them directly using NoteOn/Off pitch. Realistically, you'll probably do just fine with some 16-32 voices for all practical matters. Make it a parameter of the MIDI->event mapper, in case some users have lots of fingers. ;-) (Note: The sustain pedal is just a control, and it's implementation is entirely down to the synth implementation, regardless of how voice addressing is done. I'm really talking about virtual voices here; not direct addressing of physical voices - although that's really just a synth implementation detail, just as it is with MIDI.) I totally agree. Exactly. What I call "voice addressing" is really just what MIDI is (ab)using the pitch field for: Telling the synth which *note* I'm talking about, regardless of whatever it might be wired to inside the synth ATM - if it's even wired at all. Well, MIDI has this too - although it's very limited: All you've got is NoteOn, NoteOff and Poly Pressure. :-) (IIRC, you can do more than that with some extensions, but this doesn't seem to be widely implemented.) I think what we want is for synths to be able to have any number of voice controls (corresponding to MIDI Poly Pressure), just as they can have any number of plugin wide controls (corresponding to MIDI CCs). [...] Actually, no, you need this to be able to stop the notes as well (another voice control event, just as for MIDI) - so it really does come down to how many notes you want to have playing at once. I don't care much for channels in the context of plugins (a plugin instance is a "channel" in my view), but that's another discussion. :-) Well, in the case of Audiality, this is a non-issue. You just hook up controls for 1024 voices, if you want that many. The only "problem" here is that you may not be able to do this on the fly, in real time, since the plugin most probably has to allocate more internal state memory to handle new connections. (Then again, that's not a critical issue in Audiality either, as it allows custom memory managers. Throw in a TLSF allocator with a "sufficiently large" pool, and you're fine, as long as plugins are reasonably quick at initialize new voices.) Wouldn't know about stage lights, but MIDI works pretty well for most people doing reasonably "normal" music. What we're talking about here is mostly beyond MIDI, and some people (users and developers alike) would probably consider the very concept of voice control beyond NoteOn/NoteOff overdesign. Meawhile, some people are using one MIDI channel per voice to work around the limitations of MIDI... Either way, once you have voice control *at all* - and this is required to implement NoteOff - with a proper design, I think generic voice controls come more or less for free. It would probably be good manners for synths to provide a plugin wide pitch control to simulate "good old" MIDI Pitch Bend (you could use it for tuning too, I guess...), so voice control opponents can stay away from using voice controls entirely. ;-) //David Olofson - Programmer, Composer, Open Source Advocate .------- http://olofson.net - Games, SDL examples -------. | http://zeespace.net - 2.5D rendering engine | | http://audiality.org - Music/audio engine | | http://eel.olofson.net - Real time scripting | '-- http://www.reologica.se - Rheology instrumentation --'

Steve Harris &lt;steve(a)plugin.org.uk&gt; writes: version history in form of an array of URIs makes sense to me too -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Lars Luthman wrote: The extension looks very good, but I would recommend adding two important units - semitone and cent (in case anyone doesn't know, a cent = 1/100 of a semitone). Semitones - useful for osc transpose in synths, as well as shift amount in pitch shift modules. Cents - useful for relative detune in synths. I think those are much more common than, say, miles :) Krzysztof