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

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...

@jakey said:

This feels like it might be an OS error, but I couldn't find anything about the problem anywhere else..

Did you look on the Pd-list? Thread starts here:

https://lists.puredata.info/pipermail/pd-list/2017-08/120093.html

Known issue. Devs are working on it.

There are a couple of debounce abstracts in the la-kitchen external library.

If you are installing it in vanilla, you will have to manually specify the path as there is currently a bug that affects any external libraries with dashes in the names. You can also just copy and paste the abstracts out of the help files.

I can confirm now that this is definitely a linux version specific issue. I just checked three releases of UbuntuStudio -- 14.04, 16.04, and the new 17.10 (forgot to grab 15.10). Out of those three only 16.04 has this issue. The Sid install which I "fixed" with the above linked workaround is now aligned with Debian 9.

Hope we can write this one off as a passing upstream fumble. Would be nice to know of a specific component in 16.04 that could be replaced.

I linked to this related thread from here:

https://forum.pdpatchrepo.info/topic/11063/pd-0-48-font-size-issue

with some additional notes on the font startup flags from the Pd list.

Hi, I had a similar (but not the same) font-sizing issue related not to the version of Pd, but the version of linux I was using. Not sure if it will help, but the problem along with the workaround solution I found is described in this thread:

https://forum.pdpatchrepo.info/topic/10915/font-issue-with-new-linux-distros

BTW -- there was some clarification on the Pd list as far as exactly how those font startup flags are supposed to work. The -font-size flag is different than the -font-face and -font-weight flags in that while the latter two flags will affect all patches opened after Pd starts, the -font-size flag will only affect the default font size applied to newly created patches. Supposedly this is because the font size is the only parameter out of the three that is actually stored in the patch. Personally I still find it to be a glaring inconsistency, especially since this is not explicitly stated in the help file. Nonetheless, this is how it's supposed to work.

Keep in mind that specifying font face or weight will also affect the sizing and spacing so if you specify either of those two variables along with -font-size it may appear that -font-size is having an effect on previously created patches when it is actually the other variables causing the change.

For what it's worth, I was able to more or less "fix" the sizing/spacing problems with my patch by following the instructions at the top of this page:

https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-%26-comparisons

Not an ideal solution, wish I knew what the heck those upstream guys are thinking (or not thinking).

@Roomy You might want to bring your class instructor up to speed as to the current state of Pd Extended. Doesn't seem right to expect students to rely on a piece of old dead software to complete their work. We've seen more than a few issues on here with Extended and newer operating systems.

I don't know if this helps (depends on what you are doing), but one reason I haven't had much use for [pd~] yet is because I usually just run multiple instances of PureData when I need different startup variables. The main issue you might have as using this method as a workaround for your problem is setting up the needed communication between the two instances.