[GEM-dev] "context" with [gemcontrol] or "gemoutput"

[IOhannes m zmoelnig]

james tittle wrote:
> On Feb 4, 2005, at 4:04 AM, IOhannes m zmoelnig wrote:
> 
> 
> ...so, this is different than what I first assumed:  when I first got 
> this stuff working, I thought that all outputs went to the same 
> [gemcontrol], or rather that there would only be one [gemcontrol] per 
> patch...but now, I know this is not the case, and my original thoughts 

yes, i think that objects controlling static contexts (uhh, the buzzword 
again, now in a different "context") are not very pd-like.
that's one of the reasons why i wanted [gemwin] to go away.

having several [gemcontrol]s manipulate the same static whatever, makes 
things a bit better, but still it is not what i really like.
(although i think, my talk at pd04 was exactly about "moving static 
things from [gemwin] to [gemcontrol]...)

> need to be amended:  fortunately, it seems that most stuff just get 
> shifted from the output module "up" to the associated [gemcontrol]

right, but


> 
> ...in this regard, we'd have the possibility of multiple [gemcontrol]'s 
> that would would basically take care of everything (ie. background 
> color, viewpoint, framerate,...) except for the actual output;  the 
> output would would then be the attached [gemwindow], [gemextwindow], or 
> [gempbuffer], and all attached outputs would do the same graphic, only 
> varying as to which window/screen/offscreen/whatever...
> 
> ...this moves the earlier idea of symbolic name associations to the 
> [gemcontrol], so we'd have a different [gemcontrol] for each unique 
> output desired...and [gemhead] stays the same, with both a priority and 
> symbolic name association(s)...

right, that's what i was trying to say in one of my last emails.

> 
> ...this all works fine if everything is running at the same framerate, 
> but like you pointed out in a later email, what happens if two 
> [gemcontrol]'s are running at different frame rates and both pull data 
> from the same [gemhead]?

this is what i meant with "timing issues".

> 
> ...an easy way around this would be to limit the amount of 
> associations:  one [gemhead] can hook/associate with only one 
> [gemcontrol]:  if similar [gemhead] functionality is needed for another 
> [gemcontrol], then just duplicate the [gemhead] and change it's symbol 
> association...

i do not like this, as it makes several things unnecessarily 
complicated. if i want to do stereo-viewing i should not need to build 
the whole gem-patch double, but i want to be able to just say: "this 
should go to both screens, but with different viewpoints"


> 
> ...beyond that, I guess we'd need some universal time keeping mechanism 
> above the level of [gemcontrol], or rather as part of GemMan...this 
> really makes the mind reel!  I'd have to think alot more, and me head 
> hoit!  :-\

although i dont think that it is (should not be) too complicated, i agree.



mfg.hmm.hmm
IOhannes