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.

It appears to be DSP-centric oversight or some unfinished functionality at work here. I noticed it is possible to go into the sub-process media menu and manually create midi ports for the sub-process after it is started, but as you say -- no way to do it with the sub-process startup flags.

@RolandTpd Definitely the wrong place to post this. You should probably start a new thread in the technical issues section of the forum. Use the New Topic button above the first post on the list.

https://forum.pdpatchrepo.info/recent

AV Linux is a totally separate Debian based distribution that has nothing to do with Ubunttu -- on purpose.

http://www.bandshed.net/avlinux/

http://distrowatch.com/table.php?distribution=avlinux

This thread is already rather dated: AV linux has a new 2017 version (there was also some word they going to move to J2).

Check this, too:

https://forum.pdpatchrepo.info/topic/5235/fiddle-signal-to-midi-better-way-to-generate-midi-note-durations

I'll let someone else chime in with specific Pd patch examples, but the central objects to any patch that does this would be the [ftom] (control) and [ftom~] (DSP audio signal) objects. You can read the Pd help files on those to give yourself a head-start.

@jancsika That's not a bad idea in principal -- some of the other linux midi apps give you the option of patching both externally and from a patching routine internal to the app -- but beware. A lot of the time I notice those internal patch routines either don't work properly or cause conflicts/screw-ups with the external patch apps in situations where you find you have to use both. I don't know if it's because of improper coding of the internal patch routines or a limitation of the Alsa midi system, but It's for that reason I always use the external option with all my linux midi apps.

I'm just trying to say that all the midi patching stuff may be more complicated than it seems on the surface. The Mac and Windows Pd Vanilla midi dialogues are supposed to work that way but I can tell you they are definitely broken; not just because of the limited 9 port access (it's currently 4 in L2ork?) but because something isn't right (or completely absent) in the whole port multiplexing scheme. I've never been able to connect those 9 ports past the first 9 midi ports on the Mac's system list. You can test this with any application that will create virtual midi ports, network midi ports etc.

@NoDSP said:

I know they tried implementing something like that in Pd some time ago...

Just for reference, here's the Pd list thread I was referring to:

https://lists.puredata.info/pipermail/pd-list/2012-10/098642.html

@jancsika said:

I don't think anyone is asking for auto-patching.

Well, the OP was asking for a "plug and play" option, which I would take as auto-patching a connected midi device to the first available input in Pd.

Well, sort of.

You can use the 'greater than" operator in combination with a route object to do a basic absolute-to-binary conversion, like so:

absolute-to-binary1.pd

You may want to add a line object in there to smooth things out in case of value jumps from the encoder or you'll start to lose range -- but that brings us to the second problem. That is, how much range do you need for your "endless" value? If you only need 128 steps, you're all set. If you need more than that (or less) you need to do a bit more work.

If the 0-127 encoder wraps back to 0 after you exceed 127 and back to 127 when you go below zero, that would be one problem. However, most I have seen have a "stop" at the max or min value no matter how far you turn them. You might try adding a second route object in that case:

absolute-to-binary2.pd

Anyway that's a start...

Pardon If I'm behind the curve here (I'm still using L2ork v1 most of the time) but last I checked Jack Midi was not an available option in any version of Pd. You can connect through the jack midi patcher in Qjackctl (the second tab in the connections dialogue box after audio) but only if you have the jack/alsa midi bridge running. That just lets you patch jack midi only apps through to alsa midi only apps and vise-versa. I personally always use the third tab (confusingly only labeled "alsa" when it should be "alsa midi") because jack midi presently has no way to handle the larger sysex messages I deal with and blocks them by default.

Anyway the point is that If you are using any Pd variant you are always using either Alsa midi or OSS midi (actually the OSS is just an alsa-based simulator now so you're really always using alsa, but I digress). There are a few other graphical audio/midi patcher programs such as Patchage or the similar Catia program from the KXStudio package but AFAIK they all require you to set up the connections manually at least once.

However, all of those programs allow you to save your patching setup for instant automatic recall the next time you need it. In Qjackctl this is done from the "Patchbay" dialogue box. I haven't used it in awhile but if you mess with it you'll find a way to save the current set of connections. Qjackctl is pretty messy and counter-intuitive thou so for beginners you might want to have a look at the other options mentioned above.

AFAIK there's no auto-midi patching options available. I know they tried implementing something like that in Pd some time ago but they disabled it because it ended up causing more problems than it solved. There's info about that buried in the Pd list somewhere....

Ok I took a cursory look at the patch, and the first thing I notice is that you appear to be connecting your makenote objects to the raw midiout objects. The first and second outputs from makenote (note number, note velocity) are supposed to be connected to the first and second inputs (respectively) of the noteout object. The current arrangement of your patch will most likely not send anything (at least, not anything an external midi device or application will recognize). Check the help files for the proper use of the midi objects.