2 Mar
2011
2 Mar
'11
11:44 p.m.
2011/3/2 Olivier Guilyardi <list(a)samalyse.com>om>:
On 03/02/2011 08:55 PM, Stefano D'Angelo wrote:
Mmm, this answer goes straight to the heart of the problem: what does
the UI actually represent?
Your examples show quite clearly that the visualization part might be
of great help, and I honestly won't support the idea that the host
should do that, since there are thousands of ways you could represent
data.
Yet a problem remains... is data visualization really indivisible from
a plugin state and/or its input parameters?
Or, in more practical terms, should we consider visualization
belonging to the plugin GUI or not? I suspect that in theory it is
not, but in real world it is... since it would really be madness to
ask a plugin how it treats data, how could it ever be represented in
the most meaningful way w.r.t. its processing algorithm and asking it,
optionally, for a self representation in either a form of data that is
directly comparable to the input/output representation (compressor and
EQ example) or whatever else...
(I'm scared of myself at times)
What I don't really get is why you would ever
want visualization,
since that is more related to sound analysis, that LV2, as of now,
doesn't really support (yes, you can do whatever you want, but don't
tell me about spectrograms... that stuff is better suited to Vamp and
the like as of now - this may change, hopefully, however).
Visualization can allow realtime feedback of the applied effect as well as
improved interaction.
About my previous compressor example: imagine a single area where you have both
the input and the output waveform. It allows you to see the applied compression
but not only. The threshold above which the compression is applied can be
represented as an horizontal line which could be moved up and down.
Another example is a visual EQ as the one found in Jamin, where you both see the
live spectrum and can adjust frequency bands level.