(responding again in thread)
It is most likely a bug, maybe introduced in the MIDI overhaul I did for 0.48. Does the same issue occur in 0.47?
Can make a *re-produceable* patch and/or project for testing and open an issue on the pure-data Github repo? The simplest thing for me would be the syses messages you're sending as bytes.
You could also check the output of the midi tester patch I added:
Browser -> Pure Data/7.stuff/tools/miditester.pd
Hi,
Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a video that shows the issue: https://vimeo.com/316526250 it's a private video, the pass is: sysexissue Does anybody know what could cause this behavior and if it's possible to 'fix it'? The first time I reported it, it was when I stumbled on this using my personal Linux machine and Miller Puckette suggested to change the MIDI buffer in the source code, but unfortunately also setting that to something insane like 2^20, the issue was still there. Now I double checked on MacOS Sierra and Windows 10 and it is the same.
Cheers, Mario
I did a test patch (attached)
I can send 7 byte sysex messages up to every 3ms
I can send noteout up to every 2ms
This tests gave same results if using a midicable (cable loop on the sound-card) or using a virtual driver.
Mensaje telepatico asistido por maquinas.
On 2/11/2019 10:55 AM, Dan Wilcox wrote: (responding again in thread)
It is most likely a bug, maybe introduced in the MIDI overhaul I did for 0.48. Does the same issue occur in 0.47?
Can make a *re-produceable* patch and/or project for testing and open an issue on the pure-data Github repo? The simplest thing for me would be the syses messages you're sending as bytes.
You could also check the output of the midi tester patch I added:
Browser -> Pure Data/7.stuff/tools/miditester.pd
Hi,
Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a video that shows the issue: https://vimeo.com/316526250 it's a private video, the pass is: sysexissue Does anybody know what could cause this behavior and if it's possible to 'fix it'? The first time I reported it, it was when I stumbled on this using my personal Linux machine and Miller Puckette suggested to change the MIDI buffer in the source code, but unfortunately also setting that to something insane like 2^20, the issue was still there. Now I double checked on MacOS Sierra and Windows 10 and it is the same.
Cheers, Mario
-- Dan Wilcox @danomatika danomatika.comhttp://danomatika.com robotcowboy.comhttp://robotcowboy.com
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Do other applications handle MIDI this quickly? The original spec is quite slow and processing MIDI at such a (relatively) high speed is probably running up against Pd's block boundary.
See the following discussion: https://github.com/pure-data/pure-data/issues/399
On Mon, Feb 11, 2019 at 4:19 PM Lucas Cordiviola lucarda27@hotmail.com wrote:
I did a test patch (attached)
I can send 7 byte sysex messages up to every 3ms
I can send noteout up to every 2ms
This tests gave same results if using a midicable (cable loop on the sound-card) or using a virtual driver.
Mensaje telepatico asistido por maquinas.
On 2/11/2019 10:55 AM, Dan Wilcox wrote:
(responding again in thread)
It is most likely a bug, maybe introduced in the MIDI overhaul I did for 0.48. Does the same issue occur in 0.47?
Can make a *re-produceable* patch and/or project for testing and open an issue on the pure-data Github repo? The simplest thing for me would be the syses messages you're sending as bytes.
You could also check the output of the midi tester patch I added:
Browser -> Pure Data/7.stuff/tools/miditester.pd
Hi,
Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a video that shows the issue: https://vimeo.com/316526250 it's a private video, the pass is: sysexissue Does anybody know what could cause this behavior and if it's possible to 'fix it'? The first time I reported it, it was when I stumbled on this using my personal Linux machine and Miller Puckette suggested to change the MIDI buffer in the source code, but unfortunately also setting that to something insane like 2^20, the issue was still there. Now I double checked on MacOS Sierra and Windows 10 and it is the same.
Cheers, Mario
-- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Lucas,
I tried your patch on a MacBook Pro 2.7 GHz Intel Core i5 16 GB of ram and I can easily send SysEx from your patch faster then 3 ms (1 ms is more than fine and I'm sure we can go even faster). I'm using a virtual MIDI port by the way. In fact the point is, if we're talking about MIDI over MIDI DIN, there are some limitations. The max you can cope with is roughly 3 bytes per msec (see MIDI HW baudrate), then of course the HW device would probably have some internal buffer to use in case it receives more msg than can actually handle. In terms of USB MIDI the bandwidth is way bigger than that. We are talking about 12 Mbit per second for a USB 1.0 device (let's say a class compliant device that then doesn't use any special driver). I remember I found once in the portmidi source code ( https://sourceforge.net/projects/portmedia/files/portmidi/217/ - pmmacosxcm.c) a comment that says:
/* maximum overall data rate (OS X limit is 15000 bytes/second) */ and then #define MAX_BYTES_PER_S 14000
I'm assuming other OSs would deal with something at least similar to that (I know Windows is not as good as MacOS on that, and unfortunately Linux with ALSA neither). In my case I'm using and class compliant HW device connected via USB. I know for sure MidiMonitor, Max/MSP and Python (using python-rtmidi) can handle this data. I'll try to create something we can use to test this and open an issue on github.
Cheers, Mario
On Mon, 11 Feb 2019 at 15:19, Lucas Cordiviola lucarda27@hotmail.com wrote:
I did a test patch (attached)
I can send 7 byte sysex messages up to every 3ms
I can send noteout up to every 2ms
This tests gave same results if using a midicable (cable loop on the sound-card) or using a virtual driver.
Mensaje telepatico asistido por maquinas.
On 2/11/2019 10:55 AM, Dan Wilcox wrote:
(responding again in thread)
It is most likely a bug, maybe introduced in the MIDI overhaul I did for 0.48. Does the same issue occur in 0.47?
Can make a *re-produceable* patch and/or project for testing and open an issue on the pure-data Github repo? The simplest thing for me would be the syses messages you're sending as bytes.
You could also check the output of the midi tester patch I added:
Browser -> Pure Data/7.stuff/tools/miditester.pd
Hi,
Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a video that shows the issue: https://vimeo.com/316526250 it's a private video, the pass is: sysexissue Does anybody know what could cause this behavior and if it's possible to 'fix it'? The first time I reported it, it was when I stumbled on this using my personal Linux machine and Miller Puckette suggested to change the MIDI buffer in the source code, but unfortunately also setting that to something insane like 2^20, the issue was still there. Now I double checked on MacOS Sierra and Windows 10 and it is the same.
Cheers, Mario
-- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I got a repro. Here's a video that shows it (pass: sysexissue): https://vimeo.com/316624285 I'll open an issue on github with the patches I used.
Cheers, Mario
On Mon, 11 Feb 2019 at 19:17, Mario Buoninfante mario.buoninfante@gmail.com wrote:
Hi Lucas,
I tried your patch on a MacBook Pro 2.7 GHz Intel Core i5 16 GB of ram and I can easily send SysEx from your patch faster then 3 ms (1 ms is more than fine and I'm sure we can go even faster). I'm using a virtual MIDI port by the way. In fact the point is, if we're talking about MIDI over MIDI DIN, there are some limitations. The max you can cope with is roughly 3 bytes per msec (see MIDI HW baudrate), then of course the HW device would probably have some internal buffer to use in case it receives more msg than can actually handle. In terms of USB MIDI the bandwidth is way bigger than that. We are talking about 12 Mbit per second for a USB 1.0 device (let's say a class compliant device that then doesn't use any special driver). I remember I found once in the portmidi source code ( https://sourceforge.net/projects/portmedia/files/portmidi/217/ - pmmacosxcm.c) a comment that says:
/* maximum overall data rate (OS X limit is 15000 bytes/second) */ and then #define MAX_BYTES_PER_S 14000
I'm assuming other OSs would deal with something at least similar to that (I know Windows is not as good as MacOS on that, and unfortunately Linux with ALSA neither). In my case I'm using and class compliant HW device connected via USB. I know for sure MidiMonitor, Max/MSP and Python (using python-rtmidi) can handle this data. I'll try to create something we can use to test this and open an issue on github.
Cheers, Mario
On Mon, 11 Feb 2019 at 15:19, Lucas Cordiviola lucarda27@hotmail.com wrote:
I did a test patch (attached)
I can send 7 byte sysex messages up to every 3ms
I can send noteout up to every 2ms
This tests gave same results if using a midicable (cable loop on the sound-card) or using a virtual driver.
Mensaje telepatico asistido por maquinas.
On 2/11/2019 10:55 AM, Dan Wilcox wrote:
(responding again in thread)
It is most likely a bug, maybe introduced in the MIDI overhaul I did for 0.48. Does the same issue occur in 0.47?
Can make a *re-produceable* patch and/or project for testing and open an issue on the pure-data Github repo? The simplest thing for me would be the syses messages you're sending as bytes.
You could also check the output of the midi tester patch I added:
Browser -> Pure Data/7.stuff/tools/miditester.pd
Hi,
Not too long ago I wrote here reporting an issue with receiving SysEx messages. When Pd receives a big quantity of SysEx, the MIDI IN port 'gets stuck' and then you need to go to 'Media->MIDI settings...' and re-select the port, otherwise no MIDI messages will be received anymore. Here's a video that shows the issue: https://vimeo.com/316526250 it's a private video, the pass is: sysexissue Does anybody know what could cause this behavior and if it's possible to 'fix it'? The first time I reported it, it was when I stumbled on this using my personal Linux machine and Miller Puckette suggested to change the MIDI buffer in the source code, but unfortunately also setting that to something insane like 2^20, the issue was still there. Now I double checked on MacOS Sierra and Windows 10 and it is the same.
Cheers, Mario
-- Dan Wilcox @danomatika danomatika.com robotcowboy.com
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
Lucas Cordiviola -
Mario Buoninfante