1 Sep
2016
1 Sep
'16
4:52 a.m.
On Sun, 2016-07-10 at 11:30 -0400, Tim E. Real wrote:
On Saturday, July 9, 2016 6:07:37 PM EDT you wrote:
Adding new port types to LV2 is a possibility, or some other interface
to specify that out != in, but I think an arbitrary pull model where the
plugin requests data doesn't really make sense in this context. At some
level, the host needs to be requesting a certain amount of processing
time / amount of input data / amount of output data, and having
situations like the plugin asking for amounts that are simply impossible
at the current time doesn't lead anywhere good.
It seems more reasonable to me, and more in-line with how streaming
audio plugin APIs work, to add an interface where the plugin can specify
the number of output samples that correspond to some number of input
samples (or vice-versa) and keep everything else the same.
Though one might question how sensible it is to use a streaming audio
API like LV2 in the first place for such things...
I think gstreamer has facilities very much like what you are describing,
though.
--
dr
Well, technically, VAMP doesn't really do
audio-in=>audio-out plugins at
all, but rather audio-in=>metadata out, so that doesn't really count.
but fundamentally in != out == analysis not realtime.
The term 'realtime' would be a bit muddy here since what I
had in mind was that the streams could accommodate
either 'live' or 'offline file' data, in a 'live realtime'
mixing sense.
A stream info flag could indicate that the stream is in fact
'stretchable' or not.
Thus both 'live' and 'file' input could be mixed agnositcally.
The goal would be to have, say LV2, support time-stretch plugins.
Imagine Rubberband as an LV2 stretch plugin.
The plugin can ask for more or less input data.
It seems this is the only type of processing that can't easily
be supported by current plugin architectures, without building
special embedded support into the application, since it requires
pulling variable lengths of input data.