[PD] plugin~ external
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
>> 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?
>> 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
> 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