Re: [LAD] LV2 realtime safe memory pool extension

On Tuesday 13 November 2007, Lars Luthman wrote:
[...]
> 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.

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.

[...]
> > - so is the ability to deliver MIDI or MIDI-like events with
> > sample accuracy. But that may be added later (I'm looking at your
> > MIDI Port extension, it looks perfect except for double values for
> > timestamp - I think int32 and sample accuracy would be
> > simpler/faster and equally 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.

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?

> > - the way to communicate current bpm from host to the plugin
(bpm-synced
> > delays, flangers etc were a standard in 2000 or so :) )
>
> 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 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.)

[...]
> > - the ability to paint on plugin icon in realtime (so that we may
> > make oscilloscope plugins or display current frequency response
> > plots in filter plugins)
>
> 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)

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...)

[...]
> > - optimization of parameter handling by telling the plugin which
> > parameters have changed (using a bitmask) - which is a must for a
> > 200-parameter synthesizer :)

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. ;-)

[...]
> > - dynamic ports, so that a mixer plugin can have new inputs/auxes
> > added on the fly (very low priority in my opinion, and nobody
> > seems to be working on it)
>
> 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.

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 --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Nov 13 20:15:04 2007