Hi,
I have the same problem. It affects several computers running XP, Vista
or Win7 and several Midi controllers; either connected to a RME
multiface or through USB (Korg NanoPad / Berinhger BCR2000 or BCF2000 /
Akai LPD8). Mostly using CC, hardly Midi-notes. And most of the time I
go through Midi-Ox and a virtual midi port (midi yoke) to merge all
controllers before sending to Pd. Midi-Ox checks for looping and should
be able to prevent it and my patches try to limit looping and Midi data
flow too.
It does look like there is some overflow of the midi I/O buffers.
I tend to limit the flow of data outgoing with [speedlim] and have a
separate sessions of Pd for the control/GUI and audio with the
audio/midi properties set differently between the two sessions.
For me it happens after big rushes of data: if I instantiate all the
parameters of a BCR2000 at once (over 100 parameters) at the same time
as updating the GUI in Pd it's not that hard to overload the midi
buffers and create this problem and it doesn't take two hours to crash
then... :)
And if you send a lot of stuff from the controllers too then it can lead
to the same issue.
I'm not sure it's only the flow of midi data, but it could be the Midi
data plus a lot of processing in Pd, especially with GUI objects moving
in response to the Midi input.
Re-instantiating the Midi-settings seems to flush the buffers, but
sometimes it takes a reboot to make the problem go away once everything
is stuck.
Cheers
Pierre-Olivier
On 26/02/2012 08:28, Ingo wrote:
I had the same problem with Windows XP and a RME Hammerfall DSP card using
only the normal [notein], [ctlin], [toutchin] and [pgmin] for a sampling
synth. I don't think it's the midi interface. RME has some of the best
drivers - very stable.
Sometimes after a certain amount of time it started playing notes by itself
and didn't seem to stop anymore. It sounded like notes or melodies that I
had been playing before. Nothing random.
Could it be possible that midi data is written into a buffer that does not
get emptied anymore? Then something might trigger reading out that buffer?
I couldn't recreate why it happened. Most of the time it didn't do it but
every once in a while it did.
I had no problem ever running Nuendo for days on that same machine
programming midi. The same Pd patch was doing fine on a Linux computer after
switching to Linux.
Ingo
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] Im Auftrag von
Miller Puckette
Gesendet: Sonntag, 26. Februar 2012 00:04
An: Villa Anna
Cc: pd-list
Betreff: Re: [PD] MIDI input problems in PD
I haven't seen this problem, but I have to admit I don't think I ever
ran MIDI into a Windows machine for more than 2 hours at a time (back
when I acually used MIDI Windows itself wasn't stable enough to run for
that long at a time :)
It's hard to know whether this is the MOTU driver misbehaving in windows 7
or something with Pd itself - my only suggestion would be to try either
(1) switching interfaces to something more modern than 828MKII or (2)
try using some other software to see if the problem is specific to PD.
cheers
Miller
On Sat, Feb 25, 2012 at 11:03:32AM +0100, Villa Anna wrote:
Dear list,
I have problems with Midi input in PD.
I use Windows 7 and make use of a Motu 828MKII soundcard.
I receive MIDI via a polytouchin object (make use of FSRs and a coridium
armmite to translate pressure on the FSRs to Midi messages).
All goes fine in the beginning, but sometimes after a while (f.e. 2
hours)
my Midi input starts to be random (FSRs trigger that are not supposed to
be
triggering). If I restart PD everything is back to normal. Any idea what
the cause of this problem might be?
It's an installation project so it is difficult to restart everything
from
time to time.
Thanks in advance for your help!
Laura
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
