[PD] plugin~ external

Kim Cascone kim at anechoicmedia.com
Tue Jun 15 19:12:43 CEST 2010

> 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 :)

More information about the Pd-list mailing list