...I guess I kinda overlooked this issue that IOhannes brought up: actually, I didn't realize that the idea was to have multiple [gemcontrol]'s possible! So this makes more sense...the [gemcontrol]'s should have the "output"-association/symbol, and then just pass that on to whatever is hooked up to that particular control...
...but one thing I'm not understanding: when I have multiple [gemcontrol]'s, a "render on" message to one turns all of them on: it seems like this should be seperated, right? Especially if we're gonna have the ability to alter the frame rate...
hmm, jamie
james tittle wrote:
...but one thing I'm not understanding: when I have multiple [gemcontrol]'s, a "render on" message to one turns all of them on: it seems like this should be seperated, right? Especially if we're gonna have the ability to alter the frame rate...
right, it is just not yet implemented... (as it would have involved further changes to GemMan, and i was just happy that at least i got multiple windows rendering (more or less) the same....
now what comes to my mind:
should things like background-colour, viewpoint, etc be handled in the GemOutput (as [gemwindow]) or in [gemcontrol] ? i always thought they could be handled by GemOutput, but i am not so sure about this anymore (i guess i put it into GemOutput since [gemcontrol] was still static and i wanted to be able to change the viewport on the different windows independently.
i (now) mean that for a clear separation, "context" (again probably missusing this term) details should be handled within [gemcontrol]. but then we would need some way of synchronizing various independent [gemcontrol]s (e.g. for cave-like applications), probably again by associating the context with a symbolic id (the same as in [gemhead])
i guess this might make sense.
mfg.asd.r IOhannes
hmm,
:-)
jamie
On Feb 4, 2005, at 4:04 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
...but one thing I'm not understanding: when I have multiple [gemcontrol]'s, a "render on" message to one turns all of them on: it seems like this should be seperated, right? Especially if we're gonna have the ability to alter the frame rate...
right, it is just not yet implemented... (as it would have involved further changes to GemMan, and i was just happy that at least i got multiple windows rendering (more or less) the same....
...that's ok: I just didn't know what the status was...
now what comes to my mind:
should things like background-colour, viewpoint, etc be handled in the GemOutput (as [gemwindow]) or in [gemcontrol] ? i always thought they could be handled by GemOutput, but i am not so sure about this anymore (i guess i put it into GemOutput since [gemcontrol] was still static and i wanted to be able to change the viewport on the different windows independently.
i (now) mean that for a clear separation, "context" (again probably missusing this term) details should be handled within [gemcontrol]. but then we would need some way of synchronizing various independent [gemcontrol]s (e.g. for cave-like applications), probably again by associating the context with a symbolic id (the same as in [gemhead])
...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 need to be amended: fortunately, it seems that most stuff just get shifted from the output module "up" to the associated [gemcontrol]
...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)...
...typical rendering would run much the same as it does now, with GemMan going thru the gemheadLink list and rendering by priority, then passing the created display lists to the correct gemcontrol based on their symbol association...
...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]?
...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...
...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! :-\
hmm, jamie
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
...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.
to sort things out, i have started a GemWikiWiki on puredata.org
it is probably better to do common thinking on a wiki-page than via the mailing-list (better ways of organizing things)
i would invite everyone to share their ideas of how things should work and how they might be implemented at http://puredata.org/Members/zmoelnig/GemWiki/
you have to be logged in to change things.
mfg,.a.sdr IOhannes
On Feb 8, 2005, at 9:36 AM, IOhannes m zmoelnig wrote:
...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.
to sort things out, i have started a GemWikiWiki on puredata.org
it is probably better to do common thinking on a wiki-page than via the mailing-list (better ways of organizing things)
i would invite everyone to share their ideas of how things should work and how they might be implemented at http://puredata.org/Members/zmoelnig/GemWiki/
...cool idea! Certainly better than wading thru emails...I'll be able to play with it more this evenin'...
l8r, jamie