Paul Davis <[EMAIL PROTECTED]> writes:

> >You're right.  But don't you see that this means that the audio sample rate is
> >different from the control sample rate?  For every process cycle, there will
> >be one new control sample and N new audio samples (N is the fragment length),
> >implying that the audio rate is N times the control rate.
> 
> But N is not fixed! The host is free to call the plugin's run() or
> runAdding() function with any non-zero argument. It might call it
> like:
> 
>        run(16);
>        run(21467);
>        run(1);
>        run(480);
>        run(16384);
> 
> what control rate is that?  The point is that the plugin has no clue

None, but neither is that a conventional real-time audio system anymore.  As
you know, in (most of today's) real-time systems the process() function is
called at regular intervals, which gives birth to constant buffer lengths.

> what the control rate is unless it goes to some effort to track
> it. The host may not even have the idea of a "control rate": it may
> handle control-events in a completely asynchronous way.

Apropos asynchronous data, care to give a briefing or it wrt. LAAGA?  Am I
right in thinking that the sending client sets the buffer size in calling
laaga_get_buffer(), which is then told to the receiving client?

> 
> >Yesterday I was trying to make a LADSPA host for LAAGA, and the very lack of
> 
> An excellent effort. Thanks.

Well, have a peek at http://iem.kug.ac.at/~jams/ladspaplugin-0.0.1.tgz
Unfortunately it's not tested, me having problems with ALSA, but it's based on
the tried-and-true plugin~ LADSPA host for Pd.  I would appreciate someone
(you? :) testing (and fixing:) it.

> >per-port sample rates made me have to implement some (inferior) sort of a
> >downsampler and an upsampler right in the host, which will produce surprising
> >results.
> 
> Can you explain this a little more? I don't understand the problem
> (which is not to say I claim there isn't one) ...

OK, your solution is to create a "control" port type and make all its buffers
be of length one, but I would prefer control signals to be just plain signals
just with another sample rate.  The latter solution allows for connecting and
converting different-rate (control) ports together, using a resampler client.
Think combining Csound, where you can select arate and krate by hand, with
LADSPA, where you can't.

Later,
-- 
-Jarno

Reply via email to