[PD] plugin~ external

[Kim Cascone]

>
> it does work globally for all LADSPA plugins hosted by [plugin~].
>
> i have to say that you were using it wrongly (though i cannot find the
> email were you explained exactly what you were doing: all threads are
> totally messed up; the subject became meaningless;...)
>   
I was following your instructions which I am pasting below:

> plugin~ syntax
>
> the message is:
> "port <symbol:direction> <symbol:type> <symbol:name> <float:lowerlimit>
> <float:upperlimit>"
>
> with <symbol:direction> being either "in" or "out"
> with <symbol:type> being "control" or "audio"
> with <symbol:name> being the name of the port (e.g. "Amplitude random 
> (%)")
>
> and lower/upperlimit define the valid range of the value.
>
> for controlling, you use "control <symbol:name> <float:value>"
>
> <symbol:name> is not case-sensitive, and it tries to find a simple match.
> e.g. "Amplitude random (%)" can be controlled with "amp" or "AMPLItude"
> or "Amplitude random (%)".
> it will take the first port that matches, so if you have parameters
> "FrequencyUpper" and "FrequencyLower", then "freq" will match
> "FrequencyUpper", in order to control the other param you have to use at
> least "frequencyl"


> in short it was something like:
> info gave you something like the following
> <snip>
> info: port out audio Out 0 1
> info: port in control Trigger 0 1
> info: port in control Velocity 0 10
> info: port in control Frequency (Hz) 0 20000
> info: port in control Resonance 0.001 1
> info: port in control Frequency Ratio 0 10
> </snip>
>
> and you tried to access (say) the "Frequency Ratio".
> you tried (without success) to use things like "frequencyratio" and
> "frequency_ratio".
>
> this does not work.
>   
that is correct - it does not work
> the control name will be matched against all port-names and the first
> with an exact match (case-insensitive; only the number of characters
> given will be checked) will be used.
>
> the _only_ freedom you have, is case-insensivity and
> number-of-characters (as long as it uniquely identifies the parameter
> you want to address); you cannot exchange characters at will (neither
> can you replace "X" with "U" nor " " with "_")
>
>
> so "Trigger" match the first control port (as well as "T" and "trigger")
> "Frequency" (and "f", "freq",...) will match "Frequency (Hz)" (since
> this will be found before "Frequency Ratio"..
>
> if you want to access "Frequency Ratio" than you have to use something
> that matches this name until it becomes unique (that is: up to
> "Frequency R", to differentiate it from "Frequency (")
> since all characters must match exactly (apart from the case) you have
> to construct a symbol with a space in it.
> again, there is no use replacing the space with "_" or "X" or "space" or
> nothing at all.
>
> it might be a good idea to allow underscores as well, but so far nobody
> has asked for it.
> also, i think that this is probably not so important, as you can just
> reuse the symbol you got out of [plugin~].
>   
I'm not sure this is a very good approach to using the [plugin~] external

and I'm surprised you don't know about the following schema that Tim 
Vets posted
which is much more simple than needing a manual on 'grep' for getting 
correct control names:

> [0\
> |
> [control #n $1( 
> |
> [plugin~ svf]
>
> where n is the number of the parameter (so #1 or #2 or #3 ..etc)

isn't this much clearer and 'somewhat' more intuitive?
maybe [plugin~] should count control ports and use this <#n> instead?

this is what Derek already put in the manual (albeit needs some 
corrections) and how I'll continue with my contribution to that chapter

> anyhow, personally i don't think that the info-interface of [plugin~] is
> particularily cleverly done.
>   
if a Pd user needs a semester of 'how to use grep' in order to send 
control data to a [plugin~] then I have to agree wholeheartedly
> i never used this object before.
> i only made it not crash any more.
> i probably will never use it again.
>   
then you should probably be glad for this sort of feedback? isn't this 
all helping the Pd devs to chase down these bugs so they can be resolved?
> i don't think that using all those VST/LV2/runzelpunzel plugins out
> there will make anything more professional.
plugins are an important part of all professional sound designers 
toolkit - I speak as a professional with 30 years in the industry :)