Hi,
I don't understand this behaviour:
When I send a sysex message to midiout, midiin (and sysexin) receive it.

• also when nothing is connected to the midi-interface
  Also when I send something to noteout it comes back from midiin and notein.
  Can I remove the midi-feedback-loop in my alsa configuration?

I had a cheap noname usb-midi interface (oss-driver), which did not do that.
This interface was not reliable for sysex-messages so I replaced it by a m-audio midisport uno. It works great, it receives and transmits long sysex-messages without errors.( alsa-midi driver)
But in pd the outgoing messages get to the midin also.
I tried sending a string with amidi instead (ping to my synth):
amidi --port=hw:2,0,0 --send-hex="f0 00 00 7e 4b 00 0f f7" --dump

amidi shows no repeating output on the input (only pong from synth), so it must be something related to pd (or alsa-midi routing?).

raspbian wheezy, pd-extended

Can I change this somehow? Is there an oss-driver for midisport uno?

Cleaning up the received data is stupid work and I hope unnecessary...
best regards

I've seen this behavior on other MIDI realtime data, e.g., MIDI clock. I forget the exact circumstances, but I've definitely seen it.

At the moment, I forget if this was a pd error or mine. I did a lot of testing with loopMIDI & MIDIYoke, with my output=my input. I actually found this to be a very useful configuration & ultimately made my code handle this scenario (e.g., input & output being the same loopMIDI port). That way I could xlate one type of message into another, a useful mental model for what I was trying to do.

Are you sure your midi monitor isn't creating a loop?
Does this happen with NO MIDI devices configured, i.e., all MIDI ports set to 'none'?

I wish I COULD see it on sysexin. I have not successfully been able to receive sysex (Windows, pd extended 0.43.4).

I'm curious - what version of pd are you running?

I found the problem.
There is a alsa midi-through device that has to be disabled:

"
sudo rmmod snd_seq_dummy

permanently:

sudo sh -c "echo blacklist snd_seq_dummy > /etc/modprobe.d/blacklist-seq-dummy.conf"

which will create a configuration file that tells modprobe (the linux device driver loader) not to load snd_seq_dummy. It can be easily reversed by just deleting the file.)
"

pd connects automatically to it i think.

"aconnect -i -o -l"

shows all virtual midi connections.

Ok, this works fine, but now I have to discover why Pd does not start alsa-midi with my startup script in etc/rc.local .... grrrrrr.

@ shawnb

I'm using Pd 0.43.4-extended on a Raspberry Pi running Linux (Raspbian).
On Mac sysex stuff works, but I can't try on windows.
Can't you try midiin instead of sysexin?

A lot of midi hardware does not work good with sysex messages:

http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist

I don't get why it is so complicated to send a few bytes..

But if it is really pd win that does not work with sysex, perhaps you could get it into pd via a python script that sends it via udp or pyext to Pd. I think I saw a midi library for python somewhere.

best regards
Jens

I tried a bit on linux and mac and saw that midiclock input is not working with pd-extended. Perhaps it works in newer pd vanilla versions:

http://lists.puredata.info/pipermail/pd-dev/2013-08/019599.html

> > On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote:
> >> Hmm... just looking at the code in s_midi_pm.c I can't understand how
> >> it could ever have worked for sysex or 'system' messages.

Perhaps midi-input works better in pd-extended 0.44?
I couldn't compile the latest pd-extended 0.44 on linux, so I tried a workaround with a python script that forwards midiinput to an udp-port. This works to get midiclock and sysex into pd-extended.

You need python and python_rtmidi:
https://pypi.python.org/pypi/python-rtmidi

Python-script and Pd-patch attached.
start the python-script from terminal and don't use oss-midi in pd (alsa or no midiinput at all), because this will block alsa-midi from opening the midiport.

Tried on Raspberry pi, pd-extended 0.43, python 2.7

Does someone know if this is also possible with py/pyext?
I could print midi-messages to the pd-window but I don't understand object oriented programming enough to get the midi-messages out of an pyext outlet.)

best regards
Jens

http://www.pdpatchrepo.info/hurleur/midiclock_py2pd.zip

Haven't used python. I am able to get MIDI clock messages using [midirealtimein] in this patch:
http://puredata.hurleur.com/sujet-10040-simple-fun-generator

The only MIDI issue I've had with pd is with sysexin - everything else I've tried in MIDI has worked fine (including PCs, CCs, notes, clock & sending sysex). Sysex input doesn't show up on [sysexin], [midirealtimein], or [midiin].

