[LAD] "enhanced event port" LV2 extension proposal

Krzysztof Foltman wdev at foltman.com
Tue Dec 4 09:42:37 UTC 2007


Dave Robillard wrote:

> Using a uint32_t (which is a reasonable limit for number of symbols in
> pretty much any system) and just not using out of range numbers for the
> event ones doesn't seem so bad, just in case.  It's one line in a
> comment somewhere, BFD.

I'm thinking of something else - like having different "domains" for
mappings. Like http://whatever/parameter-value gets number 10 in
URI-to-event-type mapping, and number 16777216 in URI-to-global-numbers
mapping. Basically, same class (URI-to-int mapper), different objects
(event type URI registry, plugin port URI registry, plugin URI registry,
 and so on). Different dictionaries, same dictionary interface.

I'm not insisting this is a good idea - just that it could solve the
"max 65536 types" thing nicely while preserving some (not all)
generality. It could also lead to a mess if somebody used wrong type ID
(when the same URI is in two registries).

Also, I would be for a requirement that numbers are always assigned (by
host) sequentially starting from 0, not by - for example - hashing,
because then some plugins could use small arrays to store
event-type-to-handler mapping (or
something-id-to-whatever-data-structure). Is that OK?

Seems that we don't have as many ideas for design of URI-int mapping as
we had for binary layout ;)

What about this (translate it to C in your heads :) ):

interface IURIRegistryObserver
{
  // function in plugin etc. called by host whenever new URI is registered
  void mapping_added(int id, const char *uri);
};

interface IURIRegistry
{
  int uri_to_id(const char *uri, bool create_if_absent);
  const char *id_to_uri(int id);
  void add_observer(IURIRegistryObserver *observer);
  void remove_observer(IURIRegistryObserver *observer);
};

interface IURIRegistries
{
  IURIRegistry *get_registry(const char *registry_uri);
};

Where IURIRegistries pointer is passed as a feature to a plugin.

Either that, or expose individual IURIRegistry objects as separate
features (perhaps deriving from http://something/uri-registry, RDF
allows that, right?).

Note that there is no delete function, as is doesn't seem very useful
for our purposes. Otherwise, it should be fine.

Thoughts?

Krzysztof



More information about the Linux-audio-dev mailing list