[GEM-dev] Re: "blend"-messages

[IOhannes m zmoelnig]

tigital wrote:
> On Tuesday, July 22, 2003, at 01:11  PM, IOhannes m zmoelnig wrote:
> 
>> 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.
still, you have done quite well (i dare say)


>> 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?

well, of course, and i was laughing at myself while typing in the 
sentence for the second time...
anyhow, 27.

> 
>> 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...

yes, but what should we do ? get a hand on miller and...

>>
>> 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, 

and often i find features i have coded myself and didn't know ....

> 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?

personally i'd prefer the [alpha] object.
it is just:
manips are manips and geos are geos (for me geos are just drawable 
forms, they don't know anything about color and antialiasing and)

mfg.as.rd
IOhannes