Cross-Platform Max For Live SysEx (and unrestricted MIDI in/out) Externals
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:
Awesome - thanks David!
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
Cheers
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.
@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?
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: 7.2.1.28222
P3: 56e0a771
P4: imp.midiinfo.mxe64
P5: 0.0.0.0
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.
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
You need to use imp.sysexin to receive sysex, just like the standard max objects.
Aha...awesome, this handles sysex more reliably than lh_midi so far..
Thank you!
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
Thanks
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
@shgn
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.
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.
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?
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?
Hello David,
Congratulations for your great work ! 👍
I have a question concerning the native Max sysexin object, maybe you can help me solve a strange problem with a Max for Live device I'm currently developing. It seems there is a bug (or a limitation ?) with the native sysexin object, but only at runtime... Let me explain :
I use sysexin to receive programs from my hardware reverb unit (an Alesis QuadraVerb Plus). When I load one program, I get 155 bytes of data, which is fine. When I load 100 programs at once (with a special QuadraVerb sysex command), I expect to get 14708 bytes of data. This is exactly what I get when I run my device in Max editor and my device works fine. But when I test my device at runtime in Ableton Live, I only get 3072 bytes of data and my device stops to work (I try to detect final F7 byte, which is never received). This strange behavior is perfectly reproducible as I always receive a truncated sysex data of 3072 bytes at runtime.
I have done some tests with a very simple patcher and sysex data files I have built from my QuadraVerb, respectively containing 3071, 3072 and 3073 bytes (always terminated with a F7 byte). The first two data files (3071 and 3072 bytes) are received correctly even at runtime, but the last one (3073 bytes) is indeed truncated at runtime only (I don't receive the final F7 byte).
Have you ever encountered such a problem or limitation with the native sysexin object ? I can't find any infos on this which is very frustrating. I have posted a topic on C74's forum but I don't have any answer from the community :
https://cycling74.com/forums/issue-with-sysexin-object-only-at-runtime
Thank you in advance if you can help a bit ! :)
All the best from France.
Guillaume
My Dev Setup
• MacBook Pro Mid 2014 / i7 / RAM 16 GB / SSD 500 GB
• macOS High Sierra 10.13.6
• Ableton Live 10 Suite (EDU) 10.1.9
• Max 8.1.1 (Max for Live licence)
• MIDI Monitor 1.4
• SysEx Librarian 1.4
• Hex Fiend 2.8
• TextMate 2.0.6
Hi David
The [imp.midiin] object doesn't seem to work with [xctlin]
Is there a workaround for this or is this just a limitation of the object?
The specific use problem I'm working on is trying to receive 14-bit CC data from multiple MIDI channels into one M4L device?
Connecting the [xctlin] object doesn't work in the same way as with [midiin]
