[PD] list etiquette WAS: plugin~ external

[Kim Cascone]

Dan Wilcox wrote:
>
>>> and I want to make sure the text is a) true and b) easily understood 
>>> by a n00b
>
> This is where I think things should always go ... to the wiki or the 
> Floss manual! If a solution is found, pleasepleaseplease post it to a 
> standard place and then *everyone* can benefit and we don't get the 
> same questions every 6 months.
that's exactly what I'm trying to do here :)

and given that most, if not all, Linux audio apps can host a 
LADSPA/DSSI/LV2 plugin circa 2010 I see no reason why Pd shouldn't also 
be able to host one without 1337 secret handshakes, compiling src, 
chasing down deps, and other distractions to someone wanting to simply 
and easily host a plugin to do some audio processing

mind you these 'l337 handshake' solutions are sometimes necessary when 
solving a Linux audio problem but should not be a 0th order approach to 
trying to use Pd in a production environment

also, keep in mind I'm coming at Pd from 10 years of Max/MSP usage where 
the community is much less anarchic and doesn't share the political 
framework of being a FOSS app - which makes things less flexible at 
times but also imposes a certain standard, from the top down, on how 
things should work
> Not everyone knows to search the mailing list. This is why I suggested 
> a few weeks ago that we should look into building out "knowledge" base 
> in a more centralized way because there are too many disparate 
> elements ... I think newbies don't know where to look.
given the variety of conflicting info I've been given over the past week 
about how the [plugin~] object 'should work (or  why it doesn't) I'd 
have to say that even the 'experts' don't know where to look sometimes

it should NOT take anyone (even a Pd n00b) the better part of a week to 
figure out
a) why sending [info] to a [plugin~] won't always give her the correct 
info using what they believe to be the standard Pd [print] external
and
b) that using [<symbol:name> being the name of the port] in [plugin~] 
doesn't work globally for all LADSPA plugs hosted by [plugin~] and that 
<symbol:#n_of_ctrl_port> does - at least in the ones I've tested so far