[PD] plugin~ external

[Kim Cascone]

> 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?
>   
I'm not groking the logic here...if cmt.so comes with a dozen or so 
plugs bundled within it, which is not apparent by looking at your LADSPA 
dir, then how is this a bug with analyseplugin? it seems to me that 
analyseplugin is reporting exactly what is 'inside' cmt.so and not buggy 
at all

in fact, if you look at your LADSPA plugins in an app such as Ardour 
you'll see that it pokes inside of cmt.so and lists all the plugins 
inside of it just like analyseplugin does on the command line

I think there should be a similar way to get at this very same info in 
Pd using [info]

>
>   
>> > 
>> > ===================
>> > 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.
>   
if the plug designer uses '0.5*srate' to denote that  a control will 
allow you to go from 0Hz -> nyquist then they are obviously operating 
under the belief that passing a '*' is not a big deal for apps like 
Ardour and other LADSPA hosts...

although now that I'm looking at the controls in Ardour for cmt/lpf plugin
the range is stated as: [2.205 - 22050] which is [0.0001*srate - 0.5*srate]
so there must be some way that Ardour is parsing this and making it 
sensible to the user without a) code for that specific plugin's data or 
b) having to resort to the command line to invoke analyseplugin

> 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)
>   
I've parsed worse in Max using [sprintf] and don't see this as a big deal

but most likely users would never want to parse the control info simply 
because it doesn't provide anything reliably useful for controlling a 
plug in the first place

the schema you suggested of the plug grepping the control name is not 
how things work (across all plugins) from what I found out

whereas the following does:

manually count the number of controls reported by [info] and then use 
[control #n $1]
(and only when using [pd/print] because using [print] doesn't pass 
parentheses)


my point is really that if the [pd/print] external is not passing the 
info supplied by the plugin regardless of what it is then it something 
is broken somewhere

is there a LADSPA spec for callback data?

> if you are only interested in some visual feedback (e.g. the printout at
> the console), then you probably should just use "analyseplugin"...
>   

but you just stated above: 
'not a bug per se at all, but rather a problem with "analyseplugin" don't
you think so?'

so I should now rely on 'analyseplugin' for accurate info? 


>   
>> > 
>> > 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.
>   
maybe a look at the Ardour code could provide a possible strategy
but in either case HOW TO correctly send [info] to the [plugin~] is not 
clearly documented anywhere
> another possibility would be to add extra information whether the
> boundaries have to be multiplied by something.
>