13 Jun
2010
13 Jun
'10
4:48 p.m.
On Sun, Jun 13, 2010 at 5:38 PM, <fons(a)kokkinizita.net> wrote:
On Sun, Jun 13, 2010 at 09:11:24AM -0400, Paul Davis
wrote:
At least the compressor has other issues as well (didn't test the
others).
Ciao,
--
FA
O tu, che porte, correndo si ?
E guerra e morte !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Did someone mention CV as an interapp/plugin global standard, both
internal as a plugin/host communication protocol and as standalone
intercommunication protocol?
1 protocol language to rule them all, one protocol language to
bind....never mind.
Just a thought, and an ironic moment of dejavu.......
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
its difficult to see why you wouldn't simply
define your own plugin
API. the discovery process has to be one of the least interesting
parts of LV2 (or any plugin API that i can think of) and co-opting it
appears to me to save oneself almost no work at all.
True. This *will* a separate API, and using it directly will
by far the easiest way, but
1. Given that basic LV2 is almost nothing, *any* extension
more or less corresponds to a complete redeifinition (with
only the run() call being standard). So it's not really
so special.
2. 'Embedding' it in LV2 may placate some people, and
save me some flames.
supporting touch specifically requires 2 things:
a) a user interface that has a distinct gesture for both the start
of a touch and its end
b) an explicit way to convey the use of this gesture to a
control object
(b) is not provided by a basic get/set control port value
interface. How does the LV2 'external GUI' handle this ?
More generally, I don't think you can do automation right
by just monitoring/injecting control port values. Except
maybe when the automation data has a constant rate, e.g.
1/16 FS. In all other cases, it's only the plugin that can
decide in any intelligent way on control points, their
frequency and/or step size, etc. and it's only the plugin
that can interpolate such data in the correct way.
I tried
to see if/how this works today using Ardour 2.8.9
and the Calf compressor, but didn't get that far: just
using automation 'play' with the plugin GUI open crashes
both Ardour and the external GUI (memory corruption detected
by glibc).
i have seen quite a few reports recently that involve the Calf
plugins, most of them not so great (i..e crashes etc). i have some
suspicions that they do GUI operations from an illegal thread.