hey,
...well, I've got gemmouse working osx, finally! However, I noticed that there's no support for mouse wheel input, so I've added that, but have a small problem: there are too many outlets for this object! As it is now, the outlets are x and y location, and then 3 seperate outlets for the buttons...seems like this is a bit excessive for the buttons: why not just have one outlet send a 0,1,or 2, based on the button press? Then we could have an outlet for wheel axis and value...
any thoughts? jamie
tigital@mac.com wrote:
hey,
...well, I've got gemmouse working osx, finally! However, I noticed that there's no support for mouse wheel input, so I've added that, but have a small problem: there are too many outlets for this object! As it is now, the outlets are x and y location, and then 3 seperate outlets for the buttons...seems like this is a bit excessive for the buttons: why not just have one outlet send a 0,1,or 2, based on the button press? Then we could have an outlet for wheel axis and value...
any thoughts?
hi great you got it running.
i think you are absolutely right, but: [gemmouse] has been around quite a long time (i guess, pre 0.80 !). changing the object would probably break a lot of patches that rely on it. probably the simplest method would be another(!) object, like [gem_mouse] (or similar), and mark the old [gemmouse] as deprecated. i would like the new behaviour to output normalized coordinates too. (probably normalizing in only one direction)
but before such new object (of course, all names but "gemmouse" will be clumsy) might come into being we should consider how to make a solid interface to multiple render-windows (this has been on my todo-list a long time)
any thoughts?
mfg.as.dr IOhannes
Hey all,
How about making a new object (with the new functionality) as Johannes suggests, but rather than including the old version, include an abstraction which mimics the old behavior. Mark the abstraction as depreciated and then discontinue it's distribution.
I'm very happy about the prospect of multiple render windows, perhaps even one GL window for interface and the other for output.. (or previews, you name it)
Jamie, thanks for the work with the tcl.tk8.5 is certainly huge steps ahead! There are a couple issues though, lots of render errors (improperly renders objects), and the performance is certainly better, but the 1.25Ghz machine still moves GOPS more slowly than windows on the 800Mhz. (Its about the same on linux.) I'm sure this would be better if I left in the priority hack, but that make PD close to useless!
Also I'm getting segfaults in OSX with pd/gem I'll send a crashlog once I accumulate one. Anyone have a shortcut so that I can always run pd (with flags) in gdb from a script/alias? rather than:
gdb pd run [pasted lots of stuff]
Thanks!
Ben
tigital@mac.com wrote:
hey,
...well, I've got gemmouse working osx, finally! However, I noticed that there's no support for mouse wheel input, so I've added that, but have a small problem: there are too many outlets for this object! As it is now, the outlets are x and y location, and then 3 seperate outlets for the buttons...seems like this is a bit excessive for the buttons: why not just have one outlet send a 0,1,or 2, based on the button press? Then we could have an outlet for wheel axis and value...
any thoughts?
hi great you got it running.
i think you are absolutely right, but: [gemmouse] has been around quite a long time (i guess, pre 0.80 !). changing the object would probably break a lot of patches that rely on it. probably the simplest method would be another(!) object, like [gem_mouse] (or similar), and mark the old [gemmouse] as deprecated. i would like the new behaviour to output normalized coordinates too. (probably normalizing in only one direction)
but before such new object (of course, all names but "gemmouse" will be clumsy) might come into being we should consider how to make a solid interface to multiple render-windows (this has been on my todo-list a long time)
any thoughts?
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Mon, 19 Jan 2004 ben@ekran.org wrote:
How about making a new object (with the new functionality) as Johannes suggests, but rather than including the old version, include an abstraction which mimics the old behavior. Mark the abstraction as depreciated and then discontinue it's distribution.
In GridFlow, [@out x11] can emit those messages:
{position <y> <x> <buttons>}
where buttons is a OR of the following:
256 = left button 512 = middle button / side button / wheel press 1024 = right button 2048 = wheel up 4096 = wheel down and the keyboard modifiers (shift,ctrl,alt,etc)... as X11 does it.
So I use [route position] and then extract list values as needed.
[@out x11] also emits {keypress <keyname>}, {keyrelease <keyname>}, and {bang} ("frame completed") messages. All of this is done with a single outlet. What's neat is that it is extensible with other event information.
How do you like it?
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hey ben,
On Monday, January 19, 2004, at 09:39 AM, ben@ekran.org wrote:
Hey all,
How about making a new object (with the new functionality) as Johannes suggests, but rather than including the old version, include an abstraction which mimics the old behavior. Mark the abstraction as depreciated and then discontinue it's distribution.
...I think this is a great idea, because it's the best of both worlds: I could make the new object gem_mouse, and the abstraction will be gemmouse...
I'm very happy about the prospect of multiple render windows, perhaps even one GL window for interface and the other for output.. (or previews, you name it)
...It's not clear atm how we would do this on osx...at any rate, I don't think this is something we should talk about until after the current release "attempt" ;-) I've got way too much on my plate in the short term, and am barely getting time to finish up the gem_mouse and gemkeyboard...
Jamie, thanks for the work with the tcl.tk8.5 is certainly huge steps ahead! There are a couple issues though, lots of render errors (improperly renders objects), and the performance is certainly better, but the 1.25Ghz machine still moves GOPS more slowly than windows on the 800Mhz. (Its about the same on linux.) I'm sure this would be better if I left in the priority hack, but that make PD close to useless!
...hmmm, I haven't been able to try out your "render objects" errors: I doubt that's coming from tcl/tk, tho...the GOP slowness is definitely a bother, but also definitely related to XCopyArea(), which has not been converted/updated to CG, and is the MAJOR bottleneck in tk drawing, at least atm...fixing that is next on my agenda after the current gem/pd stuff I'm doing, so hold on...
Also I'm getting segfaults in OSX with pd/gem I'll send a crashlog once I accumulate one. Anyone have a shortcut so that I can always run pd (with flags) in gdb from a script/alias? rather than:
...sorry, I've just been using project builder...disturbing about what you've found with some crash between pd and gem...we should check that out closely...
l8r, jamie
-
ben＠ekran.org -
IOhannes zmoelnig -
Mathieu Bouchard -
tigital＠mac.com