On Thu, Sep 4, 2008 at 1:13 AM, simone-www. io-lab. org <[EMAIL PROTECTED]> wrote: > On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer <[EMAIL PROTECTED]> 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 > >> >> 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.... _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
