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

[IOhannes m zmoelnig]

On 2010-06-15 08:11, Jonathan Wilkes wrote:
> Matju,
>      Does the most recent version of GF post an informative message to the console when the user first 
> creates a [print] object?  (In 9.8 on winxp it doesn't.)  If not, it should.
> 
> Or, why don't you just call your object [post]?  That way when it replaces [print] there will be one less
> character to type.
> 

this kind of defies one of the purposes of "dynamic libraries", no?


let's make a very simple Gem-centered example:
as you all know, Gem is based on openGL.
now openGL is a bit weirdish, since it will behave differently depending
on the libraries installed on your computer. sometimes it will use
hardware acceleration, but if the proper libraries cannot be found, it
will simply resort to software rendering.
the results will be different: sw-rendering will be magnitudes slower,
but also the rendered image is not guaranteed to be identical.
however, the standard guarantees that the difference are "sufficiently
small".
if Gem was doing like most of you suggest, there would need to have
separate objects for hardware accelerated rendering and software
rendering. e.g. [Gem.sw.cube] vs [Gem.hw.cube], [Gem.sw.translate] vs
[Gem.hw.translate] and so on.
now this might be interesting in some cases (i remember a feature
request for sw-rendering in an environment with hw acceleration), but in
general, i'm sure that i would not want to have to rewrite every single
patch i developed on my prehistoric netbook to be able to run at the
final target architecture.
as a matter of fact, i think it is an advantage that the user has not to
be aware of the underlying components so much (though with recent openGL
this became a bit more complicated; however that's an entirely different
story)

of course this openness sometimes leads to some problems.
e.g. the user of Gem doesn't really know whether hw acceleration will be
available. Gem does print something to the console when it detects DRI
(on linux), but this info probably doesn't tell you enough (and it's
linux only).

also, an openGL implementation might choose to not fully implement the
standard and decide to drop the green color (as it's not needed anyhow).
most people will probably see this as a bug, as they will get results
they did not expect at all. they should write to the implementor and
complain, so the bug will probably be fixed (or the implementor
convinces all people that they really don't need green).


i personally think that GF's [print] implementation is buggy, as it is
not able to print symbols with parenthesis correctly in some circumstances.
this bug should be fixed (if this involves rewriting the entire parsing
machine for nested lists, then this is unfortunate but cannot be helped;
our openGL implementor probably had good reasons to leave out the green
channel as well)

i also think that Pd's [print] implementation is buggy, as it doesn't
deal correctly with simple characters like comma, semicolon and braces.
it's even more buggy, as it will print a scary warning about "bug" and
"inconsistency" whenever it encounters something it doesn't know about.


all in all i think it likely that GF's implementation is less buggy than
the vanilla implementation.

fgmkasdr
IOhannes






-------------- 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/6f9f5525/attachment.bin>