Re: [ecasound] LV2 Plugin Support

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 Thu Aug 11 16:15:01 2011