[LV2] --SPAM--::Re: [Devel] lv2_descriptor() considered harmful
sk at k-hornz.de
Sun Feb 26 15:48:12 PST 2012
On 26.02.12 23:08, David Robillard wrote:
> On Sun, 2012-02-26 at 14:28 +0100, Stefan Kersten wrote:
>> my use case is an extension that allows realtime-safe instantiation (and
>> destruction) of plugins. currently the interface to be provided by the plugin
>> via extension_data looks like this:
>> typedef struct
>> void (*initialize)(LV2_Descriptor * descriptor,
>> const char * bundle_path,
>> const LV2_Feature *const * features);
>> void (*release)(LV2_Descriptor * descriptor);
>> uint32_t (*instance_size)(const LV2_Descriptor * descriptor);
>> uint32_t (*instance_alignment)(const LV2_Descriptor * descriptor);
>> LV2_Handle (*instantiate)(const LV2_Descriptor * descriptor,
>> void * location,
>> double sample_rate);
>> } LV2_RT_Instantiate_Interface;
>> the main point here is that the host's feature set is required during library
>> (or descriptor) initialization, because potentially non-realtime-safe calls
>> (e.g. to the urid extension) cannot be made from within instantiate and their
>> results need to be cached beforehand.
> Wouldn't it be simpler/better to just have the host pass an allocator?
the idea is to keep instance creation overhead as low as possible; "placement"
instantiation saves one call to the allocator and is possible for many plugins
(in my case most of them generated by faust). an allocator feature still makes
sense though, for plugins that don't know their memory requirements at compile time.
> Presumably initialize and release would go away if the new discovery API
> was there to use.
yes. i've been rolling my own plugin API when i realized that LV2 does almost
everything i need and is extensible enough to make it do virtually anything.
More information about the Devel