Re: [ecasound] LV2 Plugin Support

Hi Kai,

I just found lilvmm.hpp which is included in lilv, a c++ wrapper around
lilv. It iimplements a lot of what I'm looking for. I'll just do a
singleton, but using the lilvmm wrapper structs.

Jeremy

On Thu, Aug 11, 2011 at 5:57 AM, Kai Vehmanen <kvehmanen@email-addr-hidden> wrote:

> Hi,
>
> On Wed, 10 Aug 2011, Jeremy Salwen wrote:
>
> 1. Memory management
>>
>
> I'll answer these in separate mails.
>
>
> As for memory management, part of me is confused on how exactly ecasound
>> handles things, and part of me is just unsure what I should do in this
>> case. Bascially, from what I can tell, ecasound keeps a map of
>> string->Object around which includes *all* possible effects, and this map is
>> never freed. Lilv uses something called the "LilvWorld", which
>>
>
> Yes. To keep things simple(r), there are no separate descriptor-types
> and/or per-object factory functions in the codebase. Instead for each
> distinct object type, one instance of the class is actually created and
> stored and associated with a object id (e.g. -etd is attached to an instance
> of EFFECT_DELAY class) and this is done in eca-static-object-maps. When new
> objects (for actual use) are instantiated, the existing object for the
> requested type is cloned (with clone() or new_expr()). Thus we don't need
> to separately describe the meta-data (parameter names, param hints, etc),
> but instead we create one class instance and use its methods to get the
> information directly. Same
> code can be reused at runtime to query info about the plugins, using
> the same interface.
>
> The intent was to reduce the amount of boilerplate code and abstractions,
> but it can be argued whether this is simpler in the end. With some effort,
> the needed metadata could be extracted and exposes outside the
> implementation classes, but this is extra code (for each plugin) I wanted to
> avoid. Dunno how beneficial this simplication is in the end, but at least I
> have been pretty happy with it so far (design dates back to early days in
> the 90s ;)).
>
> As for the allocation lifecycle, it's actually not entirely static. If you
> use no chainops, the object maps are never created. The object maps heavily
> use the singleton design pattern (see eca-object-factory.cpp for how the
> singleton logic is implemented in ecasound).
>
> But you are right that once the singleton is allocated, it stays allocated
> forever.
>
> For LV2, if LilvWorld is sufficiently small, I'd recommend making it a
> singleton with an implementation like in eca-object-factory.cpp. E.g. you
> provide a helper function to get a reference to a LilvWorld object.
> Everybody that needs to use a populated LilvWorld just uses this function to
> get a reference. If nobody uses this code path (e.g. not using any LV2
> plugins), LilvWorld never gets allocated.
>
> You can probably copy/duplicate the code for LADSPA in eca-object-factory
> and eca-static-object-maps for LV2. If the LV2 plugins are loaded by a
> separate function in eca-object-factory.h, that will make sure the singleton
> is not created unless needed. It's then upto the parser
> (eca-chainsetup-parser.cpp) to call the appropriate eca-object-factory.h
> methods to create objects. For LADSPA and LV2, the logic in
> eca-static-object-maps.cpp is a bit different compared to native objects
> like EFFECT_DELAY (where one-class == one type).
>
>
> *never* free the LilvWorld, as ECA_OBJECT_FACTORY will always contain
>> references to LV2 plugins which would be invalidated if I were to free it.
>> So I was thinking of a couple possible options of dealing with the
>> LilvWorld: #1, I could store it statically in some class ...but I'm
>>
>
> So I'd vote for this. Make the LilvWorld object a singleton and access it
> with a function lke those in eca-object-factory.h. Then it gets only created
> if somebody uses LV2, but when created, remains allocated forever.
>
> PS And to be nice for valgrind and other memory debuggers, it might
> be a good idea to wrap LilvWorld into a simpler wrapper class that
> has a destructor that calls lilv_world_free(). This way the singleton
> won't show up as a memory-leak in memdebuggers at process exit. But
> this is finetuning already, not a major concern...

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev

_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Fri Aug 12 00:15:04 2011