2 Jun
2008
2 Jun
'08
4:16 p.m.
2008/6/2 Nedko Arnaudov <nedko(a)arnaudov.name>me>:
The less stuff to maintain, the better ;-)
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 :-\
Me too actually. I don't know.
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.
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).
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.
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.
I could help, let's just see how this discussion turns out.
At least I don't want to waste effort if I start writing something :-)
Stefano
"Stefano D'Angelo"
<zanga.mail(a)gmail.com> writes:
While I'm still not back to lv2zyn/zynjacku development, I'll share my
thoughts. :)
Fair enough :-)
Let's stop
this flame for a moment and see what LV2 misses in order to
let me kill EPAMP and live an happier life.
Not sure you will live happier live :P #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.
#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.
#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.
#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. Can we start
discussing about these issues and see if they are solved
already/how to implement them/how to make them better?
Sure, but IMHO the things get real momentum when someone starts writting
code, not just discussing. I hope this advice this will help you in your
journey ;)