Lars Luthman wrote:
> as a drop-in replacement with suitable port mappings. Maybe an extension
> could be defined for that if a pressing need arises.
It has arisen in the past, and it will arise if the standard gets
popular, most likely sooner than you expect. It would be nice to solve
it somehow before many big synths get released as LV2.
One more thing - is there any way to communicate lack of data on an
audio port? For example, a synth with no note plugin could communicate
the fact that it produced a buffer full of zeros to the following
plugins, so they don't process those zeros unnecessarily?
My approach to that (basically multi-channel extension to Buzz approach)
was to define the process audio function in the way similar to:
uint32_t process_audio(uint32_t numsamples, uint32_t nonzero_inputs);
The function would disregard all inputs that have their corresponding
bits in nonzero_inputs set to zero. It would also return a bitmask
determining which outputs were set to non-zero values. For example, an
amp plugin with gain set to -inf dB would always return 0, without even
filling the output buffer. The same amp plugin with inputs unconnected
would also return a zero (or only one bit set if it was a two-in two-out
plugin). A synth plugin with no voices active and no active tail
processed in effects would also return 0.
Is the explanation clear?
Sure, it's not trivial to set that flag correctly in plugins that deal
with any kind of internal state (especially complex one like in reverb),
but it worked very well for Buzz. The end result was the ability to use
very complex processing networks - as long as not all instruments
produced sound all the time. The effects that were idle (because of no
input and no tail) consumed very little CPU time. If they consumed more
than very little for no reason, a horde of users started to complain ;)
The idea is dated back to 1997 or so, and it would be practical to reuse
it to increase multitimbrality (because then you can afford to have,
say, 20 different instruments with their own processing chains, as long
as you don't use all of them at the same time).
> 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.
That's nice. The only missing part is stability, then?
> There is no generic loader for them though, that might be useful.
Definitely.
> 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.
I've proposed my modifications to the MIDI Port spec - and perhaps could
provide a library to translate between old and new buffers. I definitely
think the change is worth it, because it seems to be simpler, cleaner
and doesn't cause misaligned memory access (which can cause SIGBUS on
SPARC machines and performance penalty on x86).
Can a plugin or GUI send MIDI data back to host?
> 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.
Yes.
> A complete transport sync mechanism would be more
> complex but also more useful - think loopers, record/playback plugins,
> automatic arpeggiators.
True. Not a priority for me, but other people might like it a lot.
> 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.
Nice. Hope something stable gets born at some point.
> 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.
Cool!
> 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)
Well, what I'd want here would be kind of in-place mini GUIs. But that's
just a gadget, nothing essential. It would be nice for certain purposes
(quick glance at some parameters on an oscilloscope, or having instantly
accessible volume controls, switches etc) in modular environment.
> 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).
That should be fine.
(about bit flags for changed groups of params)
> 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. It's just an optimization, but checking all 200 parameters for a
change each time a 64-sample long buffer is processed (low-latency
environment) doesn't seem to be very efficient :)
Another option is to send parameter changes via those float MIDI-like
events I suggested in the previous mail, and not by writing to ports -
then the same optimization can be implemented by plugin itself.
> 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.
So, another thing to look at in the near future. Especially if someone
plans to code a sampler of any sort.
> 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.
I thought of a situation where CC binding is defined on a per-preset
basis, or for things like something-to-LV2 adapters. But there are much
more pressing issues for now, it seems.
>> - dynamic parameters (Nedko is already working on these)
> Haven't looked much at this yet.
It's a work in progress, but it might be nice for future adapter
plugins, modular plugins or other advanced stuff.
> 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.
I think that asks for a separate extension, or reuse of separate MIDI
channels for individual notes (each note gets sent in a separate MIDI
channel, and the pitch bend etc affects only one channel by definition).
Or if my new MIDI structure proposal is adopted, one might reuse of some
bits in the 'flags' field as a "subchannel" so that control changes,
pitch bends etc are sent to individual voices.
But, again, that's a very far future - first things first!
Krzysztof
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 13 20:15:03 2007
This archive was generated by hypermail 2.1.8 : Tue Nov 13 2007 - 20:15:03 EET