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

On 3 Jun 2008, at 12:53, Stefano D'Angelo wrote:
>>>>> #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?

I mean the y(-1) etc. buffers that filters use to calculate their
output. Actually it may not be neccesary to discard them in some
cases, but you will still get glitches from the coefficient changes.

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

You don't have to make plugin A directly feed plugin B, you can have
the host do some buffer twiddling inbetween.

>>>>> #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 :-\

Well, pitch shifting is fine in plugins.

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

Yeah, that's what implying by "magic", in LV2 it's an annotation on
ports.

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

OK, but interleaving is just inconvenient, in many ways.

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

Yes, sure.

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

http://lv2plug.in/docs/index.php?title=Filesystem_Locations

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

It is.

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

That was the intention I believe. The sample code makes it look eaay,
but I've not written any code with it myself.

LV2 is certainly one of the easiest plugin formats for plugin authors.

- Steve

_______________________________________________
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:02 2008