[PD] plugin~ external

Kim Cascone kim at anechoicmedia.com
Mon Jun 14 20:20:35 CEST 2010


Mathieu Bouchard wrote:
> On Sat, 12 Jun 2010, Kim Cascone wrote:
>> Mathieu Bouchard wrote:
>>> I would have done it like this if [print] was able to handle extra 
>>> atom types.
>> ok but the problem still exists with passing parentheses which is 
>> blocking some data from be sent to the console...or has this been 
>> fixed? just curious
>
> I will reply in public because I don't see any reason why you replied 
> in private nor any reason why I couldn't reply back to the list.
only because some of your emails to me were in private and some were 
Cc'd to the list and I couldn't remember whether or not I was replying 
to a private or public email of yours...
>
> I haven't "fixed" the parentheses yet. This will really involve making 
> a second kind of GridFlow class, which will not go through the 
> parens-filter at all. (I don't see what else I could do).
OK -- in that case it should be spelled out clearly for people somewhere 
(in the console? or help file?) that the [print] object they think they 
are instantiating is not the standard one from pd and is in fact the 
[print] from the GridFlow library

case in point: the problem I encountered trying to get [info] from 
[plugin~] using the [gf.print] thinking I was using the standard Pd 
[print] object
>
>> ok so you're swapping print objects under-the-hood in order to have 
>> more atom types available with the GridFlow [print] when using other 
>> objects from the GridFlow library?
>
> yes.
>
>> is there a way the object instantiated could have [gf.print] on it 
>> instead of just [print]?
>
> no, because the point is to prevent Pd's [print] from running when I 
> type [print],
sorry I meant is there a way to LABEL the actual external in the patch 
so that it says [gf.print] without changing its behavior under the hood?

the user could still type in [print] but the object that would appear 
would have [gf.print] written on it instead

also, there should be a warning in the console stating when 
instantiating this object:
*'this [print] is not the standard pd object. To use that object type 
[pd/print]'*

> because it would print disquieting error messages looking like a bug. 
> I think that it's better than pretending to use DS pointers like GEM 
> does and GF used to do, for lack of an extensible typesystem.
>




More information about the Pd-list mailing list