[PD] overriding plugin names (was Re: plugin~ external)

Hans-Christoph Steiner hans at at.or.at
Tue Jun 15 20:47:16 CEST 2010


The key different between your Gem example and the GF vs. Pd [print]  
is that you are talking about objects within the same library.  The  
[print] issue is about a library versus core.  Overriding core objects  
in a library seems like a bad idea, especially when its so simple to  
call it something different.

.hc

On Jun 15, 2010, at 4:07 AM, IOhannes m zmoelnig wrote:

> On 2010-06-12 01:23, Kim Cascone wrote:
>> IOhannes m zmölnig wrote:
>>> most users should never notice (unless in a pleasant way).
>> if you instantiate a [print] object
>> and don't know whether you are loading a buggy GridFlow [print]  
>> object
>> or a working Pd [print] object
>> then how is this logical, clear or concise?
>
> most discussion here is very centered around the patching process.
> please don't forget about just loading a patch (and about using  
> premade
> abstractions for that matter).
>
> so if you load a patch with 87 [print]'s in there, what information do
> you get if Pd prints 86 times "dear user\, you are using matju's  
> special
> [print]\, which has problems with parens".
> and how do you relate one of these warnings to a specific object?
> (luckily the warning mentions [print] in my example)
> and what happened to the 1 object that had no printout?
>
>
> and if it only should print once (as somebody suggested on the list):
> this should actually be done by Pd anyhow.
>
>
> e.g. zexy comes with a version of "wrap" that is (imo) superior to the
> one that comes with Pd-vanilla. (and no, i will not remove "wrap" from
> zexy. it has been there for ages). whenever you load zexy's wrap  
> (which
> is normally simply done by loading "zexy", but in PdX it might be very
> complicated), then zexy will overwrite the built-in wrap by it's own.
> Pd will then print:
> "warning: class 'wrap' overwritten\; old one renamed 'wrap_aliased'"
>
> so you have been warned.
>
> most likely the same happens when you load gridflow (unless matju has
> done some weird hacking)
>
>
>>
>> doesn't it make more sense to differentiate the two
>> by calling one [gf_print]
>> and the other [print]?
>
> it would offload the task for correctly printing a message from Pd to
> the user.
> computers are mainly thought of as devices to offload tasks from the
> user rather than towards the user (though this often fails)
>
>>
>> this way if I want to use a property of the GridFlow [print] object  
>> for
>> some reason I know I can call it using its name
>>
>
> why would you?
>
> why don't you think just fixing the obvious bug in GF's print won't  
> help
> you more?
>
> if you don't want to use GF's [print], then you probably don't want to
> use GF as well. in this case you probably don't want to load GF at  
> all,
> which will magically evaporate the problem.
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



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

The arc of history bends towards justice.     - Dr. Martin Luther  
King, Jr.





More information about the Pd-list mailing list