On Fri, Sep 5, 2008 at 12:05 AM, simone-www. io-lab. org cimo75@gmail.com wrote:
On Thu, Sep 4, 2008 at 1:13 AM, simone-www. io-lab. org cimo75@gmail.com wrote:
On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer derek@umatic.nl wrote:
Hey Simone,
the only thing I see in the patch is that you should remove the number box inline in the "MIDI to DEGREES" section. Inline GUI elements can slow down a patch, especially when visible. Also, do you really want the CC input to change the size of the font in the [text2d], because that's what it does now ;-)
no it sends a 7bit value to be displayed, the font size is the second inlet
Besides that, you may want to have a look at your system config. Linux, right? In that case, you should make sure that OpenGL is configured properly, and that you have 3d acceleration enabled, otherwise all the GEM stuff will be done by the CPU which could also slow things down a little or a lot. There's plenty of docs online for whatever distro you are using...
ah! since i got dual head installed i had to say good bye to Compiz and friends, and that maybe means no OpenGL.This is due to xinerama not supporting it, probably i ll have to use xrandr with a virtual desktop size on xorg.conf cause life without dual head can be pretty miserable ;) Yet i don understand why this happens only with midi in and not in other situations.. btw i can t find proper infos about how to offset gemwin on a second screen or to have it not showing bars and window frame Tech specs: Dell D410 1,73Ghz 1,25 Mb Fedora Core 8 + CCRMA rt kernel microkontol KORG
here we go, this issue with OpenGL has finally pushed me to trash my old Cinerama xorg.conf and go for the newest Xrandr which is just awesome and i have OpenGL on both screens and the patch loads on my external screen and it runs much more smoothly and nicely!! thumbs up !! yet: the response from the MIDI input is not as fast as as i imagined: what does it make it go so slow? Rotating images shouldn t be such a big deal and since i plan to embed this application on a small miniATX computer or similar i wonder what can be done to address this timing issue.. Simone
The issue seems to be gone although it came back once again so i am trying to figure out what slows down the patch.I ll post as soon as i manage to address it. I would like to thank everybody for the support, i am really freaking out with the amazing possibilities such an application can offer.
Also, try not to run GEM stuff in the same PD patch as audio stuff (I mentioned this during the workshop). Running separate instances of PD, one for audio and one for GEM, connected with [netsend] objects or OSC, should do the trick.
best! d.
simone-www.io-lab.org wrote:
hi I hope it s fine with top posting but the issue now is drifting off-topic: the patch works as a charm now, thanks again, but (there is always a but) somehow the incoming MIDI messages are slowed down. I tried to monitor the MIDI in and can see how when i turn the rendering on all the MIDI income gets slowed down terribly. Is there any known issue with GEM and MIDI or anything i have to check on my machine? GEM+sending messages from within PD worked flawlessly, CPU is not hogged, jack runs smoothly. I am attaching the patch but without the font file generating the 7bit midi value
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 49: "Display your talent"
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....
-- .wmv , .wma , .pps along with all proprietary Windows formats won t be accepted and/or viewed....