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

2008/6/3, Steve Harris <steve@email-addr-hidden>:
> On 2 Jun 2008, at 19:16, Stefano D'Angelo wrote:
>>
>>>> #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 :-\
>
> I think you'll make everyones life much better if you just provide
> utility functions (eg. in slv2) to convert interleaved integers and
> whatever to channelled floats. Constantly converting back and forth
> between different plugins with different requirements is lossy (in
> audio quality terms) and difficult to get right. Just do it once.
> There's a reason that LADSPA, LV2, VST etc. do everything in floats.

Maybe yuo're right.

>>>> #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.
>
> If you want glitch free playback then you have to stick to one sample
> rate at the card, in which case you may as well do the conversion
> before you start feeding plugins.

Right, didn't think about that actually.

> Any plugin that uses filters (ie. pretty much anything interesting)
> will have to recalculate it's coefficients and throw away buffers if
> you change the sample rate on it, so you'll be out of luck if you
> expect this to be smooth.

By "throwing away buffers" you mean past buffers?

>>>> #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.
>
> It's not necessary, just intervene after each run() call, it's not
> hard and on a modern machine the cost is negligible.

Sorry, I'm not understanding here. How would you do exactly?

>>>> #4. Support for time stretching when using non real-time audio
>>>> sources.
>>>
>>> Why not? AFAIK this has clear uses in "professional" audio world too.
>
> Yeah, but not in "realtime". LV2 could of course support that, with an
> extension, but it doesn't seem like the sort of thing that has enough
> variance that a plugin mechanism is a huge win over using SRC.

Mmm.. not if it is only time-stretching, but if it is time-stretching
+ other stuff (for example pitch shifting) together? Gonna use two
plugins? I don't know :-\

>>>> #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.
>
> In LADSPA there's a "magic" control out port called "_latency" or
> something, that should apply to LV2 aswell, but I'm not sure if the
> spec says so.

Which spec are you referring to? IIRC the LADSPA spec doesn't state
such a thing. Some convention maybe?

>>>> #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).
>
> What is a channel that is not a port/port group? Ports can be grouped
> and attributed, as eg. quality v's speed, or you can just say that by
> convention QvS ports have some well-known label, in the same way that
> systemic latency is indicated.

I was referring to one of the interleaved channels in a multi-channel stream.
About labels, could we maybe define a set of known labels? (And isn't
that already implemented somehow in LV2? - I'm not exactly familiar
with it, as you may have noticed)

>>>> #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.
>
> That's just a specification issue, it doesn't require any code. In
> order to use things like the CRT, linkers and loaders invoke global
> constructor attributes and so on, so that's just not an issue.

?

>>>> #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.
>
> That's all in the specification. You can also do more sophisticated
> searches based on attributes of the plugins (EQs, room correction or
> whatever).

"That's all in the specification" <- that's the weird part of it. Are
you going to make a new revision any time there's some new platform to
support?
Then, I see no reference on how to get a fixed path when you
compile/install an LV2 host, which could be useful after all (in many
distros I had to set LADSPA_PATH on my own, for example).

>>>> #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.
>
> Extensions can label the concurrency properties of any additional
> stuff in a machine readable way, but I don't think that's relevant, as
> without knowing exactly what a new function does, how/why would you
> call it?

I agree. Anyway, I was just saying that maybe it's good to be strict
about concurrency issues, in case LV2 is not already strict enough.

>>>> #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.
>
> I don't see why you'd need a different library, but hey, the more the
> merrier.

I didn't look at SLV2, gotta give it a look ASAP.

However, let's make it simple for both developers who don't want to
loose too much time with LV2 and for users.

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:01 2008