2008/6/3, Arnold Krille <[EMAIL PROTECTED]>: > Am Dienstag, 3. Juni 2008 schrieb Stefano D'Angelo: >> 2008/6/3 Arnold Krille <[EMAIL PROTECTED]>: >> > Am Montag, 2. Juni 2008 schrieb Stefano D'Angelo: >> >> 2008/6/2 Arnold Krille <[EMAIL PROTECTED]>: >> >> > 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...)
Yes, but the host has to know how much time corresponds to a buffer, so it must know the input and output sample rate. > But the host should _never_ force a plugin to do resampling/time-stretching! > Because it opens a pandoras box of bad quality! Of course. >> >> 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... Who said that? I said "an effect API *for media players*". Anyway, it doesn't matter. I'm starting to think that it's better to adapt LV2 to this task. Stefano _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
