[PD] Setting a variable in abstractions

[simone-www.io-lab.org]

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..
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....