IAC Bus stops working /Midi from Processing using midibus

[agent well]

Hello there,

I am sending midi notes from Processing to Ableton Live over the IAC Bus using the midibus library for p5.

This usually works great, but every now and then a strange thing happens:

Abletons Midi Indicator is still flashing when i send midi from Processing.
However, the notes don't trigger Instruments anymore!

I also noticed, that when "Midi From" is set to All Ins, input from the Computer Keyboard doesn't go through either.
Only when I specifically select "Computer Keyboard" as input.
Unfortunately this doesn't work for the IAC Busses.

So I tried turning the ports on and off in the settings as well as in OS X Audio-Midi Settings, restarting software, even killing the MidiServer process.
All without luck.

The only way to fix this problem was to restart the computer!

Any other solutions/tipps to fix this problem?

Does anybody know, what might be causing this?
It feels like the IAC bus crashes.
I might send to many and/or wrong formatted midi commands.
Tried including slight delays (4 ms) before sending new commands. No luck.
I also don't send note offs, but let "Note Length" MIDI Effect handle it.
Might be a problem.

I am thankfull to any tips solving this problem, as this concerns my diploma project and i can't afford to have this stuff stop working during my presentation...

Best,
Jonas

Mac OS X 10.6.8
Ab Live 8.3.
Latest midibus lib

Similar/same bug??
http://puredata.hurleur.com/sujet-3264- ... ks-noteout

[UncleAge]

You are not alone in the universe

I had pretty much the same experience. Pretty much to a "T". Just like you I was using Processing, but it wasn't a project of mine. It was Glitch Sequencer which is done in processing http://www.glitch-sequencer.com/documentation.php

What was odd was that if the disconnect happened it continued through the use of anything over the IAC buss going into Live. But if I did the same setup with Reaper everything worked fine. And it worked fine without having to reboot. But as you mentioned in your post I would have to reboot to get Live to work again.

With that said I can say that I have not had another issue for quite some time. However, I have not used Glitch Sequencer in quite some time as well. That incident happened in May 2011. Ableton's support was timely and they tried to help but couldn't reproduce the issue. I didn't bug the dev of Glitch Sequencer because I was really using the app to help learn how to program Processing and it didn't cause issues with other hosts (I use Studio One as well).

One question I have for you though... Do you cold boot your system each time you use it? I usually put mine to sleep and it seems as though that each time that I have had any midi issues it has been after waking the system from it's nap. IOW, I almost never have a midi issue after I have done a cold boot. May be just a coincidence but it's true.

[agent well]

One question I have for you though... Do you cold boot your system each time you use it? I usually put mine to sleep and it seems as though that each time that I have had any midi issues it has been after waking the system from it's nap. IOW, I almost never have a midi issue after I have done a cold boot. May be just a coincidence but it's true.

As my mac has real difficulties restarting/turning on*, I as good as never cold boot.
Will watch out for this. Just not letting it sleep...

Thanks for your reply!

Cheers,
Jonas

*Which makes this bug even more a pain in the a** for me..,

[agent well]

I wish there was at least another way to restart the IAC bus!
By example by killing and restarting the right processes in terminal.
Like i said, killing MidiServer didn't do it for me..

[broc]

Does the disconnection happen after running the setup for some time, without changing anything?
If so, I'd suspect the problem is caused by your midi messages (eg. missing note offs).

[agent well]

Does the disconnection happen after running the setup for some time, without changing anything?
If so, I'd suspect the problem is caused by your midi messages (eg. missing note offs).

yes, it does.
will include note offs and continue to monitor the situation

[UncleAge]

I wish there was at least another way to restart the IAC bus!
By example by killing and restarting the right processes in terminal.
Like i said, killing MidiServer didn't do it for me..

Maybe my experience isn't exactly identical because the IAC buss was still working for me when I used it with Reaper and Studio One. It was only Live that had problems.

@broc: I've got a mini monitor program somewhere on this machine. I'm going to see if proper messages are getting communicated. Thanks for the tip...

[agent well]

Maybe my experience isn't exactly identical because the IAC buss was still working for me when I used it with Reaper and Studio One. It was only Live that had problems.

i tested it in audio-midi-setup, iac bus doesn't respond anymore.

also inserted midi offs in my code, didn't do it

maybe i'm sending note-ons/offs to fast consecutively.

well, up to another restart...

[broc]

Next I would look at the midi messages from Processing with a midi monitor like http://www.snoize.com/MIDIMonitor/

[agent well]

Maybe my experience isn't exactly identical because the IAC buss was still working for me when I used it with Reaper and Studio One. It was only Live that had problems.

