2 Jun
2008
2 Jun
'08
3:36 p.m.
"Stefano D'Angelo" <zanga.mail(a)gmail.com> writes:
While I'm still not back to lv2zyn/zynjacku development, I'll share my
thoughts. :)
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 ;)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>