Ok so here are some more 'issues'
I'm using the 'lpf' LADSPA plugin to use as a simple example for the FOSS manual
it has one control which is the cutoff frequency
I instantiate the [plugin~ lpf] in a patch
the console window reports: verbose( 1):plugin~: found plugin "lpf" in library "/usr/lib/ladspa/cmt.so" verbose( 2):plugin~: open_plugin (x, "lpf", "/usr/lib/ladspa/cmt.so", 44100); verbose( 1):plugin~: constructed plugin "Low Pass Filter (One Pole)" successfully verbose( 1):plugin~: plugin ports: audio 1/1 ctrl 1/0 verbose( 1):plugin~: plugin active plugin~: "Low Pass Filter (One Pole)"
=============== first level of confusion ===============
occurs when a user is looking for the 'lpf' messages on the command line using
analyseplugin lpf
they won't find it unless they read the console carefully and see the LADSPA plug is actually called 'cmt.so'
and if they type in analyseplugin cmt.so
they will have to scroll through the dozens of plugins inside 'cmt.so' for the lpf plug
not a bug per se but there must be other plugs that come bundled like the cmt.so which present a similar confusion...?
=================== the second level of confusion ===================
occurs when sending [plugin~ lpf] an [info] message in a patch
the [pd/print] object reports to the console:
b: port in control Cutoff Frequency (Hz) 0 0.5 b: port in audio Input 0 1 b: port out audio Output 0 1
leading the user to believe that the Cutoff Freq is controlled with a float from [0 - 0.5] instead of [0 - 0.5*srate] (n times the sample rate)
while 'analyseplugin cmt.so' reports:
Plugin Name: "Low Pass Filter (One Pole)" Plugin Label: "lpf" Plugin Unique ID: 1051 Maker: "CMT (http://www.ladspa.org/cmt, plugin by Richard W.E. Furse)" Copyright: "(C)2000-2002, Richard W.E. Furse. GNU General Public Licence Version 2 applies." Must Run Real-Time: No Has activate() Function: Yes Has deativate() Function: No Has run_adding() Function: No Environment: Normal or Hard Real-Time Ports: "Cutoff Frequency (Hz)" input, control, 0 to 0.5*srate, default 440, logarithmic "Input" input, audio "Output" output, audio
as you can see the [pd/print] object is not reporting the correct message to send for 'cutoff freq' it SHOULD read: b: port in control Cutoff Frequency (Hz) 0 0.5*srate
but is reporting b: port in control Cutoff Frequency (Hz) 0 0.5
so it seems the [pd/print] object is not passing the '*' symbol
is this a known issue or can it be changed?
also, just as a data point the gf [print] object reports:
error: [print foo]: close-paren without open-paren foo: port in audio Input 0 1 foo: port out audio Output 0 1
On 2010-06-14 22:27, Kim Cascone wrote:
=============== first level of confusion ===============
occurs when a user is looking for the 'lpf' messages on the command line using
analyseplugin lpf
they won't find it unless they read the console carefully and see the LADSPA plug is actually called 'cmt.so'
and if they type in analyseplugin cmt.so
they will have to scroll through the dozens of plugins inside 'cmt.so' for the lpf plug
not a bug per se but there must be other plugs that come bundled like the cmt.so which present a similar confusion...?
not a bug per se at all, but rather a problem with "analyseplugin" don't you think so?
=================== the second level of confusion ===================
occurs when sending [plugin~ lpf] an [info] message in a patch
the [pd/print] object reports to the console:
b: port in control Cutoff Frequency (Hz) 0 0.5 b: port in audio Input 0 1 b: port out audio Output 0 1
leading the user to believe that the Cutoff Freq is controlled with a float from [0 - 0.5] instead of [0 - 0.5*srate] (n times the sample rate)
while 'analyseplugin cmt.so' reports:
[...]
Ports: "Cutoff Frequency (Hz)" input, control, 0 to 0.5*srate, default 440, logarithmic
[...]
"Input" input, audio "Output" output, audio
as you can see the [pd/print] object is not reporting the correct message to send for 'cutoff freq' it SHOULD read: b: port in control Cutoff Frequency (Hz) 0 0.5*srate
but is reporting b: port in control Cutoff Frequency (Hz) 0 0.5
so it seems the [pd/print] object is not passing the '*' symbol
i'm sure you don't want to get a symbol "0.5*srate" for the upper boundary. the idea is of course, to do something meaningful with the data you get, e.g. set the boundaries of a slider or similar. you wouldn't want to parse the meaing of the symbol "0.5*srate" yourself in Pd as it is. (at least: i wouldn't)
if you are only interested in some visual feedback (e.g. the printout at the console), then you probably should just use "analyseplugin"...
is this a known issue or can it be changed?
it should be possible to change it. the obvious solution is to pre-multiply with the srate if needed. another possibility would be to add extra information whether the boundaries have to be multiplied by something.
fgmadsr# IOhannes