Hi Max

It seems that the GUI should slow down long before the MIDI does - or
at least that's what happens to me - so it sounds like a MIDI problem
and not a cpu load thing.

This may be a dumb question, but is there any chance the MIDI
signal's looping back to PD's MIDI in? I only ask because I've
managed to do it myself with similar results...

cheers dafydd

On 13-Nov-05, at 8:18 PM, Max Neupert wrote:

i would prefer to still have the gui as i can't set everything via
midi. what's slow is just the midi input, but i can still set the values
with a slider with more instant effect. is there anything which affects just the midi input to be delayed? any other explanations to this phenomenon?

max

Am 13.11.2005 um 22:39 schrieb B. Bogart:

...

Hi,

try -nogui, or maybe your patch is too much for your machine...

Whats the CPU load without doing the MIDI stuff?

b.

Max Neupert wrote:

...

hi list,

i've used a midi mixer lately in a performance to control some Gem stuff with the faders. Pd seemed to be completely busy handling Gem patch so the midi input got delayed for more than 2 sec. how may I avoid this delay?

max

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Hi roman, list,

i was aware of the audio/video problem as this workaround is
frequently suggested on the list to run 2 instances of pd and
communicate with OSC. But in my case it's even a problem without any
audio, just gem and midi input. that was new to me. i will try to
receive the midi in another instance and send the control via OSC.
maybe this workaround will help also in this case. if i succed i will
post the results.

max

Am 14.11.2005 um 12:46 schrieb Roman Haefeli:

hi

i had once a similar problem with gem and audio. the rendering of the gemwin took so much cpu-time, that the dsp was interrupted all the
time. i solved it by running two instances of pd, one for gem and one for
the dsp. the disadvantage of such a setup is, that audio and graphik is
not synced anymore.

roman

"Max Neupert" abonnements@revolwear.com wrote:

...

hi list,

i've used a midi mixer lately in a performance to control some Gem stuff with the faders. Pd seemed to be completely busy handling Gem patch so the midi input got delayed for more than 2 sec. how may I avoid this delay?

max

___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de

I recall this problem from a few years ago, and that running Pd with elevated priority made this worse. FWIW, I found MIDI nearly worthless as a 3D controller due to the 7 bit resolution. Scaling 0..127 to rotation, translation or film scrubbing was not nearly enough to offer decent control.

On 11/14/05, Georg Holzmann grhPD@gmx.at wrote:

anyway, the hack to run 2 instances of PD is only to avoid audio dropouts, because Gem is not threaded (yet)

It's probably not going to be threaded very much either since calling GL without a ton of sync glue code gets really ugly. On OSX, Quicktime really likes to run in the same thread, although many of the codecs, compressors and video capture components spawn additional threads.

... so it would only be a hack and no solution to the problem ...

Lucky for you I have extended this hack to allow sharing of pix_ chains between pd processes.

Am 14.11.2005 um 20:39 schrieb Georg Holzmann:

wich cpu load to you have in your patch ? maybe it's simply to heavy ?

yeah. you are right. it's way to heavy. it's actually not my patch,
but maybe someone has got an idea why it's so heavy on the cpu.

thanks.