[LAD] Let's kill EPAMP???

[Nedko Arnaudov]

"Stefano D'Angelo" <zanga.mail at gmail.com> writes:

While I'm still not back to lv2zyn/zynjacku development, I'll share my
thoughts. :)

> 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

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

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

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

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

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

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

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

> 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 ;)

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20080602/ab097915/attachment.pgp>