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

Jonathan Wilkes jancsika at yahoo.com
Tue Jun 15 12:32:11 CEST 2010


Thanks for changing the subject line.

In your example, why wouldn't the developer just add a method so the user can send a message to set 
hardware or software acceleration (or query to see if hw accel. is available) if they wish to do so explicitly?


Anyway, I think my [post] vs. [print] question is really beside the point.  What I want to know is if 
[gf.print] is an improvement over the current [print], why doesn't it just get incorporated into Pd?  It 
doesn't make sense that someone should have to download and install GF to get a less buggy [print] object.

I don't understand what you were talking about in that other thread when you wrote about 87 objects 
in a patch that post a message to the console 86 times.  I've never seen this happen.  Most objects that post 
a console message only do so when the first instance is created, whether by actively patching or by opening 
a file.  (See [expr] for an example of this.)

-Jonathan



________________________________
From: IOhannes m zmoelnig <zmoelnig at iem.at>
To: Jonathan Wilkes <jancsika at yahoo.com>
Cc: Mathieu Bouchard <matju at artengine.ca>; Roman Haefeli <reduzierer at yahoo.de>; pd-list <pd-list at iem.at>; Kim Cascone <kim at anechoicmedia.com>
Sent: Tue, June 15, 2010 12:39:19 AM
Subject: overriding objects (was Re: [PD] plugin~ external)

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100615/70313839/attachment.html>


More information about the Pd-list mailing list