PD tries to handle MIDI as fast as it gets it, hence Miller's warning.
First, does Pd lock up on the RPI *without* your patch running? If so, then Pd itself is clogged up by all the messaging on the RPI. If it's your patch, then your message handling can/should be optimized ala Ingo's suggestion. Do you have any GUI objects in the message chain? If so, the fast messaging will also be causing GUI updates which may be slow on the RPI. Another way to check this is to run Pd with -nogui and see if it works without hanging.
On Feb 21, 2020, at 12:00 PM, pd-list-request@lists.iem.at wrote:
From: Andrew Lyons <tstexture@gmail.com mailto:tstexture@gmail.com> To: pd-list <pd-list@iem.at mailto:pd-list@iem.at> Subject: [PD] Throttling midi message rates Message-ID: <CAF3KZatNm75zFtG7WVJt_3hF8VcoP0ZjL96GGBVrx_bSuG+6pw@mail.gmail.com mailto:CAF3KZatNm75zFtG7WVJt_3hF8VcoP0ZjL96GGBVrx_bSuG+6pw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi,
I have an FCB 1010 MIDI foot pedal controller with 10 switches and two pedals. One of the foot pedals is used to control glissando rate. More specifically, it is hooked up to a vline~ object in pd. (I originally used a line.)
If I change the pedal position too quickly, it locks up PD, and I have to kill and restart the software. I have not encountered this before, but I remember Miller saying something about "bad things happen" if the MIDI input rate is too high in one of his MS171 lectures.
I do not have access to the firmware code on the foot pedal board, so I'm hoping there is a way to throttle MIDI data rates in PD. I am running on a raspberry pi 3 (buster) in a Zynthian kit.
Any pointers appreciated.
Thanks!
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Looks like this issue https://github.com/pure-data/pure-data/issues/895 I can recover the locked-up Pd by disconnecting the ALSA MIDI in the QjackCtl Graph. (see animated gif in the github issue)
The MIDI device I'm experiencing this issue with is a Sensel Morph in 14bit MIDI mode.
@ Andrew Lyons Pleas don't hijack threads. If you have a new question, compose a new email to pd-list@lists.iem.at and never just take a random old email and change the subject / content. https://puredata.info/community/lists/Netiquette
On 21.02.20 12:29, Dan Wilcox wrote:
PD tries to handle MIDI as fast as it gets it, hence Miller's warning.
First, does Pd lock up on the RPI *without* your patch running? If so, then Pd itself is clogged up by all the messaging on the RPI. If it's your patch, then your message handling can/should be optimized ala Ingo's suggestion. Do you have any GUI objects in the message chain? If so, the fast messaging will also be causing GUI updates which may be slow on the RPI. Another way to check this is to run Pd with -nogui and see if it works without hanging.
On Feb 21, 2020, at 12:00 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: Andrew Lyons <tstexture@gmail.com mailto:tstexture@gmail.com> To: pd-list <pd-list@iem.at mailto:pd-list@iem.at> Subject: [PD] Throttling midi message rates Message-ID: <CAF3KZatNm75zFtG7WVJt_3hF8VcoP0ZjL96GGBVrx_bSuG+6pw@mail.gmail.com mailto:CAF3KZatNm75zFtG7WVJt_3hF8VcoP0ZjL96GGBVrx_bSuG+6pw@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hi,
I have an FCB 1010 MIDI foot pedal controller with 10 switches and two pedals. One of the foot pedals is used to control glissando rate. More specifically, it is hooked up to a vline~ object in pd. (I originally used a line.)
If I change the pedal position too quickly, it locks up PD, and I have to kill and restart the software. I have not encountered this before, but I remember Miller saying something about "bad things happen" if the MIDI input rate is too high in one of his MS171 lectures.
I do not have access to the firmware code on the foot pedal board, so I'm hoping there is a way to throttle MIDI data rates in PD. I am running on a raspberry pi 3 (buster) in a Zynthian kit.
Any pointers appreciated.
Thanks!
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I did start a new thread. I suspect you are mistaken. Happy Friday!
@ Andrew Lyons Pleas don't hijack threads. If you have a new question, compose a new email to pd-list@lists.iem.at and never just take a random old email and change the subject / content. https://puredata.info/community/lists/Netiquette
Am 21. Februar 2020 18:52:00 MEZ schrieb Andrew Lyons tstexture@gmail.com:
I did start a new thread. I suspect you are mistaken. Happy Friday!
you most certainly did not.
your original mail contains a header:
In-Reply-To: 2BB7A77D-3F7E-479A-8078-11707CBF3AAE@gmail.com
...and accordingly shows up as a reply to fede's email on "pd-start-dsp" messages.
whenever you hit "reply", you are *not* starting a new thread, even if you remove the subject and the body (and the recipient,...) and replace all of them with your own values...
mfg.hft.fsl IOhannes
Ok. My bad. Nouveau client snafu.
On Fri, Feb 21, 2020, 2:40 PM IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 21. Februar 2020 18:52:00 MEZ schrieb Andrew Lyons <tstexture@gmail.com
: I did start a new thread. I suspect you are mistaken. Happy Friday!
you most certainly did not.
your original mail contains a header:
In-Reply-To: 2BB7A77D-3F7E-479A-8078-11707CBF3AAE@gmail.com
...and accordingly shows up as a reply to fede's email on "pd-start-dsp" messages.
whenever you hit "reply", you are *not* starting a new thread, even if you remove the subject and the body (and the recipient,...) and replace all of them with your own values...
mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Thanks Dan. I'll run some more tests and try out Ingo's suggestion.
On Fri, Feb 21, 2020, 3:29 AM Dan Wilcox danomatika@gmail.com wrote:
PD tries to handle MIDI as fast as it gets it, hence Miller's warning.
First, does Pd lock up on the RPI *without* your patch running? If so, then Pd itself is clogged up by all the messaging on the RPI. If it's your patch, then your message handling can/should be optimized ala Ingo's suggestion. Do you have any GUI objects in the message chain? If so, the fast messaging will also be causing GUI updates which may be slow on the RPI. Another way to check this is to run Pd with -nogui and see if it works without hanging.
On Feb 21, 2020, at 12:00 PM, pd-list-request@lists.iem.at wrote:
From: Andrew Lyons tstexture@gmail.com To: pd-list pd-list@iem.at Subject: [PD] Throttling midi message rates Message-ID: CAF3KZatNm75zFtG7WVJt_3hF8VcoP0ZjL96GGBVrx_bSuG+6pw@mail.gmail.com Content-Type: text/plain; charset="utf-8"
Hi,
I have an FCB 1010 MIDI foot pedal controller with 10 switches and two pedals. One of the foot pedals is used to control glissando rate. More specifically, it is hooked up to a vline~ object in pd. (I originally used a line.)
If I change the pedal position too quickly, it locks up PD, and I have to kill and restart the software. I have not encountered this before, but I remember Miller saying something about "bad things happen" if the MIDI input rate is too high in one of his MS171 lectures.
I do not have access to the firmware code on the foot pedal board, so I'm hoping there is a way to throttle MIDI data rates in PD. I am running on a raspberry pi 3 (buster) in a Zynthian kit.
Any pointers appreciated.
Thanks!
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
-
Andrew Lyons -
Dan Wilcox -
IOhannes m zmölnig -
Max