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@iem.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Mathieu Bouchard matju@artengine.ca; Roman Haefeli reduzierer@yahoo.de; pd-list pd-list@iem.at; Kim Cascone kim@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