Hi all.
I am pleased to have finished my first pair of max externals, specifically designed for use within max4live, . This is no 'ready made' live device, these are only max objects which, if you take a look at the help patches, will enable you to build max4live devices with full access to sending and receiving midi events - notes/cc/program change/channel aftertouch/poly aftertouch/pitchbend and sysex from outside of Live, and without channel restrictions. These objects can equally be used in maxmsp, but differ only slightly from maxmsp's midiin and midiout objects.
Unfortunately for you windows users, these are mac only, and I have no plans to delve into windows midi frameworks, sorry. For windows developers, any source code would be of limited use as generally the code is quite simple. The head scratchy bit was doing all the coremidi integration... especially as I'd never looked at mac os frameworks before a couple of weeks ago.
Feedback is most certainly welcome on useability, robustness and feature requests.
I'm also interested as to how anyone might end up using these in their max4live devices, if indeed you do.

@broc - I'll get the send/receives tidied up early next week all being well and you can give them a good old run for their money! hehe!
@bulo - We'll have no talk of devils here Sir... Diddy metal!
@ amounra93 and Bjorn - Thanks very much for your input.
@ flowdesigner - sorry, I was so busy doing these, I didn't have the headspace to deal with too many betatesters!
Enjoy xx

Yay! I think a number of users are going to be pretty happy about Leigh's new externals....I've been testing them for a little while, and everything seems to work well....for those of you that were participating in the other threads about this, here's your (mac only) solution.

I'm going to drop this thing into Monomodular for the next revision. Very STOKED!

Thanks so much for making this wonderful tool, and for making it open source and free. You rock, you are my hero, and you definitely get a raise

NOW, who is going to make an implementation for Windows, so all those poor souls out there stuck in PC land have a solution as well?

leighhunt wrote:These objects can equally be used in maxmsp, but differ only slightly from maxmsp's midiin and midiout objects.

Can you please explain the differences (and reasons) in more detail?
Would it be possible for the user to build abstractions which are fully compatible with Max?

How about 1-byte real time messages like MIDI clock and MTC?
For example, I have a MTC generator built in Max.
Running it in M4L would turn Live into a MTC master (which currently is a missing feature).

3dot... wrote:umm.... we can do this already using osc..or through mxj...
what am I missing? (windows user)

Its a MIDI Driver inside a MFL device (like midiin in regular Max). No OSC/UDP converters needed. Since you can receive/send straight inside a device, Live's MIDI restrictions don't apply. No 3rd party apps and no virtual drivers required.

This is fantastic! By the looks of things I should be able to create a full editor for my Virus B. Of course I need to get my finger out and learn a bit more Max first but I have a really good reason now. Thanks!

+1 ... but it should outperform the osc option ...
(which isn't gonna be too hard I'm guessing)
did anyone try using the mxj to use Javas' Midi Library ?
I'm thinking this should work..
gonna try it out when I have the time..

leighhunt wrote:
Feedback is most certainly welcome on useability, robustness and feature requests.
I'm also interested as to how anyone might end up using these in their max4live devices, if indeed you do.

Hi,
Unfortunately I've been rather flat out gigging recently.
I have done some work on C4 integration, but it relies entirely on my own 'parameter' system, which involves a bunch of homemade 'parameter' externals and parsing externals.
This is partly because I don't wish to cloud my brain with the whole python scripting / control surface interfacing learning curve, and also because I already had a system working in MaxMSP which works roughly as follows;

'Parameter' externals hold a storage/recall value and also a 'post modulation' realtime value, so as not to have to update the C4 lcds when modulating from, for example, an lfo source (long sysex messages updating at a fast rate rather clogs up the midi output and slows C4 lcd updating).
What I did was, when a parameter is assigned modulation in a 'mod matrix', so to speak (source/destination/amount etc), the leftmost digit on the lcd for each encoder displays an 'm' so I know it is being modulated.

When saving presets of parameters the 'pre modulated' value is stored.
This method works nicely for my way of thinking... possibly not for others....

The 'parsing' externals (one for each C4 'layer') are constantly updated so that when changing layers on the C4, no conversion of parameter value to ascii to sysex is required. All layers are constantly updated and convert to the sysex messages as and when 'pre modulation' values are changed in the system, thus when changing layers the lcds update much quicker.

This works nicely with M4L devices I have built, and I am slowly building M4L devices (one per track), that observe Ableton devices and load premade 'parameter' external abstractions that convert the Ableton devices to integrate them with the whole system.

Reading this back I'm not sure how better to explain if it sounds somewhat convoluted! sorry.

I might try over the new year period to put together a simple example of the system, but eventually there will be
1 - separate, unique externals for every parameter type (unique integer and floats for each min,max combination/unique menu type parameters) - so quite alot!
2 - just the one 'parsing' external (one instance per C4 layer).
3 - A 'modulation' external for binding modulation sources to the parameter externals (one instance per modulation source/destination).

As you can see, this is a long way off the python scripting way of going about things, but I've put so much time into it so far, with pleasing results, that I am going to stick with it.

Hi!
Is there a chance to see something like a lh_ctrlin in the future?
To put it simple: I'm making a patch where the 8 knobs from my midi controller controls... 8 parameters. And I've noticed that, compared to ctrlin, using the CC informations that are coming from lh_midiin is not very reliable; i.e it has problems to correctly handle several differents CC that are transmitting informations simultaneously.