Cross-Platform Max For Live SysEx (and unrestricted MIDI in/out) Externals

    Mar 08 2016 | 8:00 pm
    These objects are a re-implementation of the standard Max MIDI objects using a cross-platform MIDI library (RtMidi). This means that you can use them in Max For Live devices to access the system MIDI ports in an unrestricted way. And.... you can get SysEx!
    Only caveat is that on Windows, you have to disable any MIDI input/output port you want to use. If Ableton is trying to use the port at the same time the objects can't connect to it. For this reason, I've added a status outlet to each object to indicate whether the port connection was successful or not. Other than this extra feature, the objects are feature-clones of the originals.
    Oh, also the double-click port menu is only implemented on Windows because I genuinely can't work out how to create a pop-up menu on OS X from a cpp project. Anyone have any ideas?
    Download below:

    • Mar 09 2016 | 3:43 pm
      Awesome - thanks David!
    • Mar 12 2016 | 12:25 pm
      Excellent work I like the status feature! is it possible to add another extra to compliment this:
      "port none"
      This could also trigger status 0
      As I cannot see a practical reliable way of deselecting ports on different systems. (dummy ports is a extra hassle solution)
      W10 Max 7.2.1 32 bit Max Working 64 bit Max Crashes
    • Mar 14 2016 | 1:01 pm
      Hey David, great work! I've been waiting for a cross platform version of lh_midi for years, if its reliable this is going to open up sysex communication for alot of m4l users.
    • Mar 14 2016 | 1:06 pm
      @MR-BIT Port de-selection is a good idea, I'll add it in the next release. Regarding your 64-bit crash, which OS are you running?
    • Mar 15 2016 | 11:16 am
      Nice one David! I'm running Windows 10 Pro build 10586.164 64bit
      Not sure if this log info helps:
      Problem signature: P1: Max.exe P2: P3: 56e0a771 P4: imp.midiinfo.mxe64 P5: P6: 56df00b8 P7: c000001d P8: 000000000000e095
      Last part of the WER file:
      LoadedModule[174]=F:\Max 7\Externals\imp.midi_v1_0\imp.midiinfo.mxe64 LoadedModule[175]=C:\WINDOWS\SYSTEM32\dbgcore.DLL State[0].Key=Transport.DoneStage1 State[0].Value=1 FriendlyEventName=Stopped working ConsentKey=APPCRASH AppName=Max (64-bit) AppPath=C:\Program Files\Cycling '74\Max 7\Max.exe NsPartner=windows NsGroup=windows8
      If you need any specific info let me know and i will try and dig it up.
    • Mar 19 2016 | 8:36 pm
      I don't seem to ba able to receive any sysex using imp.midiin. Other MIDI message are received normally
      OS X 10.9.5
    • Mar 19 2016 | 8:48 pm
      You need to use imp.sysexin to receive sysex, just like the standard max objects.
    • Mar 20 2016 | 1:24 am
      Aha...awesome, this handles sysex more reliably than lh_midi so far..
    • Mar 31 2016 | 6:57 pm
      Thank you!
    • Apr 01 2016 | 9:58 pm
      Hi David,
      I am trying to get a bang in a Max Midi Effect M4l device from the Push 2 controller when it is turned on. With the imp.sysexin it only works it works when the Push 2 is loaded before you drop a device in a track and then you turn it off and on again. But when I turn the Push 2 on with the m4l device already inserted in a midi track it doesn't get the port. Any idea why?
      FYI: Max7 64bit OSX 10.11.3
    • Jul 07 2016 | 2:46 pm
      Hi David, thank you for these wonderful tools — been waiting for 64bit support!
      There seem to be problems however with the data imp.midiout sends into the MIDI environment. What happens is that it integrates previous successful data in the current chain of MIDI events, that being said, only grouped MIDI events (i.e. 179 10 77) seem to be transmitted successfully, though not always (e.g. 179 10 $1 in a message box does NOT work). if I successfully send out CC 10 77 on Channel 4 as a grouped chain from a message box (179 10 77) and then via midiformat CC 10 78 I get "179 10 77 10 78", which is basically the previous event plus the intended data as invalid bytes without the channel (see attached picture).
      I am a bit cluesless as to what I else I should try — hopefully you can help!
      I am on Mac OSX 10.8.5, Ableton Live 9.6 @64Bit
      Thanks much! shgn
    • Jul 25 2016 | 1:27 am
      Thanks for spotting this. I will take a look at the bug next time I have opportunity, it would be really helpful/save me a lot of time if you could post a patcher which reproduces and demonstrates this problem for me to test against.
    • Jul 29 2016 | 11:44 am
      okay, here is an .axmd-file demonstrating the bug in my case, plus the code.
    • Nov 01 2016 | 12:26 pm
      Great stuff David - thanks for sharing this.
      One observation - on OS X the object doesn't seem to be able to connect to the Lemur Midi Daemon - I suspect because it is a virtual port?
      Happy to help in any way if i can.
    • Jan 10 2017 | 9:27 pm
      Hi David, thanks for this work. I'm pretty new to M4L and I'm hoping you could help me with a logic problem. I'm using your externals in a device controlled by Push 2, in the native live mode, not user mode. Since the native Push 2 remote script is running, certain CCs don't make it into an M4L device just using midiin, hence my use of imp.midiin. I've got control of the appropriate port and the messages are flowing fine. However, I want my device to only process through imp.midiin when the track that the device resides on is selected and armed. Right now, midi flows to imp.midiin regardless of what track is selected (obviously, because the data comes directly from the port). This causes problems because parameters are changing in the M4Ldevice even when I'm working in a totally different track. Any thoughts?
    • Sep 14 2017 | 1:20 pm
      Hi everyone, when calling the imp objects, I get "Error 193 loading external imp.midiin".
      I put the objects into my Max externals folder.
      Any idea, how to solve this?