Re: [LAD] "enhanced event port" LV2 extension proposal

Lars Luthman wrote:

> I don't like having something this complicated in an extension that is
> going to be required if you just want to write a simple synth with a
> MIDI input.

Hey, it's simpler than it looks like. Especially when you're writing a
plugin. All you need to do is do this during activation (C++ code):

// assume you have the void* for the "registries feature" already
IURIRegistries *registries = (IURIRegistries *)feature_value;
IURIRegistry *registry =
registries->get_registry("http://example.com/event_types_registry");
if (registry) {
  midi_event_id =
registry->uri_to_id("http://example.com/midi_event_type", true);
}

And that's all. With C you'd have
registries->functions->get_registry(registries,
"http://example.com/event_types_registry") instead, but that's still 6
lines of code or less. Done on activation. Nothing truly bad.

> Is there really any need for adding and removing mappings dynamically?

I think it is (especially adding). For inter-plugin communication - even
when host doesn't support a specific plugin type, two connected plugins may.

And Dave will probably agree with me here.

The big question here is memory management when host doesn't support the
type of data which is passed between two plugins (ie. if one plugin
produces an event which is of a type which has a pointer inside, then
who does free the memory? receiver just after reception, or sender
during next process() call?)

> Just passing an array in the LV2_Feature data would be enough for me.

But then, how would you search the array if it had, say, 1000 items?
Linear search with strcmp on each item?

Exposing the uri<->id in the host lets you reuse host's lookup
implementation, which may be more efficient (say, using a hash table or
a tree like std::map).

Not that expect that many items in an array, especially if it was
restricted to event types only, and not a general mapping.

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Dec 5 12:15:03 2007