On Tuesday, July 22, 2003, at 01:11 PM, IOhannes m zmoelnig wrote:
tigital wrote:
On Tuesday, July 22, 2003, at 05:06 AM, IOhannes m zmoelnig wrote:
hi
i don't think, that there is any performance-issue in this, and it could save us all (jamie) a lot of time...
...sure, I'd love to save some time: who wouldn't? I've actually been reading stroustrup to bone up on c++ stuff (remember: I was schooled as a neurobiologist, not a computer scientist); when I started the porting of GEM to OSX last year (and we are about at it's one year mark), I knew nothing beyond c...
do i hear some sarcasm?
...eeek, no! I was just stating my by now obvious limited knowledge of C++ features, such as "inheritance" and "polymorphism": didn't know them beyond buzzwords 3 days ago, but now understand...
anyhow, great things you have done so far.
...chris and I actually talked about this blending stuff last weekend; we knew that alpha was a possibility, but didn't know if it was a full replacement...also, it takes less space in a patch to have a number going into a blend message than it does to have a number going into a colorRGB that goes into alpha that goes into the geo...I was just uninformed of other ways to do blending and needed a transparent cube...but at the same time you mention that alpha is somehow inconsistent: how so? Does it allow internal transparancy (back to front & front to back)?
hm. i cannot quite follow the example with all the numbers going in and out objects (that's the second mail today, i don't understand, maybe i get old ?)
...only as old as ya feel! That sentence was a bit of a run-on...sorry...btw, I'm 37: how old are you other guys?
basically, you are saying, that it is preferrable to have smaller patches than bloated ones. this of course is true, but i don't think 2 additional objects will bloat a patch. then i think, a patch is clearer if its functionality is defined by its (graphical) structure (connecting [objects]) and not by internal states of objects (connecting with [messages( )
...I agree, it's nice when you can look at something and tell what it does or doesn't do...unfortunately, that's not the pd/Gem way, what with unlabeled inlets/outlets and sometimes cryptic object names...
as for the inconsistency: back then in february, i added an argument to the [alpha] object which allowed the setting of the blending function. right now, there are only 2 blending functions (GL_ONE and GL_ONE_MINUS_SRC_ALPHA) and they are addressed arbitrarily with "1" and everything else - this is i find not very intuitive which i addressed as "inconsistent".
as for documentation: indeed gem has become big and undocumented (alas!, this is no news), when even the developers are not informed on features.
....yep, it's as simple as that: I didn't know about the feature, yet knew how to add the blend function to the object...let's move on...uh, that is, after we decide: do we remove the blend message from geos that have it and advertise (and expand) the beauties of [alpha], or do we make it from the objects that have it now and make it an inheritable method?
l8r, jamie
ps: I like the fact that we're talking about this stuff, let's keep up the open dialogue