Am Dienstag, 3. Juni 2008 schrieb Stefano D'Angelo:
2008/6/3 Arnold Krille <arnold(a)arnoldarts.de>de>:
Am Montag, 2. Juni 2008 schrieb Stefano
D'Angelo:
2008/6/2 Arnold Krille
<arnold(a)arnoldarts.de>de>:
Well, try syncing two devices that don't
share a world-clock and you
will "fix" that problem with real-time-time-stretching. So yes, there
is a rather practical use (but I actually don't advise to syncing two
devices without a common-clock) for real-time audio stretching (its
also called a dither-buffer but why use these algorithms when there is
rubberband and co?).
I guess you mean resampling, otherwise I don't think
it's phisically
possible to go ahead or behind in time.
Whats the difference in this respect? Both
change the number of samples,
do they?
The difference is enormous: the host has to know if the plugin does
resampling!
Yep, thats why the plugins have to tell the host how many samples they create
from the number of input samples. (With the default of the same number of
samples...)
But the host should _never_ force a plugin to do resampling/time-stretching!
Because it opens a pandoras box of bad quality!
I'm not interest in resampling plugins, but maybe
someone else is?
Not me, but when you start designing a plugin-interface with that
attitude, you will loose. You _are_ interested in all possible plugins
because you want your interface to rule the world and be used by all
plugin-devs. (Regardless whether we are talking EPAMP, LV2, LADSPA, VST
or gstreamer-plugins.)
This is not true for every plugin API. By design, some are
meant to be
universal, others are not. It's a matter of choice IMHO.
Well, your first proposal was a "universal" plugin API!? Being universal is
one of the things you wanted in the first place. And its why LV2 supports
extensions...
Arnold
--
visit
http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a "rm -rf /". Or ask your
administrator to do so...