2008/6/3 Arnold Krille <arnold@email-addr-hidden>:
> Am Montag, 2. Juni 2008 schrieb Stefano D'Angelo:
>> 2008/6/2 Arnold Krille <arnold@email-addr-hidden>:
>> > Am Montag, 2. Juni 2008 schrieb Wolfgang Woehl:
>> >> 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 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!
>> 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.
Stefano
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 3 12:15:02 2008
This archive was generated by hypermail 2.1.8 : Tue Jun 03 2008 - 12:15:02 EEST