<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">Thanks for changing the subject line.<br><br>In your example, why wouldn't the developer just add a method so the user can send a message to set <br>hardware or software acceleration (or query to see if hw accel. is available) if they wish to do so explicitly?<br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br>Anyway, I think my [post] vs. [print] question is really beside the point. What I want to know is if <br>[gf.print] is an improvement over the current [print], why doesn't it just get incorporated into Pd? It <br>doesn't make sense that someone should have to download and install GF to get a less buggy [print] object.<br><br>I don't understand what you were talking about in that other thread when you wrote about 87 objects <br>in a patch that
post a message to the console 86 times. I've never seen this happen. Most objects that post <br>a console message only do so when the first instance is created, whether by actively patching or by opening <br>a file. (See [expr] for an example of this.)<br><br>-Jonathan<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> IOhannes m zmoelnig <zmoelnig@iem.at><br><b><span style="font-weight: bold;">To:</span></b> Jonathan Wilkes <jancsika@yahoo.com><br><b><span style="font-weight: bold;">Cc:</span></b> Mathieu Bouchard <matju@artengine.ca>; Roman Haefeli <reduzierer@yahoo.de>; pd-list <pd-list@iem.at>; Kim Cascone <kim@anechoicmedia.com><br><b><span style="font-weight: bold;">Sent:</span></b> Tue, June 15, 2010 12:39:19 AM<br><b><span style="font-weight: bold;">Subject:</span></b>
overriding objects (was Re: [PD] plugin~ external)<br></font><br>
On 2010-06-15 08:11, Jonathan Wilkes wrote:<br>> Matju,<br>> Does the most recent version of GF post an informative message to the console when the user first <br>> creates a [print] object? (In 9.8 on winxp it doesn't.) If not, it should.<br>> <br>> Or, why don't you just call your object [post]? That way when it replaces [print] there will be one less<br>> character to type.<br>> <br><br>this kind of defies one of the purposes of "dynamic libraries", no?<br><br><br>let's make a very simple Gem-centered example:<br>as you all know, Gem is based on openGL.<br>now openGL is a bit weirdish, since it will behave differently depending<br>on the libraries installed on your computer. sometimes it will use<br>hardware acceleration, but if the proper libraries cannot be found, it<br>will simply resort to software rendering.<br>the results will be different: sw-rendering will be magnitudes slower,<br>but
also the rendered image is not guaranteed to be identical.<br>however, the standard guarantees that the difference are "sufficiently<br>small".<br>if Gem was doing like most of you suggest, there would need to have<br>separate objects for hardware accelerated rendering and software<br>rendering. e.g. [Gem.sw.cube] vs [Gem.hw.cube], [Gem.sw.translate] vs<br>[Gem.hw.translate] and so on.<br>now this might be interesting in some cases (i remember a feature<br>request for sw-rendering in an environment with hw acceleration), but in<br>general, i'm sure that i would not want to have to rewrite every single<br>patch i developed on my prehistoric netbook to be able to run at the<br>final target architecture.<br>as a matter of fact, i think it is an advantage that the user has not to<br>be aware of the underlying components so much (though with recent openGL<br>this became a bit more complicated; however that's an entirely different<br>story)<br><br>of course
this openness sometimes leads to some problems.<br>e.g. the user of Gem doesn't really know whether hw acceleration will be<br>available. Gem does print something to the console when it detects DRI<br>(on linux), but this info probably doesn't tell you enough (and it's<br>linux only).<br><br>also, an openGL implementation might choose to not fully implement the<br>standard and decide to drop the green color (as it's not needed anyhow).<br>most people will probably see this as a bug, as they will get results<br>they did not expect at all. they should write to the implementor and<br>complain, so the bug will probably be fixed (or the implementor<br>convinces all people that they really don't need green).<br><br><br>i personally think that GF's [print] implementation is buggy, as it is<br>not able to print symbols with parenthesis correctly in some circumstances.<br>this bug should be fixed (if this involves rewriting the entire parsing<br>machine for
nested lists, then this is unfortunate but cannot be helped;<br>our openGL implementor probably had good reasons to leave out the green<br>channel as well)<br><br>i also think that Pd's [print] implementation is buggy, as it doesn't<br>deal correctly with simple characters like comma, semicolon and braces.<br>it's even more buggy, as it will print a scary warning about "bug" and<br>"inconsistency" whenever it encounters something it doesn't know about.<br><br><br>all in all i think it likely that GF's implementation is less buggy than<br>the vanilla implementation.<br><br>fgmkasdr<br>IOhannes<br><br><br><br><br><br><br></div></div>
</div><br>
</body></html>