Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ángel Faraldo
www.angelfaraldo.info
Hi Ãngel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem you found is something different (because at least there the values settle correctly when the sliders stop moving while for you it seems like something is ending up in the wrong state).
Anyway, with apologies I have to say I'm delighted you can get this to happen on a Mac - if indeed it's the same problem as on the PC it means it's in teh Pd code and so if I can ever get it to happen here I can probably fix it :)
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ãngel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ãngel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ángel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem you found is something different (because at least there the values settle correctly when the sliders stop moving while for you it seems like something is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this to happen on a Mac - if indeed it's the same problem as on the PC it means it's in teh Pd code and so if I can ever get it to happen here I can probably fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ángel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ángel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ãngel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ãngel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem you found is something different (because at least there the values settle correctly when the sliders stop moving while for you it seems like something is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this to happen on a Mac - if indeed it's the same problem as on the PC it means it's in teh Pd code and so if I can ever get it to happen here I can probably fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ãngel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ãngel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ãngel Faraldo _________________ www.angelfaraldo.info
Yep.. I already responded to the other thread but will mention it here too just to be thorough... I think I've got this fixed - it's up on the usual http://crca.ucsd.edu/~msp/software.html ... .43-3 test1.
cheers Miller
On Sat, Jun 16, 2012 at 01:20:05PM -0700, Miller Puckette wrote:
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ãngel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ãngel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem you found is something different (because at least there the values settle correctly when the sliders stop moving while for you it seems like something is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this to happen on a Mac - if indeed it's the same problem as on the PC it means it's in teh Pd code and so if I can ever get it to happen here I can probably fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ãngel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ãngel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ãngel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller
Out of curiosity, what was the fix?
On Sat, Jun 23, 2012 at 8:29 PM, Miller Puckette msp@ucsd.edu wrote:
Yep.. I already responded to the other thread but will mention it here too just to be thorough... I think I've got this fixed - it's up on the usual http://crca.ucsd.edu/~msp/software.html ... .43-3 test1.
cheers Miller
On Sat, Jun 16, 2012 at 01:20:05PM -0700, Miller Puckette wrote:
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ángel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ángel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem
you
found is something different (because at least there the values
settle
correctly when the sliders stop moving while for you it seems like
something
is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this
to
happen on a Mac - if indeed it's the same problem as on the PC it
means
it's in teh Pd code and so if I can ever get it to happen here I can
probably
fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ángel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a
few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with ctlin), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum,
that is, from 0 to 127, the values in the number boxes connected to ctlin end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac),
I can see that the computer receives all the midi values as expected, so I guess that something happens on the ctlin level in Pd.
Apparently this is/was also an issue on Max's implementation of
I have worked with other Midi controllers in Pd and I never had a
similar problem.
i've also tried [midiin]->[midiparse], with exactly the same
results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ángel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Dull. The midi polling code (run once a tick) was happily giving up after handling one incoming MID message per device - so as soon as there were more than about 700 messages per second they piled up in teh driver and eventually started getting dropped.
I put in a throttle of 100 messages per device per tick, just to keep incoming MIDI from bringting the rest of Pd totally to a halt.
cheers Miller On Sun, Jun 24, 2012 at 12:18:24AM -0400, chris clepper wrote:
Miller
Out of curiosity, what was the fix?
On Sat, Jun 23, 2012 at 8:29 PM, Miller Puckette msp@ucsd.edu wrote:
Yep.. I already responded to the other thread but will mention it here too just to be thorough... I think I've got this fixed - it's up on the usual http://crca.ucsd.edu/~msp/software.html ... .43-3 test1.
cheers Miller
On Sat, Jun 16, 2012 at 01:20:05PM -0700, Miller Puckette wrote:
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ãngel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ãngel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem
you
found is something different (because at least there the values
settle
correctly when the sliders stop moving while for you it seems like
something
is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this
to
happen on a Mac - if indeed it's the same problem as on the PC it
means
it's in teh Pd code and so if I can ever get it to happen here I can
probably
fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ãngel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a
few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with ctlin), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum,
that is, from 0 to 127, the values in the number boxes connected to ctlin end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac),
I can see that the computer receives all the midi values as expected, so I guess that something happens on the ctlin level in Pd.
Apparently this is/was also an issue on Max's implementation of
I have worked with other Midi controllers in Pd and I never had a
similar problem.
i've also tried [midiin]->[midiparse], with exactly the same
results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ãngel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Ãngel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Does this affect the 0.42 branch as well? If so, would you mind sharing the relevant patch or svn commit?
Many thanks!
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Miller Puckette msp@ucsd.edu wrote:
Dull. The midi polling code (run once a tick) was happily giving up after handling one incoming MID message per device - so as soon as there were more than about 700 messages per second they piled up in teh driver and eventually started getting dropped.
I put in a throttle of 100 messages per device per tick, just to keep incoming MIDI from bringting the rest of Pd totally to a halt.
cheers Miller On Sun, Jun 24, 2012 at 12:18:24AM -0400, chris clepper wrote:
Miller
Out of curiosity, what was the fix?
On Sat, Jun 23, 2012 at 8:29 PM, Miller Puckette msp@ucsd.edu wrote:
Yep.. I already responded to the other thread but will mention it here too just to be thorough... I think I've got this fixed - it's up on the usual http://crca.ucsd.edu/~msp/software.html ... .43-3 test1.
cheers Miller
On Sat, Jun 16, 2012 at 01:20:05PM -0700, Miller Puckette wrote:
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ángel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ángel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem
you
found is something different (because at least there the values
settle
correctly when the sliders stop moving while for you it seems like
something
is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this
to
happen on a Mac - if indeed it's the same problem as on the PC it
means
it's in teh Pd code and so if I can ever get it to happen here I can
probably
fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ángel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a
few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with ctlin), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum,
that is, from 0 to 127, the values in the number boxes connected to ctlin end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac),
I can see that the computer receives all the midi values as expected, so I guess that something happens on the ctlin level in Pd.
Apparently this is/was also an issue on Max's implementation of
I have worked with other Midi controllers in Pd and I never had a
similar problem.
i've also tried [midiin]->[midiparse], with exactly the same
results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ángel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Here's the relevant diff - should apply OK to 0.42 I think.
cheers Miller
diff --git a/src/s_midi_pm.c b/src/s_midi_pm.c index fe123ff..856f121 100644 --- a/src/s_midi_pm.c +++ b/src/s_midi_pm.c @@ -241,44 +241,51 @@ void nd_sysex_inword(int midiindev, int status, int data1, int data2, int data3)
void sys_poll_midi(void) {
int nmess = Pm_Read(mac_midiindevlist[i], &buffer, 1);
if (nmess > 0)
while (1)
{
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message >> 24) & 0xFF);
int msgtype = (status >> 4) - 8;
switch (msgtype)
if (!throttle--)
goto overload;
nmess = Pm_Read(mac_midiindevlist[i], &buffer, 1);
if (nmess > 0)
{
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1;
nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message >> 24) & 0xFF);
int msgtype = (status >> 4) - 8;
switch (msgtype)
{
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1;
nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
nd_sysex_inword(i, status, data1, data2, data3);
}
}
else break;
}
}}
On Sun, Jun 24, 2012 at 10:23:52AM -0400, Ivica Ico Bukvic wrote:
Does this affect the 0.42 branch as well? If so, would you mind sharing the relevant patch or svn commit?
Many thanks!
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Cool! Thanks!
-----Original Message----- From: Miller Puckette [mailto:msp@ucsd.edu] Sent: Sunday, June 24, 2012 1:36 PM To: Ivica Ico Bukvic Cc: chris clepper; pd-list Subject: Re: [PD] nanoKontrol2 dropping MIDI messages (OSX)
Here's the relevant diff - should apply OK to 0.42 I think.
cheers Miller
diff --git a/src/s_midi_pm.c b/src/s_midi_pm.c index fe123ff..856f121
100644
--- a/src/s_midi_pm.c +++ b/src/s_midi_pm.c @@ -241,44 +241,51 @@ void nd_sysex_inword(int midiindev, int status, int data1, int data2, int data3)
void sys_poll_midi(void) {
- int i, nmess;
- int i, nmess, throttle = 100; PmEvent buffer; for (i = 0; i < mac_nmidiindev; i++) {
int nmess = Pm_Read(mac_midiindevlist[i], &buffer, 1);
if (nmess > 0)
while (1) {
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message >> 24) & 0xFF);
int msgtype = (status >> 4) - 8;
switch (msgtype)
if (!throttle--)
goto overload;
nmess = Pm_Read(mac_midiindevlist[i], &buffer, 1);
if (nmess > 0) {
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1;
nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message >> 24) & 0xFF);
int msgtype = (status >> 4) - 8;
switch (msgtype)
{
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1; nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
nd_sysex_inword(i, status, data1, data2, data3);
} }
}else break; }
- overload: ;
}
void midi_getdevs(char *indevlist, int *nindevs,
On Sun, Jun 24, 2012 at 10:23:52AM -0400, Ivica Ico Bukvic wrote:
Does this affect the 0.42 branch as well? If so, would you mind sharing
the
relevant patch or svn commit?
Many thanks!
Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
BTW, this does not affect Linux, right? I ask this because my Linux build only uses s_midi_oss and s_midi_alsa source files...
On 06/24/2012 01:35 PM, Miller Puckette wrote:
diff --git a/src/s_midi_pm.c b/src/s_midi_pm.c index fe123ff..856f121 100644 --- a/src/s_midi_pm.c +++ b/src/s_midi_pm.c @@ -241,44 +241,51 @@ void nd_sysex_inword(int midiindev, int status, int data1, int data2, int data3)
void sys_poll_midi(void) {
- int i, nmess;
- int i, nmess, throttle = 100; PmEvent buffer; for (i = 0; i< mac_nmidiindev; i++) {
int nmess = Pm_Read(mac_midiindevlist[i],&buffer, 1);
if (nmess> 0)
while (1) {
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message>> 24)& 0xFF);
int msgtype = (status>> 4) - 8;
switch (msgtype)
if (!throttle--)
goto overload;
nmess = Pm_Read(mac_midiindevlist[i],&buffer, 1);
if (nmess> 0) {
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1;
nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message>> 24)& 0xFF);
int msgtype = (status>> 4) - 8;
switch (msgtype)
{
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1; nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
nd_sysex_inword(i, status, data1, data2, data3);
} }
else break; } }
overload: ; }
void midi_getdevs(char *indevlist, int *nindevs,
Correct - Mac and Windiws only. (One _could_ build pormidi for linux as well - perhaps this would be a good thing).
cheers Miller
On Thu, Jun 28, 2012 at 12:16:38PM -0400, Ivica Ico Bukvic wrote:
BTW, this does not affect Linux, right? I ask this because my Linux build only uses s_midi_oss and s_midi_alsa source files...
On 06/24/2012 01:35 PM, Miller Puckette wrote:
diff --git a/src/s_midi_pm.c b/src/s_midi_pm.c index fe123ff..856f121 100644 --- a/src/s_midi_pm.c +++ b/src/s_midi_pm.c @@ -241,44 +241,51 @@ void nd_sysex_inword(int midiindev, int status, int data1, int data2, int data3)
void sys_poll_midi(void) {
- int i, nmess;
- int i, nmess, throttle = 100; PmEvent buffer; for (i = 0; i< mac_nmidiindev; i++) {
int nmess = Pm_Read(mac_midiindevlist[i],&buffer, 1);
if (nmess> 0)
while (1) {
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message>> 24)& 0xFF);
int msgtype = (status>> 4) - 8;
switch (msgtype)
if (!throttle--)
goto overload;
nmess = Pm_Read(mac_midiindevlist[i],&buffer, 1);
if (nmess> 0) {
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1;
nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
int status = Pm_MessageStatus(buffer.message);
int data1 = Pm_MessageData1(buffer.message);
int data2 = Pm_MessageData2(buffer.message);
int data3 = ((buffer.message>> 24)& 0xFF);
int msgtype = (status>> 4) - 8;
switch (msgtype)
{
case 0:
case 1:
case 2:
case 3:
case 6:
sys_midibytein(i, status);
sys_midibytein(i, data1);
sys_midibytein(i, data2);
break;
case 4:
case 5:
sys_midibytein(i, status);
sys_midibytein(i, data1);
break;
case 7:
nd_sysex_mode=1; nd_sysex_inword(i, status, data1, data2, data3);
break;
default:
if (nd_sysex_mode)
nd_sysex_inword(i, status, data1, data2, data3);
} }
}else break; }
- overload: ;
}
void midi_getdevs(char *indevlist, int *nindevs,
-- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound& Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Hi Miller!
Indeed the problem is solved! Thanks!
On Jun 24, 2012, at 2:29 AM, Miller Puckette wrote:
Yep.. I already responded to the other thread but will mention it here too just to be thorough... I think I've got this fixed - it's up on the usual http://crca.ucsd.edu/~msp/software.html ... .43-3 test1.
cheers Miller
On Sat, Jun 16, 2012 at 01:20:05PM -0700, Miller Puckette wrote:
I went ahead and ordered a nice nanoKontrol2 - it should get here in a few days and I'll report whether I can finally see this myself.
cheers M
On Sat, Jun 16, 2012 at 10:11:02PM +0200, Ángel Faraldo wrote:
Hi,
thanks for your quick reply, Miller.
On Jun 16, 2012, at 9:39 PM, Miller Puckette wrote:
Hi Ángel -
I've seen a similar problem reported in Windows:
http://lists.puredata.info/pipermail/pd-list/2012-02/094794.html
and tried to recreate it with no success. I think the Max problem you found is something different (because at least there the values settle correctly when the sliders stop moving while for you it seems like something is ending up in the wrong state).
Exactly.
Anyway, with apologies I have to say I'm delighted you can get this to happen on a Mac - if indeed it's the same problem as on the PC it means it's in teh Pd code and so if I can ever get it to happen here I can probably fix it :)
I'm glad you're delighted, specially if a fix can come out of it.
thanks again!
ángel
Miller
On Sat, Jun 16, 2012 at 07:24:09PM +0200, Ángel Faraldo wrote:
Hi list,
Yesterday I bought a new korg nanoKontrol2. To my surprise, after a few basic testings, i've discovered that when I move as little as three faders sending CC values simultaneously --and not incredibly fast--, pd doesn't receive a big part of the values (with [ctlin]), staying half the way in the midi-value range.
---------For example, moving three faders from minimum to maximum, that is, from 0 to 127, the values in the number boxes connected to [ctlin] end up in random numbers in between (like 63, 74 and 70). Even more weird (or maybe not!) is that when I move any of the faders again, the next value that is thrown out is 126 (as if the object had actually gotten the previous 127 and is going down from there!)---------
Indeed, using a midi monitoring program ('MIDI monitor' on my mac), I can see that the computer receives all the midi values as expected, so I guess that something happens on the [ctlin] level in Pd.
Apparently this is/was also an issue on Max's implementation of [ctlin]: http://cycling74.com/forums/topic.php?id=19562
I have worked with other Midi controllers in Pd and I never had a similar problem.
i've also tried [midiin]->[midiparse], with exactly the same results.
(mac osx 10.6.8, pd-extended 0.42.5, pd-extended 0.43.1, pd 0.43.2)
any light on this??
cheers,
Ángel Faraldo
www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ángel Faraldo _________________ www.angelfaraldo.info