3 Jun
2008
3 Jun
'08
6:30 a.m.
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.
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.
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.
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.
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.
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).
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.
- Steve
#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. #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.