pd-extended, 0.43.4, Windows

A couple of clarifications, following the links in your earlier posts:

My experience is with MIDI Clock on pd, which supports start/stop & tempo, useful for syncing effects across systems, but not for communicating song position. [midirealtimein] works for MIDI Clock.

I do not use MIDI Timecode, which is basically a MIDI implementation of SMPTE and allows for song position pointers. Since MIDI Timecode uses sysex messages, I would wager that if you can get sysex to work on pd, you can get MIDI timecode to work on pd.

There is a lot of really inaccurate info out there on these two protocols, and the jargon is inconsistent from app to app & community to community. Wikipedia thankfully has good data on the specifics of the two:
http://en.wikipedia.org/wiki/MIDI_timecode
http://en.wikipedia.org/wiki/MIDI_beat_clock

To be honest, I don't trust the 'blacklist'. Most of those links had '?'s, which meant that the issue was never confirmed with a second report - all it took was one person to have an issue he couldn't resolve to get a product on that list. I've used MIDI for many years, and in my experience, even large sysex dumps can be made to work. Resolving issues with large sysex dumps usually requires finding & setting a buffer size somewhere that was set too low for bulk data. (Such large syex dumps are used to backup device settings for synthesizers & effects processors, etc., for the purposes of restoring the device's state at a later time.)

My strong suspicion is that the only reason pd users report issues with large sysex messages is that the buffer is not visible/configurable, that it's a hard-coded fixed tablesize somewhere.

I've never had an issue with sysex in small chunks, across a lot of gear & software & versions of windows over the years. (Other than pd's inability to receive sysex...)

Thanks for your clarifications. learned something.
I was not aware how Midi Timecode works and will try midirealtimein.
The default buffersize of rtmidi is 1024 Bytes for example. But receiving nothing instead is suspicious...
My cheap Midi-to-USB-cable only receives the first 3 bytes of sysex-messages. I think it expects notes, but you are right - perhaps the software is often the bottleneck.

Just for fun I tried to get rtmidi working with pyext again and understand this language much better now. I attached the script for pyext and a pd-testpatch. The external spits out sysex, notes, controller, midiclock as lists or stream of numbers. If my first Python script works on your machine, this external should also receive sysex within pd.
You should close pd's midi-inputs (with alsa-midi driver on linux you can leave it open).
I just tried this external on my raspberry pi and saw nearly no audio i/o error warnings anymore- a nice side-effect! Perhaps pyext scripts have lower priority?
Buffersize for sysex is 4096 Bytes.

tested on raspberry pi with pd-extended 0.43.4, py/pyext, python 2.7, python-rtmidi

jens

http://www.pdpatchrepo.info/hurleur/rtpy.zip

royal_orchestra -

I don't use python, so I can't test your patch.

As an FYI, I just attempted to receive MTC (MIDI Timecode) into pd, and I'm sad to report it doesn't work (on Win7). It should show up as a sequence of pairs of bytes, the first byte always xF1. (Look at the quarter-frame message definitions at the bottom of the Wikipedia article on MIDI Timecode.) The xF1 (241 dec) appears, but not the actual data byte.

The xF1 appears on [midiin], but without the databyte it is useless.

Attached is a very simple MIDI diagnostic pd patch. It's not pretty, but it's very helpful at telling you what is on the MIDI bus that is visible to pd, and which messages report it. It is only helpful at showing you where to start...

Shawn
(pd-extended, 0.43.4, Win7)

http://www.pdpatchrepo.info/hurleur/Learning-8-MIDI-Diag.pd

sorry- I didn't want to bother you with patches you don't need.
Just thought it might be interesting for other forum-readers.
Thanks for the patch, I didn't know a lot of objects.
Midirealtimein works good. I didn't know that midiin doesn't output Midi-clock.

I just created some random Timecode - Messages following the rules described on Wikipedia and could successfully send and receive full-time-codes and complete quarter frame messages with built-in pd-objects on linux.

Perhaps it is a windows-driver problem?
Jens

For even more MIDI functions, open up help for one of those objects. Towards the bottom of each help page is a link for pd Related_objects. I have found it very, very helpful to constantly scan the related objects when I'm doing almost anything in pd.

Regarding pd dropping some data (e.g., no sysexin), I doubt it's a driver issue, since I've seen these pd issues on multiple devices on multiple systems. These systems work perfectly outside of pd, so my Windows & device drivers work fine.

It's either different code, or a build/compiler directive problem.

Ahhhh...... Do I want to look at the code? I seem to enjoy rabbit holes...