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

On Thu, 2007-11-29 at 09:19 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > _Any_ structure that isn't just a dumb array of bytes will be unsafe to
> > move between machines because of endianness.
>
> A bridge can compare the architectures of the bridged machines, and
> refuse to continue if they're different.
>
> That kind of bridge could be written by a well trained chimpanzee and
> work for (perhaps) majority of cases. Of course, to work for *all*
> cases, the serialization would be needed.

OK, maybe. It's trivial to add a "safe" RDF indicator in a separate
extension and just assume that an event type is not safe if it doesn't
have it.

> > struct Event_Port_Buffer {
> > uint32_t capacity; // number of elements in the array
> > uint32_t used_size; // number of _used_ elements
> > uint32_t event_count; // number of events (different from
> > // used_size if there are large events -
> > // would this really be needed?)
> > struct Event* events; // an array allocated by the host
> > };
>
> I would argue for additional Event_Port_Buffer pointer, as in "next".
> This way, the host could allocate event buffers in (say) fixed-size
> chunks, and the buffer is too full, another is allocated and linked to
> previous one. What do you think?

For that case I think it would be cleaner if the host just splits the
processing period in smaller parts if it needs to fit in more events per
time unit. The plugin doesn't need to worry about it.

> > The host won't instantiate the plugin unless it knows how to handle
> > event ports and MIDI events, and the plugin will fail to instantiate
> > unless the host passes a URI -> integer map to instantiate using a
> > LV2_Feature with the URI <http://lv2.example.com/uri-map> and a
> > NULL-terminated array of event type URIs as data.
>
> How will it fail? (how will the host be notified about failure?) Is
> there any way to communicate the reason for the failure to the user?

The same way the core spec says that a plugin should always fail to
instantiate when a required feature is missing - by returning NULL from
the instantiate() callback. There is no error message passing.

> > handle_event(events[index]);
> > index += 1 + (events[index].size - 8) / 16;
>
> index += (events[index].size + 15) >> 4;
>
> right?

No, that doesn't work. If the event size is 16 it will need to use the 8
free bytes in this event header and 8 bytes in the next one, so the
index needs to be increased by 2, but (16 + 15) >> 4 == 1.

And mine is wrong too. Embarassing. This works:

  index += (events[index].size + 23) / 16;

> > Should plugins have to list <http://lv2.example.com/uri-map> as a
> > required feature, or should that be implicit whenever a plugin has an
> > event port?
>
> I guess, sometimes the event port isn't *required* to be connected?
> Depends on a plugin, I guess. MIDI arpeggiator will need event support,
> so will a synthesizer, but a reverb with MIDI support might do without
> the event port support.

Right, if the event port has the lv2:connectionOptional hint (from the
core spec) the host doesn't need to know about the event extension at
all. So I guess the cleanest way would be to not list the uri-map thing
as a separate lv2:Feature in the RDF data but require that a host that
handles events passes that LV2_Feature to the plugin's instantiate
callback if it is going to connect a non-NULL buffer to any event ports.

--ll

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev