Hi
So I'm having fun playing around with gem. I can already see myself using it live soon. However I can't figure out how to start gem rendering in fullscreen without showing any gui, including gem window border/title bar and mouse.
The closest I can get is by sending [dimen 1024 768( to [gemwin] before creation and starting pd with -nogui. Unfortunately this still shows the title bar of the window, the mouse and my panel at the bottom of the screen. This of course looks stupid in a performance...
An ackward solution could be to create a user in whos .xsession the only thing happening is starting pd with -nogui, but I didn't try that yet since it's ackward and might not even work...
I'm running debian/linux with openbox and xfce4-panel. Pd and gem are compiled from source and are versions 0.40.3 and 0.90.
On Mon, 2007-10-15 at 22:09 +0200, Atte André Jensen wrote:
Hi
So I'm having fun playing around with gem. I can already see myself using it live soon. However I can't figure out how to start gem rendering in fullscreen without showing any gui, including gem window border/title bar and mouse.
The closest I can get is by sending [dimen 1024 768( to [gemwin] before creation and starting pd with -nogui. Unfortunately this still shows the title bar of the window, the mouse and my panel at the bottom of the screen. This of course looks stupid in a performance...
An ackward solution could be to create a user in whos .xsession the only thing happening is starting pd with -nogui, but I didn't try that yet since it's ackward and might not even work...
I'm running debian/linux with openbox and xfce4-panel. Pd and gem are compiled from source and are versions 0.40.3 and 0.90.
have a look at the helpfile of [gemwin].
messages, you probably want to send to [gemwin]:
'fullscreen 1' 'cursor 0'
don't they work for you?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
have a look at the helpfile of [gemwin].
Hmmm. I tried that (of cource) but I was expecting to be able to right click athe [genwin] object and select "help". This gave me a "sorry, couldn't find help patch for "Gem/gemwin.pd". I searced my system for a file called "gemwin-help.pd, since I though it was supposed to be called that and didn't find any, which led me to believe that there were no help files available.
Apparently they are located in .../help/ and thisone is simply called "gemwin.pd". What did I do wrong since the right-click/help way doesn't work?
Anyways, thanks for pointing me in the direction of gemwin.pd, now I can dig in, although so far in a rather cumbersome fashion...
Roman Haefeli wrote:
messages, you probably want to send to [gemwin]:
'fullscreen 1' 'cursor 0'
don't they work for you?
Well I not having looked at the helpfile I send [fullscreen( (without the 1) and obviously that didn't work. Those two messages do exactly what I need, thanks!
However now I need to log into a tty with something like ctrl-alt-F1 and do a "killall pd". Isn't there a cleaner way?
Le lundi 15 octobre 2007 à 23:13 +0200, Atte André Jensen a écrit :
Roman Haefeli wrote:
messages, you probably want to send to [gemwin]:
'fullscreen 1' 'cursor 0'
don't they work for you?
Well I not having looked at the helpfile I send [fullscreen( (without the 1) and obviously that didn't work. Those two messages do exactly what I need, thanks!
However now I need to log into a tty with something like ctrl-alt-F1 and do a "killall pd". Isn't there a cleaner way?
Hi Atte,
Quick and dirty: If your desktop is Gnome, Alt+Tab gives you the possibility to switch to any other window eg. your patch hidden behind the gemwin.
On the Pd side, you have the possibility to add a [gemkeyboard] object that sends a [destroy( message to [gemwin]. You need to map the object's output with the deisred keycode. For instance, pressing the Esc key gives the "9" keycode on my Linux box.
I think it is also worthwhile giving a try to the Pdmtl abstractions collections, the gems.* abstractions are quite helpful, especially gems.win in your case.
see http://wiki.dataflow.ws/PdMtlAbstractions
Bye
O.
Olivier Heinry wrote:
If your desktop is Gnome, Alt+Tab gives you the possibility to switch to any other window eg. your patch hidden behind the gemwin.
I use openbox, and normally Alt+Tab works like you describe, but for some reason not with gem...
On the Pd side, you have the possibility to add a [gemkeyboard] object that sends a [destroy( message to [gemwin]. You need to map the object's output with the deisred keycode. For instance, pressing the Esc key gives the "9" keycode on my Linux box.
That only works when not running in fullscreen :-(
On Tue, 2007-10-16 at 03:00 +0200, Atte André Jensen wrote:
Olivier Heinry wrote:
If your desktop is Gnome, Alt+Tab gives you the possibility to switch to any other window eg. your patch hidden behind the gemwin.
I use openbox, and normally Alt+Tab works like you describe, but for some reason not with gem...
On the Pd side, you have the possibility to add a [gemkeyboard] object that sends a [destroy( message to [gemwin]. You need to map the object's output with the deisred keycode. For instance, pressing the Esc key gives the "9" keycode on my Linux box.
That only works when not running in fullscreen :-(
don't know why exactly this is so, it is the same here: when in fullscreen, [gemkeyboard] seems to not work.. i usually use both [gemkeyboard] and [key] to destroy the gemwin..
at least on my keyboard this works for destroying in any situation by typing [esc]:
[gemkeyboard] [key] | | [sel 9] [sel 27]
hope that helps and you don't need to kill gem from shell anymore. ;-)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 16 Oct 2007, at 11:21 AM, Roman Haefeli wrote:
On Tue, 2007-10-16 at 03:00 +0200, Atte André Jensen wrote:
Olivier Heinry wrote:
If your desktop is Gnome, Alt+Tab gives you the possibility to
switch to any other window eg. your patch hidden behind the gemwin.I use openbox, and normally Alt+Tab works like you describe, but for some reason not with gem...
On the Pd side, you have the possibility to add a [gemkeyboard]
object that sends a [destroy( message to [gemwin]. You need to map the
object's output with the deisred keycode. For instance, pressing the Esc key gives the "9" keycode on my Linux box.That only works when not running in fullscreen :-(
you could try using [hid] or [hidio] instead - to capture the (USB)
keyboard directly, regardless of which process has focus at the time
simon
Roman Haefeli wrote:
On Tue, 2007-10-16 at 03:00 +0200, Atte André Jensen wrote:
That only works when not running in fullscreen :-(
don't know why exactly this is so, it is the same here: when in fullscreen, [gemkeyboard] seems to not work..
i am not sure either :-) basically it is, because in fullscreen mode, Gem will draw to the root-window, which is special in X.
otoh, depending on your window-manager you might well be able to access the keyboard-events in ghe gemwin (though i haven't had success (but i haven't tried that hard either))
finally, for getting out of the fullscreen mode (on single head machines) i usually use [gemmouse] and some combination of a hot-area and the right-mouseclick instead of the keyboard.
and most of my gfx-cards nowadays are dual-headed, so i usually have the gemwin in "fullscreen" (well, practically it is a gemwin with [border 0, offset 1024 0, dimen 1024 767( or the like) on one screen and run the patch (including a [destroy() on the other screen...
gmfas.dr IOhannes
Hallo, Olivier Heinry hat gesagt: // Olivier Heinry wrote:
On the Pd side, you have the possibility to add a [gemkeyboard] object that sends a [destroy( message to [gemwin].
And depending on how old your Gem is, make sure to put a [delay] or [pipe] between gemkeyboard's output and the destroy message to not destroy Pd.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Olivier Heinry hat gesagt: // Olivier Heinry wrote:
On the Pd side, you have the possibility to add a [gemkeyboard] object that sends a [destroy( message to [gemwin].
And depending on how old your Gem is, make sure to put a [delay] or [pipe] between gemkeyboard's output and the destroy message to not destroy Pd.
to clarify: older versions of Gem did crash when you had no delay between the windowevent and the destruction of the window (similar to triggering the destruction of a subpatch from itself).
newer versions of Gem somehow workaround this.
fgmasd.r IOhannes
IOhannes m zmoelnig wrote:
to clarify: older versions of Gem did crash when you had no delay between the windowevent and the destruction of the window (similar to triggering the destruction of a subpatch from itself).
I have this crash and my gem i 0.90, is there anything newer available for linux and if so where? I wasn't ablt to locate it on the website...
Atte André Jensen wrote:
IOhannes m zmoelnig wrote:
to clarify: older versions of Gem did crash when you had no delay between the windowevent and the destruction of the window (similar to triggering the destruction of a subpatch from itself).
I have this crash and my gem i 0.90, is there anything newer available for linux and if so where? I wasn't ablt to locate it on the website...
we don't provide linux binaries because of dependency issues. (chances are low that my binary will work on your machine)
just get the sources from cvs and compile. % cvs -z9 -d:pserver:anonymous@cvs.gem.iem.at:/cvsroot/pd-gem login % cvs -z9 -d:pserver:anonymous@cvs.gem.iem.at:/cvsroot/pd-gem co -P Gem % cd Gem/src % make
it should be quite easy :-)
fmasd.r IOhannes
On Tue, 16 Oct 2007, IOhannes m zmoelnig wrote:
we don't provide linux binaries because of dependency issues. (chances are low that my binary will work on your machine)
This is something that gets fixed using static linking, no? But perhaps making correct static linking while building a shared library is not so easy, compared to making a standalone app.
A few years ago, I had written this line, in order to compile with libruby.a and still produce a .so :
lib = "-Wl,--whole-archive"+lib+"-Wl,--no-whole-archive" unless OSX
You give those options to GCC, but the "-Wl," means "delegate the following option directly to LD"
Have you ever tried that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
On Tue, 16 Oct 2007, IOhannes m zmoelnig wrote:
we don't provide linux binaries because of dependency issues. (chances are low that my binary will work on your machine)
This is something that gets fixed using static linking, no? But perhaps making correct static linking while building a shared library is not so easy, compared to making a standalone app.
A few years ago, I had written this line, in order to compile with libruby.a and still produce a .so :
lib = "-Wl,--whole-archive"+lib+"-Wl,--no-whole-archive" unless OSX
You give those options to GCC, but the "-Wl," means "delegate the following option directly to LD"
Have you ever tried that?
no i haven't. but here Gem depends on 61 libraries (including the most standard stuff), i guess the resulting lib will get quite big...
fmadsr. IOhannes
Mathieu Bouchard wrote:
On Tue, 16 Oct 2007, IOhannes m zmoelnig wrote:
we don't provide linux binaries because of dependency issues. (chances are low that my binary will work on your machine)
This is something that gets fixed using static linking, no? But perhaps making correct static linking while building a shared library is not so easy, compared to making a standalone app.
A few years ago, I had written this line, in order to compile with libruby.a and still produce a .so :
lib = "-Wl,--whole-archive"+lib+"-Wl,--no-whole-archive" unless OSX
this should look like "-Wl,--whole-archive -lmpeg3 -ljpeg -ltiff -Wl,--no-whole-archive" instead of "-lmpeg3 -ljpeg -ltiff". correct?
if so, it doesn't do anything meaningful here...
mfg.asrd IOhannes
You give those options to GCC, but the "-Wl," means "delegate the following option directly to LD"
Have you ever tried that?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
IOhannes m zmoelnig wrote:
to clarify: older versions of Gem did crash when you had no delay between the windowevent and the destruction of the window (similar to triggering the destruction of a subpatch from itself).
I have this crash and my gem i 0.90, is there anything newer available for linux and if so where? I wasn't ablt to locate it on the website...
I think you need to use the CVS version. But I'd just use a [delay]
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Atte André Jensen hat gesagt: // Atte André Jensen wrote:
However now I need to log into a tty with something like ctrl-alt-F1 and do a "killall pd". Isn't there a cleaner way?
Normally you should be able to Alt-TAB over to Pd, but I think, something in the combination of openbox and gem-fullscreen may break here. I have a similar issue with the newest Blackbox, but it worked with older Blackboxes and other WMs.
Ciao
Frank Barknecht _ ______footils.org__
-
Atte André Jensen -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard -
Olivier Heinry -
Roman Haefeli -
simon wise