3 Jun
2008
3 Jun
'08
9:53 a.m.
2008/6/3, Steve Harris <steve(a)plugin.org.uk>uk>:
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.
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?
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 :-\
Which spec are you referring to? IIRC the LADSPA spec doesn't state
such a thing. Some convention maybe?
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)
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.
?
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).
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.
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
On 2 Jun 2008, at 19:16, Stefano D'Angelo wrote:
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.
#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. 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. >> #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. #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.
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.