Re: LV2 Plugin Support

I suppose I'll just go ahead with -elv2:

However, there are two remaining issues I see:

1. Memory management
2. MIDI ports on LV2 plugins

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 can't be
freed until everything else deriving from it is freed.  It would seem to me
that this would mean that I should *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 not sure where it would logically belong.  The Lilv
objects are mainly instantiated in ECA_STATIC_OBJECT_MAPS, but they are
mainly referenced in EFFECT_LV2, but they are stored in ECA_OBJECT_FACTORY.
I could see arguments for it to be stored in any of these three.  #2. I
could just pass the LilvWorld around as an additional argument to a bunch of
functions, and let every class that needs it keep a non-static local pointer
to it.  This requires the least hard design decisions... but it makes thing
messy by adding all this additional argument passing.  #3 I could write a
C++ wrapper around Lilv which would properly reference count all the
objects, so I wouldn't have to worry at all about memory at all from within
ecasound... but that takes the most work and I'm not sure if it's really
necessary.

As for MIDI ports, I don't know if there is infrastructure in place for
plugins to handle MIDI or other events with Chain effects.  I could look to
the LADSPA plugin support for examples of handling audio and control ports,
but I'm not sure where to look for for an example of how to implement MIDI,
if at all possible.  To make matters complicated, it seems the LV2
developers are in the middle of drafting a new extension for event ports of
all types, including MIDI, which is to replace the old one.

Jeremy

On Wed, Aug 10, 2011 at 12:36 PM, Kai Vehmanen <[email protected]> wrote:

> Hi,
>
>
> On Wed, 10 Aug 2011, Jeremy Salwen wrote:
>
>  LV2 plugin support is coming along nicely, and I'm getting to
>>
>
> that's some exciting piece of news! :)
>
>
>  questions like "what should the identifier for LV2 plugins be?"  I'm
>> referring of course to the string that is "el" in the case of ladspa
>> plugins, i.e. a plugin might be identified as
>>  "el:sine_fcac".  What prefix should an LV2 plugin be identified with?
>>
>
> Naming of the command-line visible options has been, uhm, how to put it,
> artistic, so there are no strict guidelines in place. OTOH, it's not
> completely chaotic, so related things are usually named in a similar way
> (e.g. -etd is Effect -> Timebased -> Delay).
>
> With that background, my proposals would be "-elv2" (LV2 plugin
> implementing the ecasound effect interface), or just "-lv2" (shorter but
> still easily understandable).
>

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list