3 Jun
2008
3 Jun
'08
4:47 a.m.
2008/6/3 Arnold Krille <arnold(a)arnoldarts.de>de>:
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.
Stefano
Am Montag, 2. Juni 2008 schrieb Stefano D'Angelo:
The difference is enormous: the host has to know if the plugin does resampling!
2008/6/2 Arnold Krille
<arnold(a)arnoldarts.de>de>:
Whats the difference in this respect? Both change the number of samples, do
they? Am Montag, 2. Juni 2008 schrieb Wolfgang Woehl:
I guess you mean resampling, otherwise I don't think
it's phisically
possible to go ahead or behind in time. Arnold Krille:
> And why is time-stretching limited to non-realtime audio?
Aaannnddd wwwhhhyyy iiisss tttiiimmmeee---ssstttrrrettch <meep>
sorry, time's up.
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'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.)