On Thu, 2007-11-29 at 14:03 +0000, Krzysztof Foltman wrote: > Lars Luthman wrote: > > A host doesn't necessarily have to allocate one fixed-size memory block > > for every plugin event port, it can use one large shared buffer and dole > > out portions of it to each input port in each period, > > What about plugin-to-host communication, then? Before getting the events > from the host we set the capacity to maximum, and after the plugin > returns, we just reuse the part that wasn't used by the plugin for other > events?
It's up to the host I suppose. If you pass the maximum capacity you get maximum flexibility, but also risk that a greedy plugin fills your entire buffer with 12412 MIDI CC's per audio frame. But at some point I guess you just have to assume that plugin writers aren't going to be maliciously stupid. =) > >> Why not use lv2:optionalFeature? > > Because it isn't really a separate optional feature, it depends on > > whether 1) all event ports have the lv2:connectionOptional hint and 2) > > the host doesn't plan to connect to any of those ports. > > Are hosts forced to reveal all features that they implement for > instantiate call, or just the ones mentioned by the particular plugin in > RDF? According to the core spec, hosts are only required to pass the features to a plugin that the plugin lists as required in its RDF data. In practice many hosts will probably keep one static feature array with all the features they supports that they pass to every plugin instance but it's not necessary. If we decide that plugins with event ports do _not_ have to list the URI map thing as an optional or required feature but still pass the LV2_Feature struct to the plugin at instantiation that's OK too - that's what extensions are for, extending and modifying the core spec. --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
