Re: [LAD] Let's kill EPAMP???

2008/6/3, Arnold Krille <arnold@email-addr-hidden>:
> Am Dienstag, 3. Juni 2008 schrieb Stefano D'Angelo:
>> 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>:
>> >> > 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jun 3 16:15:01 2008