[PD] Setting a variable in abstractions
cimo75 at gmail.com
Sun Sep 7 11:22:54 CEST 2008
On Fri, Sep 5, 2008 at 12:05 AM, simone-www. io-lab. org
<cimo75 at gmail.com> wrote:
> On Thu, Sep 4, 2008 at 1:13 AM, simone-www. io-lab. org
> <cimo75 at gmail.com> wrote:
>> On Thu, Sep 4, 2008 at 12:31 AM, Derek Holzer <derek at 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..
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.
>>> simone-www.io-lab.org wrote:
>>>> 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....
.wmv , .wma , .pps along with all proprietary Windows formats won t be
accepted and/or viewed....
More information about the Pd-list