james tittle wrote:
yallo,
...ok, checked it out and started compiling and stuff...immediately ran
fine.
into a prob with the triggerMotionEvent(), which apparently takes four
admittedly triggerMotionEvent (or rather: all of the hid-things like mouse, keyboard and probably tabled) does not really work yet in multiple_windows. we should discuss this (that is why i put this on gem-dev too):
[gemmouse] outputs (as we all know) the mouse-position in the gem-window. now what happens if we have several gemwindows ? i think it there should be a mechanism to get the mouse-coordinates attached to the window the mouse appears in. this is not really possible with [gemmouse]. furthermore, [gemmouse] has several limitations (e.g.: no scroll-wheel support; what about mice with 10 buttons ?)
now what should we do about it ? probably the simplest thing (as it is e.g. in pdp) would be to add an outlet to the various gem-windows that would emit the state of the mouse (or of any pointer). we could then build an abstraction (or do it in C) that sends this data to [gemmouse] which would act as a global receiver.
as for outlets: personally i think by now(;-)) that it might be best to have just one outlet and prefix the outgoing messages, like [mouse <x> <y> <bt1> <bt2> <bt3>( this way we could always add another parameter to a certain message or just use a new message like [mouse_pos <x> <y>( [mouse_button 3 1( ok, the last 2 don't sound too convincing.
anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>(
args: x, y, w, & h...why were the w & h added? I assume this is width and height of the window that is being tracked?
yes. the idea was to get away from absolute coordinates. i mean, you had to rewrite (well: adjust) your patch everytime you changed the window-dimensions (e.g. developping with a small window and performing with a big one) so i though normalized coordinates would be a cool thing (e.g. 0/0 is always upper left, 1/1 is lower/right) to make it compatible with older versions of [gemmouse] (else this would break every single patch that uses [gemmouse]) i decided to make this behaviour dependent on parameters. so you could give the maximum output range as arguments [gemmouse 1 1] would normalize x & y between 0..1 [gemmouse 10 20] would scale x between 0..10 and y between 0..20 ideally [gemmouse 1] would scale x&y between 0..1 on square windows and between 0..1 and 0..x/y (or the other way around ? thats the big question; i think i t would be better to fix the y-axis and scale x appropriately as this would make "moving objects with the mouse" much easier) on rectangle windows.
mfg.as.dr IOhannes
On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
[gemmouse] outputs (as we all know) the mouse-position in the gem-window. now what happens if we have several gemwindows ? i think it there should be a mechanism to get the mouse-coordinates attached to the window the mouse appears in. this is not really possible with [gemmouse]. furthermore, [gemmouse] has several limitations (e.g.: no scroll-wheel support; what about mice with 10 buttons ?)
...the way input works in osx is that whenever a window is created, you install some events that you are interested in (ie. mouse location)...then, whenever that event is seen during the event loop, the message is sent to the windows callback loop, and something can be done or not...one of the cool things here is that it can (and does atm) report back which window the event happened in...
...also, as it is, the mouse coords are already converted to the "local" coords of the window, but they don't have to be...
now what should we do about it ? probably the simplest thing (as it is e.g. in pdp) would be to add an outlet to the various gem-windows that would emit the state of the mouse (or of any pointer). we could then build an abstraction (or do it in C) that sends this data to [gemmouse] which would act as a global receiver.
...ok, an outlet would be sensible: maybe we should output window relative AND global coords?
as for outlets: personally i think by now(;-)) that it might be best to have just one outlet and prefix the outgoing messages, like [mouse <x> <y> <bt1> <bt2> <bt3>(
...so this is a message that is output by the window?
anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>(
...again, should this be output by the window, or is it just received?
args: x, y, w, & h...why were the w & h added? I assume this is width and height of the window that is being tracked?
yes. the idea was to get away from absolute coordinates. i mean, you had to rewrite (well: adjust) your patch everytime you changed the window-dimensions (e.g. developping with a small window and performing with a big one) so i though normalized coordinates would be a cool thing (e.g. 0/0 is always upper left, 1/1 is lower/right)
...I thought we could already normalize with gemmouse? It can take a scale value for x & y, at least...and there is already mousewheel support: in the case of OSX, it's just another event message that is installed at window creation...
...so maybe we need to look at the specifics on individual platforms?
l8r, jamie
james tittle wrote:
On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
...also, as it is, the mouse coords are already converted to the "local" coords of the window, but they don't have to be...
so "local" means that 0/0 is in some (probably the upper/left) corner (?)
...ok, an outlet would be sensible: maybe we should output window relative AND global coords?
well, i am not sure whether global coordinates are really that important, it would be more important to get the window-position (aka "offset") when the window is moved.
as for now, all implementations of [gemmouse] (or rather, the underlying callback-code) output the local coordinates.
as for outlets: personally i think by now(;-)) that it might be best to have just one outlet and prefix the outgoing messages, like [mouse <x> <y> <bt1> <bt2> <bt3>(
...so this is a message that is output by the window?
yes, that's what i meant.
anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>(
...again, should this be output by the window, or is it just received?
both. here i was referring to the output of the window, but of course we setting the window-size with "dimen x y" should still be possible.
i just took the same name because it was the first that came to my mind. i guess "dimen" (as output) is the choice to stay somewhat consistent ("size" never really made it for whatever reasons), but i see that it is somewhat confusing when talking about ideas.
...I thought we could already normalize with gemmouse? It can take a scale value for x & y, at
yes, that is what i was talking about. and i think that that is the reason why there are those additional arguments. not sure without looking at the code; but i guess until now the window-dimension (needed for normalization) was just read from the GemMan variables. this will of course not work any more, if we have multiple windows with different sizes which would be stored as class-members within the GemWindow.
least...and there is already mousewheel support: in the case of OSX, it's just another event message that is installed at window creation...
yes i know. but how is it handled, is there a 6th outlet to [gemmouse] ? or is it packed into the 4th outlet (middle button) somehow ?
the question is how to do data-retrieval (big words) in a way that is easy to extend for future use. [gemmouse] was just an example, because you ran into some problems when you wanted to add the scroll-wheel without breaking things. messages are probably simpler to extend than object-APIs. and just to think about [gemtablet] (which i have never used because of lack of tablets) which has about 10 outlets and what happens if your brandnew tablets has 5 additional buttons ? add 5 other outlets ?
...so maybe we need to look at the specifics on individual platforms?
again i was not talking about the implementations but rather how to get it right before too much work is done (avoiding frustration)
mfg.a.sdr IOhannes
On Dec 1, 2004, at 10:46 AM, IOhannes m zmoelnig wrote:
james tittle wrote:
On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
...also, as it is, the mouse coords are already converted to the "local" coords of the window, but they don't have to be...
so "local" means that 0/0 is in some (probably the upper/left) corner (?)
...yup...
i just took the same name because it was the first that came to my mind. i guess "dimen" (as output) is the choice to stay somewhat consistent ("size" never really made it for whatever reasons), but i see that it is somewhat confusing when talking about ideas.
...dimen sounds good to me...I'm just a bit new to outputting messages with lists/arguments instead of just numbers :-)
...I thought we could already normalize with gemmouse? It can take a scale value for x & y, at
yes, that is what i was talking about. and i think that that is the reason why there are those additional arguments. not sure without looking at the code; but i guess until now the window-dimension (needed for normalization) was just read from the GemMan variables. this will of course not work any more, if we have multiple windows with different sizes which would be stored as class-members within the GemWindow.
...ok, so this makes sense! Now I just need to figure out, given a WindowRef in a callback, how do I get the dimensions?
yes i know. but how is it handled, is there a 6th outlet to [gemmouse] ? or is it packed into the 4th outlet (middle button) somehow ?
...I'm pretty sure I just globbed on an outlet: actually, now I think I remember not putting in an output because of the following problems you highlight:
the question is how to do data-retrieval (big words) in a way that is easy to extend for future use. [gemmouse] was just an example, because you ran into some problems when you wanted to add the scroll-wheel without breaking things. messages are probably simpler to extend than object-APIs. and just to think about [gemtablet] (which i have never used because of lack of tablets) which has about 10 outlets and what happens if your brandnew tablets has 5 additional buttons ? add 5 other outlets ?
...ok, now I understand what you were getting at: again, I don't have much experience with writing objects that emit messages...but it seems the way to go!
jamie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
I have two questions and one suggestion:
Q1: How far along are things for multiple windows? (time-wise) Q2: Will multiple windows open the door to render to a texture as if it was just another window? (I can think of many uses for this in relation to pixelTANGO)
Suggestion:
What if there is a gemwin outlet that deals with all input events, keyboard, mouse etc.. The format could follow the HID format, which would mean that abstractions made to work with HID would be fully compatible with Gem window events... I think this would be very nice to share the same format to get the data. I'm sure there are some ugly implications of saying this but I think it would be nice to be able to use the same abstractions to parse/smooth and genrally work with input data (tablet, mouse, keyboard etc..)
B.
IOhannes m zmoelnig wrote: | james tittle wrote: | |> On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote: | | |> ...also, as it is, the mouse coords are already converted to the |> "local" coords of the window, but they don't have to be... | | | so "local" means that 0/0 is in some (probably the upper/left) corner (?) | |> ...ok, an outlet would be sensible: maybe we should output window |> relative AND global coords? | | | well, i am not sure whether global coordinates are really that | important, it would be more important to get the window-position (aka | "offset") when the window is moved. | | as for now, all implementations of [gemmouse] (or rather, the underlying | callback-code) output the local coordinates. | |> |>> as for outlets: |>> personally i think by now(;-)) that it might be best to have just one |>> outlet and prefix the outgoing messages, like |>> [mouse <x> <y> <bt1> <bt2> <bt3>( |> |> |> |> ...so this is a message that is output by the window? | | | yes, that's what i meant. | |> |>> anyhow, we need several messages to query things like the dimension |>> of the window (or whatever): [dimen <x> <y>( |> |> |> ...again, should this be output by the window, or is it just received? | | | both. | here i was referring to the output of the window, but of course we | setting the window-size with "dimen x y" should still be possible. | | i just took the same name because it was the first that came to my mind. | i guess "dimen" (as output) is the choice to stay somewhat consistent | ("size" never really made it for whatever reasons), but i see that it is | somewhat confusing when talking about ideas. | |> |> ...I thought we could already normalize with gemmouse? It can take a |> scale value for x & y, at | | | yes, that is what i was talking about. | and i think that that is the reason why there are those additional | arguments. not sure without looking at the code; but i guess until now | the window-dimension (needed for normalization) was just read from the | GemMan variables. this will of course not work any more, if we have | multiple windows with different sizes which would be stored as | class-members within the GemWindow. | | |> least...and there is already mousewheel support: in the case of OSX, |> it's just another event message that is installed at window creation... | | | yes i know. | but how is it handled, is there a 6th outlet to [gemmouse] ? or is it | packed into the 4th outlet (middle button) somehow ? | | the question is how to do data-retrieval (big words) in a way that is | easy to extend for future use. | [gemmouse] was just an example, because you ran into some problems when | you wanted to add the scroll-wheel without breaking things. | messages are probably simpler to extend than object-APIs. | and just to think about [gemtablet] (which i have never used because of | lack of tablets) which has about 10 outlets and what happens if your | brandnew tablets has 5 additional buttons ? add 5 other outlets ? | | |> ...so maybe we need to look at the specifics on individual platforms? | | | again i was not talking about the implementations but rather how to get | it right before too much work is done (avoiding frustration) | | | mfg.a.sdr | IOhannes | | _______________________________________________ | GEM-dev mailing list | GEM-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/gem-dev |
On Dec 1, 2004, at 1:18 PM, B. Bogart wrote:
Q1: How far along are things for multiple windows? (time-wise)
...as I understand, IOhannes has had a working proposition for linux in cvs since sometime in august...I'm just now getting around to try it out on OSX, and I don't know what's going on with windoze...in any event, there's no way to estimate a time to completion :-/
Q2: Will multiple windows open the door to render to a texture as if it was just another window? (I can think of many uses for this in relation to pixelTANGO)
...yep, that's my main motiviation (err, at least render to pBuffer)...but it also means all kinds of other things, like web browsers or screen windows if you can't see your second display!
What if there is a gemwin outlet that deals with all input events, keyboard, mouse etc.. The format could follow the HID format, which would mean that abstractions made to work with HID would be fully compatible with Gem window events
...are you talking about something in specific? I'm not familiar with what the "HID format" is: can you provide a link? (sorry Hans! I haven't been following the HID stuff closely ;-| )
l8r, jamie
james tittle wrote:
On Dec 1, 2004, at 1:18 PM, B. Bogart wrote:
What if there is a gemwin outlet that deals with all input events, keyboard,
that is basically what i was talking about...
mouse etc.. The format could follow the HID format, which would mean that abstractions made to work with HID would be fully compatible with Gem window events
...are you talking about something in specific? I'm not familiar with what the "HID format" is: can you provide a link? (sorry Hans! I haven't been following the HID stuff closely ;-| )
me neither; but probably we should have a look at it as i think hans has really spent some thinking on how to do it properly
mfg.a.sdr IOhannes
Hi there!
just wanna give my two cents since i just subscribed to gem-dev :)
in respect to compatibility with older gem patches, one could add another outlet to [gemmouse] which would output the window number the mouse event happened in, so one could pack the coordinates and the window number into a list and [route] this list according to the window the mouse event happened in... (but for this to work, the extra outlet would have to be added at the left, rendering all compatibility options useless?!)
ok, as i said my 0.2 $, :)
good luck for the multiple gemwin feature!
Peter P.
IOhannes m zmoelnig wrote:
james tittle wrote:
On Dec 1, 2004, at 1:18 PM, B. Bogart wrote:
What if there is a gemwin outlet that deals with all input events, keyboard,
that is basically what i was talking about...
mouse etc.. The format could follow the HID format, which would mean that abstractions made to work with HID would be fully compatible with Gem window events
...are you talking about something in specific? I'm not familiar with what the "HID format" is: can you provide a link? (sorry Hans! I haven't been following the HID stuff closely ;-| )
me neither; but probably we should have a look at it as i think hans has really spent some thinking on how to do it properly
mfg.a.sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
peter plessas wrote:
Hi there!
just wanna give my two cents since i just subscribed to gem-dev :)
i'll answer to give you some reply
in respect to compatibility with older gem patches, one could add another outlet to [gemmouse] which would output the window number the mouse event happened in, so one could pack the coordinates and the window number into a list and [route] this list according to the window the mouse event happened in... (but for this to work, the extra outlet would have to be added at the left, rendering all compatibility options useless?!)
i think that [gemmouse] as it is, is not flexible enough. of course we could add an outlet for a window id (which gives us the problem about what is a window id ? settable by the user ? an automatic number (like $0) ?) and we could add an outlet for the scroll-wheel. and markus has a trackball with 5 buttons + scroll wheel, so we add another 2 outlets. by now we have outlets (in this sequence) for: x y bt1 bt2 bt3 window scroll bt4 bt5
honestly i think we should think about a flexible way how to handle it in the future without burden us about how it was handled in the past. and then (when we have found "the" solution) we should be able to easily make a compatibility object for the old behaviour.
just my 0.2 cigarettes.
mfg.a.sdr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
IOhannes m zmoelnig wrote: | that is basically what i was talking about...
Great.
| me neither; but probably we should have a look at it as i think hans has | really spent some thinking on how to do it properly
I think Hans has done a good job of dealing with it, and each kind of device, keyboard, mouse, tablet all send out data in the same way. I think it can only be a good thing if patches make to interpret HID data can be used to interpret Gem events.
Also I imagine an abstraction could be made that pretends to be gemmouse for backwards compatibility.
B.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
james tittle wrote:
| ...yep, that's my main motiviation (err, at least render to | pBuffer)...but it also means all kinds of other things, like web | browsers or screen windows if you can't see your second display!
All good reasons, what is the difference between a pbuffer and a texture? Part of the TOT project (of which pixelTANGO is a component) is corrective projection. Basically you calculate a 3D mesh to un-distort the image projected onto an irrefular surface. If we could render the window to a texture then we could apply this correction to the entire render window rather than only to the textures on objects.
B.
On Dec 1, 2004, at 4:37 PM, B. Bogart wrote:
All good reasons, what is the difference between a pbuffer and a texture? Part of the TOT project (of which pixelTANGO is a component) is corrective projection. Basically you calculate a 3D mesh to un-distort the image projected onto an irrefular surface. If we could render the window to a texture then we could apply this correction to the entire render window rather than only to the textures on objects.
...difference between pbuffer and texture isn't a whole lot...they're both graphic card memory/VRAM resident; pbuffers allow for floating point pixels, plus they're supposed to key into new accelerations on gpu's...basically, they're really the way to go for vertex/fragment shader render passes...
...as far as corrective projection, I did something like that several years ago with a theatre project: it was a weirdly shaped screen, and of course the projector was off angle...pretty neat how it worked out...
jamie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
james tittle wrote:
| ...difference between pbuffer and texture isn't a whole lot...they're | both graphic card memory/VRAM resident; pbuffers allow for floating | point pixels, plus they're supposed to key into new accelerations on | gpu's...basically, they're really the way to go for vertex/fragment | shader render passes...
Ok, so how to you put a pBuffer onto a texture in Gem? pix_pbuffer?
| ...as far as corrective projection, I did something like that several | years ago with a theatre project: it was a weirdly shaped screen, and | of course the projector was off angle...pretty neat how it worked out...
for more info: www.tot.sat.qc.ca under "english" then "lightTWIST" (site seems to be down right this moment...)
B.
hi,
After I've got the latest Gem.pd_darwin and working with multiple windows, it works perfectly but I've found that I can't play movie with pix_film and I can't create pix_movie, I've got the latest version complied on 31, Jan. Below is what I get in console,
gemwindow::resetValues entered GemOutput::resetState entered dimenMess gemwindow::resetValues entered GemOutput::resetState entered dimenMess dimenMess dimenMess MAC: createGemWindow() gemwindow: create window 476680 MAC: createGemWindow() GemwinMac: width - 320 height - 240 MAC: BuildGLonWindow entered MAC: BuildGLonWindow: fDraggable= false MAC: BuildGLonWindow: not draggable on single device MAC: BuildGLonWindow (!pcontextInfo->fDraggable && (numDevices == 1)) MAC: BuildGLonWindow exit GemWindow Activate err = 0 createGemWindow() finished hints: actuallyDisplay = 1 hints: border = 1 hints: width = 320 hints: height = 240 hints: real_w = 320 hints: real_h = 240 hints: x_offset = 0 hints: y_offset = 50 hints: fullscreen = 0 hints: border = 1 hints: display = (null) hints: title = GEM hints: shared = 0 hints: fsaa = 0 GEM: Start rendering error: GEM: pix_movie: Couldn't open the movie file: mix8.movT (-2020) GEM: pix_film: Loaded file: /Users/slimboyfatboyslim/project/Gotland/mix8.mov with 0 frames (0x0) tried /Users/slimboyfatboyslim/project/Gotland/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/extra/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/pdp_pidip_osx/doc/pidip/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/pdp_pidip_osx/abstractions/pix_movie.pd_darwin and failed tried /Applications/Pd-0.38-0test4HCS1.app/Contents/Resources/Scripts/../ extra/pix_movie.pd_darwin and failed tried /Users/slimboyfatboyslim/project/Gotland/pix_movie/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/extra/pix_movie/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/pdp_pidip_osx/doc/pidip/pix_movie/pix_movie.pd_darwin and failed tried /usr/local/lib/pd/pdp_pidip_osx/abstractions/pix_movie/ pix_movie.pd_darwin and failed tried /Applications/Pd-0.38-0test4HCS1.app/Contents/Resources/Scripts/../ extra/pix_movie/pix_movie.pd_darwin and failed tried /Users/slimboyfatboyslim/project/Gotland/pix_movie.pd and failed tried /usr/local/lib/pd/extra/pix_movie.pd and failed tried /usr/local/lib/pd/pdp_pidip_osx/doc/pidip/pix_movie.pd and failed tried /usr/local/lib/pd/pdp_pidip_osx/abstractions/pix_movie.pd and failed tried /Applications/Pd-0.38-0test4HCS1.app/Contents/Resources/Scripts/../ extra/pix_movie.pd and failed tried /Users/slimboyfatboyslim/project/Gotland/pix_movie.pat and failed tried /usr/local/lib/pd/extra/pix_movie.pat and failed tried /usr/local/lib/pd/pdp_pidip_osx/doc/pidip/pix_movie.pat and failed tried /usr/local/lib/pd/pdp_pidip_osx/abstractions/pix_movie.pat and failed tried /Applications/Pd-0.38-0test4HCS1.app/Contents/Resources/Scripts/../ extra/pix_movie.pat and failed pix_movie ... couldn't create
Cheers, SFS
On 1 Dec 04, at 7:18 PM, B. Bogart wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hey all,
I have two questions and one suggestion:
Q1: How far along are things for multiple windows? (time-wise) Q2: Will multiple windows open the door to render to a texture as if it was just another window? (I can think of many uses for this in relation to pixelTANGO)
Suggestion:
What if there is a gemwin outlet that deals with all input events, keyboard, mouse etc.. The format could follow the HID format, which would mean that abstractions made to work with HID would be fully compatible with Gem window events... I think this would be very nice to share the same format to get the data. I'm sure there are some ugly implications of saying this but I think it would be nice to be able to use the same abstractions to parse/smooth and genrally work with input data (tablet, mouse, keyboard etc..)
B.
IOhannes m zmoelnig wrote: | james tittle wrote: | |> On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote: | | |> ...also, as it is, the mouse coords are already converted to the |> "local" coords of the window, but they don't have to be... | | | so "local" means that 0/0 is in some (probably the upper/left) corner (?) | |> ...ok, an outlet would be sensible: maybe we should output window |> relative AND global coords? | | | well, i am not sure whether global coordinates are really that | important, it would be more important to get the window-position (aka | "offset") when the window is moved. | | as for now, all implementations of [gemmouse] (or rather, the underlying | callback-code) output the local coordinates. | |> |>> as for outlets: |>> personally i think by now(;-)) that it might be best to have just one |>> outlet and prefix the outgoing messages, like |>> [mouse <x> <y> <bt1> <bt2> <bt3>( |> |> |> |> ...so this is a message that is output by the window? | | | yes, that's what i meant. | |> |>> anyhow, we need several messages to query things like the dimension |>> of the window (or whatever): [dimen <x> <y>( |> |> |> ...again, should this be output by the window, or is it just received? | | | both. | here i was referring to the output of the window, but of course we | setting the window-size with "dimen x y" should still be possible. | | i just took the same name because it was the first that came to my mind. | i guess "dimen" (as output) is the choice to stay somewhat consistent | ("size" never really made it for whatever reasons), but i see that it is | somewhat confusing when talking about ideas. | |> |> ...I thought we could already normalize with gemmouse? It can take a |> scale value for x & y, at | | | yes, that is what i was talking about. | and i think that that is the reason why there are those additional | arguments. not sure without looking at the code; but i guess until now | the window-dimension (needed for normalization) was just read from the | GemMan variables. this will of course not work any more, if we have | multiple windows with different sizes which would be stored as | class-members within the GemWindow. | | |> least...and there is already mousewheel support: in the case of OSX, |> it's just another event message that is installed at window creation... | | | yes i know. | but how is it handled, is there a 6th outlet to [gemmouse] ? or is it | packed into the 4th outlet (middle button) somehow ? | | the question is how to do data-retrieval (big words) in a way that is | easy to extend for future use. | [gemmouse] was just an example, because you ran into some problems when | you wanted to add the scroll-wheel without breaking things. | messages are probably simpler to extend than object-APIs. | and just to think about [gemtablet] (which i have never used because of | lack of tablets) which has about 10 outlets and what happens if your | brandnew tablets has 5 additional buttons ? add 5 other outlets ? | | |> ...so maybe we need to look at the specifics on individual platforms? | | | again i was not talking about the implementations but rather how to get | it right before too much work is done (avoiding frustration) | | | mfg.a.sdr | IOhannes | | _______________________________________________ | GEM-dev mailing list | GEM-dev@iem.at | http://iem.at/cgi-bin/mailman/listinfo/gem-dev | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBrgrejbOsMZSA25cRAtChAJwJeJxEedCs95jKOIjZJgbagBJwuQCaAr8I ojHeJazyDzDhlKczOnR20QI= =bccA -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
slimboyfatboyslim http://www.slimboyfatboyslim.org
hello,
On Feb 18, 2005, at 7:18 AM, slimboyfatboyslim wrote:
hi,
After I've got the latest Gem.pd_darwin and working with multiple windows, it works perfectly but I've found that I can't play movie with pix_film and I can't create pix_movie, I've got the latest version complied on 31, Jan. Below is what I get in console,
....
hints: border = 1 hints: display = (null) hints: title = GEM hints: shared = 0 hints: fsaa = 0 GEM: Start rendering error: GEM: pix_movie: Couldn't open the movie file: mix8.movT (-2020) GEM: pix_film: Loaded file: /Users/slimboyfatboyslim/project/Gotland/mix8.mov with 0 frames (0x0)
...hmm, this looks like it's trying to tell us that it can't load the movie due to there not being a context for it...unfortunately won't be able to look at it until tommorrow :-(
...otoh, please remember that the multiple_window branch is more a proof of concept atm: fr'instance, I won't be using it to play live tonight :-) But it'll get there...
l8r, jamie
hi James,
Don't worry, I'm not in a hurry, I'm now using the old Gem.pd_darwin. It works fine.
Just let you know the bugs.
Cheers, A On 18 Feb 05, at 3:22 PM, james tittle wrote:
hello,
On Feb 18, 2005, at 7:18 AM, slimboyfatboyslim wrote:
hi,
After I've got the latest Gem.pd_darwin and working with multiple windows, it works perfectly but I've found that I can't play movie with pix_film and I can't create pix_movie, I've got the latest version complied on 31, Jan. Below is what I get in console,
....
hints: border = 1 hints: display = (null) hints: title = GEM hints: shared = 0 hints: fsaa = 0 GEM: Start rendering error: GEM: pix_movie: Couldn't open the movie file: mix8.movT (-2020) GEM: pix_film: Loaded file: /Users/slimboyfatboyslim/project/Gotland/mix8.mov with 0 frames (0x0)
...hmm, this looks like it's trying to tell us that it can't load the movie due to there not being a context for it...unfortunately won't be able to look at it until tommorrow :-(
...otoh, please remember that the multiple_window branch is more a proof of concept atm: fr'instance, I won't be using it to play live tonight :-) But it'll get there...
l8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
slimboyfatboyslim http://www.slimboyfatboyslim.org
...guess I'm trying to finish up old threads for the year ;-)
On Feb 18, 2005, at 7:18 AM, slimboyfatboyslim wrote:
After I've got the latest Gem.pd_darwin and working with multiple windows, it works perfectly but I've found that I can't play movie with pix_film and I can't create pix_movie, I've got the latest version complied on 31, Jan.
...hard to believe it's been sooo long since I worked on this, but it has been a busy/distracting year! Anyway, just wanted to drop a note that movies/films are now working: it was a really stupid overlook/ mistake in separating the gemman code into gemcontrol & gemwindow (quicktime wasn't getting initialized!) 8^P I wonder/assume that pix_movie/pix_film were working fine beforehand in the linux multiple_window, IOhannes?
...no release atm, because I'm still trying to port current cvs head fixes n'changes back to the multiple_window branch, but as soon as that's done, then we can do some more group testing...
l8r, jamie
-
B. Bogart -
IOhannes m zmoelnig -
james tittle -
peter plessas -
slimboyfatboyslim