[PD] plugin~ external

[Hans-Christoph Steiner]

On Jun 14, 2010, at 3:22 PM, Kim Cascone wrote:

> 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

Hey Kim,

Switching back to that topic ;)  From my point of view Pd-extended is  
a giant thing.  There are many things that could be done to improve  
it.  Since you put a lot of effort into testing the plugin~ stuff,  
then its worth it to me to put effort into making sure the whole thing  
is smoothly integrated into Pd-extended.  That's my two bits...

.hc


----------------------------------------------------------------------------

Using ReBirth is like trying to play an 808 with a long stick.    - 
David Zicarelli