[LAD] Let's kill EPAMP???

[Stefano D'Angelo]

2008/6/2 Nedko Arnaudov <nedko at arnaudov.name>:
> "Stefano D'Angelo" <zanga.mail at gmail.com> writes:
>
> While I'm still not back to lv2zyn/zynjacku development, I'll share my
> thoughts. :)

Fair enough :-)

>> Let's stop this flame for a moment and see what LV2 misses in order to
>> let me kill EPAMP and live an happier life.
>
> Not sure you will live happier live :P

The less stuff to maintain, the better ;-)

>> #1. Support for interleaved channels and non-float data
>> Input and output data is often found in these formats.
>
> New port type is needed. Keep in mind though, that plugins using this
> port type will be probably limited to music player hosts. Also if we
> extrapolate this idea, we will have mp3 stream ports or things like
> that. Think twice whether it is good idea.

Well, I'd say non-float non-compressed data. I think ALSA's PCM sample
formats are more than sufficient. If you're worried about third
parties... LV2 is decentralized by design :-\

>> #2. Changing sample rate without re-instantiating all effects.
>> Gapless playback when chaning songs, for example, should be possible
>> without performing black magic.
>
> While I see nothing wrong to support that in general, if I was writting
> a music player, I'd use one sample rate/format do processing using it
> and convert/decode input streams early in the flow chain.

Me too actually. I don't know.

>> #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.

>> #4. Support for time stretching when using non real-time audio sources.
>
> Why not? AFAIK this has clear uses in "professional" audio world too.
>
>> #5. Informations about delay time introduced by the algorithm itself
>> to do syncing with video-sources (for example).
>
> Uhm, dont we have such thing in LV2 already? If not, I think we need
> it. This should be useful for syncing multiple audio streams too. For
> video sources I'd prefer to have video streams (video port type),
> probably as event port.
>
>> #6. Some way for the host to make sense of the meaning of some
>> parameters and channels, to better support global settings and stuff.
>
> No idea what you mean by this. ATM, I miss instantiation stage
> parameters though.

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.

By "channel sense", I mean the host could know what a channel is in a
standardized way (I see you have that already in port groups
extension, it could be generalized to channels rather than ports).

>> #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.

>> #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.

>> #9. Maybe more strict requirements on both hosts and plugins
>> (especially about thread-safety).
>> I see there is some indication in the core spec, but I don't know
>> about extensions and/or other possible concurrency issues.
>
> If things are not documented clearly enough I dont see why they
> shouldnt.
>
>> #10. Something (a library possibly) to make use all of this features
>> easily from the host author's POV.
>
> I'd choose one path of two host helper libraries, one for music player
> like apps and one for more music creation oriented ones. Not sure whether
> SLV2 fits in former case, AFAIK it is only used in later ones.

I could help, let's just see how this discussion turns out.

>> Can we start discussing about these issues and see if they are solved
>> already/how to implement them/how to make them better?
>
> Sure, but IMHO the things get real momentum when someone starts writting
> code, not just discussing. I hope this advice this will help you in your
> journey ;)

At least I don't want to waste effort if I start writing something :-)

Stefano