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

[IOhannes m zmoelnig]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100615/58212624/attachment-0001.bin>