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

Replying to myself, lame but necessary.

Here I put some concrete proposals to try solving these issues, if
it's worth it. I am willing to help as much as I can coding and stuff,
but if someone else is interested as well it'd be way better.

2008/6/2 Stefano D'Angelo <zanga.mail@email-addr-hidden>:
> 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.
>
> #1. Support for interleaved channels and non-float data
> Input and output data is often found in these formats.

As Steve Harris suggests, let's not touch this but write a bunch of
helper functions to do the dirty work of demuxing and converting.

I have them already
(http://hg.atheme.org/naspro/file/6adbc44c9678/naspro-objects/lib/util.c)
and with very little work could be adapted I think.

These should reside either in SLV2 or somewhere else (see below).

> #2. Changing sample rate without re-instantiating all effects.
> Gapless playback when chaning songs, for example, should be possible
> without performing black magic.

Let's just forget about this now.

> #3. Some serious connection logic thing (all the "equal channels" thing etc.).
> This needs a thousand flame wars and *deep* thinking.

I was thinking if we can write a "simple" "chain streamer" aimed at
media players.

Again, this could reside either in SLV2 or be in a new separate
library using SLV2. The previous demuxing code should be in the same
place as this code.

> #4. Support for time stretching when using non real-time audio sources.

I came to this conclusion about it: if combining together pitch
shifting and time stretching you can get better results than doing
things separately, it is the case to support it at a plugin level;
otherwise time stretching can be done by the host and pitch shifting
by the plugin.

Now, I'm looking at phase vocoders on wikipedia
(http://en.wikipedia.org/wiki/Phase_vocoder) and that thing states:

"The time scale of the resynthesis does not have to be the same as the
time scale of the analysis, allowing for high-quality time-scale
modification of the original sound file."

I'm no expert in this stuff, does anyone know how if that is true?

In such case support should be added and, IMHO, that could be done
modifying the run() to return buffer length and give the host an hint
on maximum buffer sizes.

I think it shouldn't be done inside an extension since it's really
core level stuff.

> #5. Informations about delay time introduced by the algorithm itself
> to do syncing with video-sources (for example).

LV2 has that already.

> #6. Some way for the host to make sense of the meaning of some
> parameters and channels, to better support global settings and stuff.

Regarding audio ports, there is the port groups extension and channels
go away since we want to forget aout interleaved audio.

Talking about control ports, I think an extension could do the trick.

> #7. Global explicit initialization/finalization functions for more
> exotic platforms (they wouldn't harm, so why not having them).

I am still convinced they can't do any bad, but anyway it's not a
tragedy if you don't want them around.

> #8. Rules to find plugins possibly platform-specific and outside of
> the specification; possibly one compile-time valid path.

There are compile-time valid paths already.

I'm suggesting to state in the core spec: "look at this page to know
rules on how find plugins", but if you don't want to do it's still no
tragedy.

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

I trust you :-)

> #10. Something (a library possibly) to make use all of this features
> easily from the host author's POV.

Possibly some new stuff to SLV2 or an SLV2-based library, as I'm
saying on point 3.

Summing up, I'd say we need to:
- expand SLV2 to do "default chain streaming", channel demuxing and
format conversion for host authors who have no special attitude
towards this kind of stuff, or outside of SLV2 in a new SLV2-based
library;
- if it's the case, add a "number of samples" return value to the
run() callback in the core spec or, in the worst case, put an
alternative run() callback inside an extension;
- write an extension for "control in sense" (for the host to know
what's the meaning of a parameter);
- if LV2 authors want to do so, add global eplicit init/fini functions
and put platform-specific rules for finding plugins outside of the
spec.

I'm available for all of this tasks.

Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Jun 4 00:15:04 2008