[GEM-dev] Re: multiple_window: the questions begin!

Fri Feb 18 13:18:20 CET 2005

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 at 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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>
>
slimboyfatboyslim
http://www.slimboyfatboyslim.org