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 :)
On 2010-06-15 19:12, Kim Cascone wrote:
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.
it's not meant to work, so it doesn't surprise me very much...
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
this i don't know. but i also don't know whether we are talking about the same thing here.
and I'm surprised you don't know about the following schema that Tim Vets posted
why? i don't use [plugin~], how am i supposed to know?
which is much more simple than needing a manual on 'grep' for getting correct control names:
where does the "manual grep" come into play? it seems like i missed it, and i have no idea why anyone would need to use "grep" here.
[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?
i don't know.
i personally find it highly non-intuitive to use the numeric id of a control-port. i seem to remember that in the given example there was an "Amplitude" control, but i have no idea which number this was. thus, i would prefer to use [control Amplitude $1( rather than [control 2 $1(
maybe [plugin~] should count control ports and use this <#n> instead?
i don't think i understand what you mean. do you think the output with [info( should be "port 12 in control Frequency Ratio 0 10" (in the case that the "Frequency Ratio" control is really #12)?
you can do this simply by adding a counter to the patch.
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
again, why "grep"?
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 was merely volunteering to fix a bug where a lot of people have been whining for ages.
of course i'm happy if people help fixing a problem (even if it's not mine)
fgmasdr IOhannes