I just tested with SimpleSynth.
While Live was not working correctly anymore, I could still strigger sounds in SimpleSynth over the IAC Bus.
(I guess Audio-Midi-Setup was not the right tool to test the working of the bus...)

Midi Monitor shows "*** ZERO ***" for the time field.
Maybe thats confusing Live.

[UncleAge]

Maybe my experience isn't exactly identical because the IAC buss was still working for me when I used it with Reaper and Studio One. It was only Live that had problems.

I just tested with SimpleSynth.
While Live was not working correctly anymore, I could still strigger sounds in SimpleSynth over the IAC Bus.
(I guess Audio-Midi-Setup was not the right tool to test the working of the bus...)

Midi Monitor shows "*** ZERO ***" for the time field.
Maybe thats confusing Live.

So do you think the glitch is in the java midibus app?

[broc]

Apparently midibus doesn't send proper timestamps as required for Live's midi input handling.

It's explained in the Live manual, chapter 'midi fact sheet'.

PS. I'd suggest to contact the author of midibus for clarification.

[8O]

Hi guys, so I've just come across the same issue... been testing a Pure Data patch (on behalf of a Windows user) on my Mac via IAC and sending Note On kills all MIDI note input in Live (including the computer keyboard MIDI).

Thanks, Broc, for the tip - I looked in the Live manual and found:

To solve this problem, the interface drivers give each MIDI event a timestamp as they receive it, and those are passed to Live along with the event so that Live knows exactly when the events should be added to the clip.

Even within the computer, the accuracy of timestamps can vary widely, depending on the quality of the MIDI hardware, errors in driver programming, etc. Live must assume that any timestamps attached to incoming MIDI events are accurate, and that outgoing events will be dealt with appropriately by any external hardware. But both situations are impossible for Live to verify.

...which doesn't cover the case that I'm seeing in Pure Data -> IAC, where the timestamp is just missing:



...from the manual, I'd expect Live's timing to be wonky in this case, but not for all other incoming MIDI to be ignored.

Feels like Pure Data -> IAC is unclean, but Live's handling is not robust...

Anyway... will test with other hosts/synths and also compare without IAC (MidiYoke) on a Windows machine later this week...

If anyone has other ideas to try out, gratefully appreciated... cheers...

[UncleAge]

I wouldn't expect that data stream to work without time stamps either. The part I don't understand is that why wouldn't these situations come up during alpha testing or some sort of regression testing a long time ago? The data stream may be corrupt but one would think that the Ableton programmers would have guarded the program from erroneous raw input data. It is a "Live" app, no? I mean if the program must kill the bad midi port then, ok. Why kill all of them?

[Asunderer]

Hi everybody,

I've been developing a sequencer application on the Mac in C++ using Core MIDI. I had the same problem where Ableton Live would start ignoring messages on the IAC bus after a while. Other applications would continue to handle the messages correctly. Only a system restart seemed to fix it.

I was creating MIDI packets and sending them out with a timestamp of 0, which supposedly means "play now" according to the CoreAudio documentation and examples. Nonetheless, using the "MIDI Monitor" app, all of the traffic I observed from devices and programs had an explicit timestamp, except for my messages, which showed up conspicuously with the "****ZERO****" stamp.

Adding the timestamp to the messages fixed the problem! I have not had any issues with the bus since, and Live even recovered without a system restart that first time.

I'm guessing that many MIDI generating suites don't provide the timestamp-- e.g. Processing and PyGame. I'm not sure what the solution would be except for maybe requesting or submitting patches for the associated Libraries. I think I read that somebody had had success by adding a miniscule 'delay' parameter in PyGame, which would cause the library to set an explicit timestamp on system MIDI packets. A hacky workaround would be to route the MIDI bus to an intermediate program that echoes the MIDI packets to another IAC bus but adds timestamps.


Here's some example C++ MacOS X CoreMIDI code to set the timestamp correctly. I'd expect that Windows has something analogous:

Code: Select all

MIDIPacketList packetList;
MIDIPacket * pPacket = &pList->packetList[0];
// Craft a packet:
pPacket->timestamp = AudioGetCurrentHostTime();   // This is the time that CoreMIDI hardware drivers, etc stamp MIDI messages with
pPacket->data[0] = 0x90;  // cmd byte
pPacket->data[1] = 0x00;  // etc...
pPacket->data[2] = 0x01;
pPacket->length = 3;
pList->numPackets = 1;
// Send the packet list (containing one packet)
MIDISend(outMidiPort, outMidiDestination, &packetList);  // Assuming port & destination objects exist, etc.

I hope this helps somebody-- I don't think I would have suspected the timestamp unless I'd found this thread, so thank you everybody