I'm trying to create a MIDI environment for my MS2000 to extend its warranty of "fun."

However, I've noticed in the midi dump for a single patch random 0's. They always arrive in the same location UNLESS I switch between generic or low latency kernels on Ubuntu.

I've not tried realtime at this moment. I've tried taking the received data and transmitting it back without any alterations, received a data error from the MS2000.

I'm extending this research outward in case someone happens to have experienced this as a puredata / maybe qjackctl / audio domain.

Connection comes through a Motu Timepiece
Roland Um One

Have not been able to find a related scenario in any of my searches. I don't like fully relying on my workaround which assumes the faulty zero's will just "stay put."

Any insights or pointers appreciated!

I am not sure if I understand the description of your problem, though I am not sure if it matters as long as it has anything to do with SYSEX failure in Pd.

Are you running both those interfaces directly in Linux?

Also, what version of Pd?

I do have some general info about obtaining and or maximizing MIDI/SYSEX performance with Pd.

Linux and Mac platform Pd is partially functional with regards to SYSEX but to obtain full functionality requires some minor tweaks be made to the source code and compiling Pd from said source. Windows Pd has it's own problems with SYSEX and MIDI, for which I know of no current solution.

edit: misread the post, I think...

@NoDSP

Sorry, I'll see if I can clarify a little further.

My motu handles most of the channel routing, etc. Nothing complicated. It's one of the older models without USB, so the Laptop <-> UM one <-> Motu <-> Ms2000

This is consistent across PD .47 and .48

I have not tried realtime kernel yet.

I had some time to do a couple more tests. Removing the Motu from the chain, and monitoring with kmidimon and no other applications running, including qjack.

The returned result induces zeros in the same location. Now for a quick gotcha: I have another ms2000, same result.

So it's not the ms2000(s), or the motu. This leaves the UM-One, or my computer configuration.

I can resurrect a windows zombie to do a basic midi monitor there, but it won't completely rule out the UM-One.

I'd be happy to learn more about midi tweaks, as it seems my primary use of pure data is to develop a midi ecosystem more than sounds and synthesis.

Thanks for checking in

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

If you are looking for a midi thru function rtmidi has a flag allow_types(false, false, false) which allows extended vars, this may not make sense if this but i got python to back ya, rtmidi is very common acrossed the board linux and mac os + windows: check this python script, problem is probably lack of constructor vars w/ more arguments and jacks lack of handling hardware IO https://github.com/8888clockradio/iridescentCoconut/blob/master/beatstepUSBtoSPDSXsoftwareThru.py

Standard midiin and midiout objects are not fully collecting and sending all data

Correction: ignore_types(False, False, False)

Do sysex w/ rtmidi or rtmidi-python

Thank you all for your responses. I've been away from this specific challenge as it's been stable "as-is," and my preemptive goal is to finish my performance suite and teaching myself the in/out of pure data itself.

In the future I plan on trying all these options in step and document the path to hopefully a fix. I have some experience in instructional writing and documentation so I hope to also write up whatever path leads to a solution for potential help of others.