[LV2] --SPAM--::Re: [Devel] lv2_descriptor() considered harmful

[David Robillard]

On Tue, 2012-02-28 at 11:10 +0100, Stefan Kersten wrote:
[...]
> i intend to create most plugins with faust [1], which generates c++ code that
> doesn't do dynamic memory allocation. for the cases where i do need dynamic
> memory, i thought about a separate extension providing a realtime allocator
> feature, something like:
> 
> struct LV2_RT_Allocator {
> 	void* (*alloc)(LV2_RT_Allocator* self, size_t size);
> 	void* (*alloc_aligned)(LV2_RT_Allocator* self, size_t alignment, size_t size);
> 	void (*free)(LV2_RT_Allocator* self, void* ptr);
> };

There is this, though it's quite a mess that needs to be cleaned up:

http://lv2plug.in/trac/wiki/Rtmempool

I am not sure there is a point though.  Is there a significant advantage
to forcing the host to supply this functions vs. just including a pool
in your plugin if you need it?

> i am working on an audio engine for mobile and server-side realtime rendering.
> currently planned are plugins for disk-based sample playback, spatialization,
> nothing fancy really. the architecture is similar to supercollider's scsynth
> [2], that's why plugins (`SynthDefs' in SC parlance) need to be
> realtime-instantiatable by default in order to be able to use them e.g. as
> voices in a synthesizer. for other LV2 plugins the plan is to instantiate them
> in a non-realtime thread and send the new instance to the audio thread.

If you're pre-allocating the memory for them anyway, is there really a
difference from just pre-instantiating a bunch plugins beforehand?

-dr