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