Re: [LAD] Let's kill EPAMP???

From: Stefano D'Angelo <zanga.mail@email-addr-hidden>
Date: Tue Jun 03 2008 - 14:58:43 EEST

2008/6/3, Nedko Arnaudov <nedko@email-addr-hidden>:
> "Stefano D'Angelo" <zanga.mail@email-addr-hidden> writes:
>
>>>> #3. Some serious connection logic thing (all the "equal channels" thing
>>>> etc.).
>>>> This needs a thousand flame wars and *deep* thinking.
>>>
>>> No idea what you mean by this.
>>
>> If someone is going to write that helper library (or adjust SLV2 or
>> whatever), I guess we should find some reasonable conventions to
>> organize and use plugins in a chain-like thing. This is damn hard, as
>> Paul Davis outlined already on this mailing list, and I actually don't
>> know to which degree it should be done.
>
> Looks like good cadidate for separate helper library. But as Paul said,
> proably each player will end with its own helper "library".

I'm waiting for an answer from Steve Harris on this :-)

>> Example: some LV2 extension tells the host that which parameter is a
>> "quality vs. speed" parameter in a plugin. The host can, then, show a
>> global "quality vs. speed" parameter to the user.
>
> In dynparam extension there are "hints" for this. They could be used as
> generic UI generation hints, as MIDI mapping hints or as "quality
> vs. speed" hint. I think this could be done for normal LV2 ports too,
> i.e. assigning hint URIs with a port.

That could do the trick.

>>>> #7. Global explicit initialization/finalization functions for more
>>>> exotic platforms (they wouldn't harm, so why not having them).
>>>
>>> I still dont get what is the use case for this.
>>
>> Both on the host side and on the plugin side, no need for #ifdefs to
>> define initialization/finalization functions and maybe support for
>> exotic platforms not having them.
>
> I dont see what you will do within those global
> initialization/finalization functions. That thing needs to be something
> not platform specific.

Well, I for example would use them with NASPRO to fill the plugin with
all effect descriptors (don't know yet how to do with RDF/Turtle, but
I'll find a way).

> This can be made as separate thing that can be
> reused for other things too. The same way libtool is asbtraction to
> shared libraries.

?

>>>> #8. Rules to find plugins possibly platform-specific and outside of
>>>> the specification; possibly one compile-time valid path.
>>>
>>> AFAIK, this conficts with "LV2 spirit". Why one needs this? If the goal
>>> is to avoid RDF Turtle, this shouldnt be issue with proper helper
>>> library for hosts. Still such feature could be implemented in such a
>>> helper library.
>>
>> Nope. I mean there should be platform-specific rules to get the list
>> of directories containing shared object files and possibly there
>> should be a fixed path to check on each platform, known at compile
>> time.
>
> Interface to SLV2 (-like) library should definitively allow modification
> of directory list.

Which kind of modification?

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 3 16:15:02 2008

This archive was generated by hypermail 2.1.8 : Tue Jun 03 2008 - 16:15:02 EEST