Hello,
under heavy (but reasonable) load of audio computation in Pd 0.31 (Win95 box with Prodif+ audio and MusicQuest midi) any burst of midi input data incoming in a short period of time causes a total and nonreversable deafness of all midi objects.
This effect occurs even without any ``real'' midi events -- it is simply sufficient to connect a device sending active sensing stream. But it is possible to play separate notes with no harm, no matter how many notes as long as in a slow tempo.
Is this a well known phenomenon or just my bad luck?
Any chance there is a way of performing a midi driver reset other than restarting Pd?
Thank you,
Krzysztof Czaja
hello Krzysztof,
Your problem with MIDI is not known in general. Does anyone have the possiblity to try this out on a Windows system ?
It may be a problem with your system, or if others have this on Windows it could be a problem with pd too ...
Guenter
Krzysztof Czaja writes:
Hello,
under heavy (but reasonable) load of audio computation in Pd 0.31 (Win95 box with Prodif+ audio and MusicQuest midi) any burst of midi input data incoming in a short period of time causes a total and nonreversable deafness of all midi objects.
This effect occurs even without any ``real'' midi events -- it is simply sufficient to connect a device sending active sensing stream. But it is possible to play separate notes with no harm, no matter how many notes as long as in a slow tempo.
Is this a well known phenomenon or just my bad luck?
Any chance there is a way of performing a midi driver reset other than restarting Pd?
Thank you,
Krzysztof Czaja
Hello again,
I investigated this a little further and found that
There is no need to even turn dsp on. Midi gets stuck, for example, if there is some printout comming from Pd simultaneously with `too fast' midi input. The very simple test patch is included as an attachment.
The same machine under Linux/OSS runs the same test patch perfectly. I can not check midi with audio under Linux since OSS does not support Prodif+ card.
Given all that I assume it is windows midi driver to blame but I would have been more certain if this machine had given me any midi problems in Cubase, which it never had.
- After digging in the sources I found a very useful `pd audio'
message. It performs exactly the midi reset action I queried for in my previous post, so I included this message in the test patch. It is applicable only in windows (i.e. where it is really needed :).
Thank you very much for your patience.
Krzysztof
Guenter Geiger wrote:
hello Krzysztof,
Your problem with MIDI is not known in general. Does anyone have the possiblity to try this out on a Windows system ?
It may be a problem with your system, or if others have this on Windows it could be a problem with pd too ...
Guenter
#N canvas 348 303 536 467 12; #X obj 293 242 metro 1000; #X obj 82 196 notein; #X obj 82 330 print note; #X obj 82 242 spigot; #X obj 293 286 print metro; #X msg 31 389 ; pd dsp 0 ; pd audio 0 2; #X obj 82 286 spigot; #X msg 293 196 0; #X msg 337 196 1; #X obj 227 242 == 0; #X msg 265 399 ---------------------------------; #X obj 265 430 print reset; #X floatatom 19 286; #X msg 174 196 stop; #X msg 174 242 0; #X obj 174 112 r printout; #X msg 205 39 ; printout none; #X msg 364 20 ; printout note; #X obj 174 152 route none note metro; #X obj 387 196 t b 0; #X obj 230 330 r reset; #X obj 170 418 del 100; #X obj 230 361 t 0 b; #X msg 39 39 ; reset 50; #X msg 364 67 ; printout metro 50; #X connect 0 0 4 0; #X connect 1 0 3 0; #X connect 1 1 3 1; #X connect 3 0 6 0; #X connect 3 0 12 0; #X connect 6 0 2 0; #X connect 7 0 0 0; #X connect 7 0 9 0; #X connect 8 0 0 0; #X connect 8 0 9 0; #X connect 9 0 6 1; #X connect 10 0 11 0; #X connect 13 0 0 0; #X connect 13 0 14 0; #X connect 14 0 6 1; #X connect 15 0 18 0; #X connect 18 0 13 0; #X connect 18 1 7 0; #X connect 18 2 19 0; #X connect 19 0 8 0; #X connect 19 1 0 1; #X connect 20 0 22 0; #X connect 21 0 5 0; #X connect 22 0 21 0; #X connect 22 1 10 0;
-
Guenter Geiger -
Krzysztof Czaja