Help porting some software I wrote into Live / M4L

[mzero]

Before I was using Live I wrote my own percussion step sequencer: It uses a Launchpad as an interface and generates MIDI out.
I'd like to re-write this and bring it into Live. My aim is to have close integration. For example, rather than it's own pattern storage, it should just use clips.

What I need help with is which path to go down, as there seem to many:

• Pure M4L device. Given the others I see on the Max4Live site, I'm guessing this is doable, though it isn't clear to me that there are objects that will let me read/write clip data. (Somehow I'm failing to find doc of all the Live objects in Max... is there an on-line guide?) - Downside is that for things like modal UIs, I'm guessing patches are going to be horribly complex.... and I'm a programmer by day, so...
• M4L device, with much logic written as a Java element? Or JavaScript? M4L seems to support both - but again, I haven't found what Live interfaces exists from within each of those two languages. Is one better or more complete than the other?
• M4L device, with external code (in C, C++, or hey, even Haskell) - I'm guessing there are no APIs into Live from code compiled and included like this, so I'm guessing this way would be quite painful, having to wrap all interaction with Live in some custom protocol to my compiled code.
• Skip M4L, and just write a Remote Script. This isn't perhaps as flexible, and again, the APIs from Remote Scripts into Live don't seem to be obviously public - but I suppose I could reverse engineer them...

Can anyone help shed some light on which path might work, and where I can get a sense of the Live integration APIs available?

[S4racen]

Hi Mzero....

If you need the API details they are all written in whats called the Live Object Model which is found on the cycling website or in the help files within maxforlive...

Cheers
D

[Angstrom]

there is an example in M4L building tools called "clip operations" which will might be of interest. But personally I don't like programming with boxes when it comes to handling, querying, filtering data. A lot of people like it, but I find it more complex than simply looking at the text/code/script.

So, I prefer the JS LiveAPI strategy as it makes a LOT more sense to my way of thinking:

This is what you want:
https://compusition.com/writings/js-liv ... ps-reading

Example:

Code: Select all

var path = "live_set view highlighted_clip_slot clip";
var liveObject = new LiveAPI(path);
log("path:", liveObject.path);
log("notes:", liveObject.call("get_notes", 0, 0, 256, 128));

The boxes and wires approach seems daft for coding to me. Compare those few lines of script to this image, and
perhaps it's just me but this seems like confusing overkill.


BTW - in the bit in that article where he says "lets paste in our log() function", I don't know why he says that. You can just do this instead.

Code: Select all

include('ang-jsmax-utils.js');//or whatever your utils lib is called.

[19oclock]

Totally agree. The whole pipes and balloons thing is a way to maybe test a basic concept, but if we're dealing with real coding then let's code for real.

[mzero]

Thanks - this is the kind of input I was looking for.
Still welcoming other people experiences!

I agree, for many things, text code in an imperative language is going to be much easier. (Of course, I'm a software engineer by day, so I might be biased by what I know well.)

When something needs lots of real time input streams, and the flow is largely functional (the outputs is a continual transformation of the inputs) then I can see the box-n-wires approach. So building instruments and audio patches controlled by signals makes sense to me to do in Max.

But, programming control surfaces feels awkward, especially when the interface into Live is very much imperative and procedural. (That is, had Live been presented into Max as a series of continual signals, like "this outlet has the currently selected clips notes on it", then perhaps this would have all been easier!)

[19oclock]

But, programming control surfaces feels awkward...

That is my opinion, too. When I first started using Live for DJing I purchased a commercial template from Isotonik, but it was pretty terrible and crashed a bunch. I just don't think that pure M4L scales well beyond a small devices, so offloading things into the realm of Java seems like the best route to take. I've had wayyyyy better success that way and enjoy benefits of proper typed code including scaling, porting, and of course maintenance is a breeze. Keeping track of walls of wires and boxes would be horrendous.

[S4racen]

Anything timing reliant is better off in the max world than JS....

Cheers
D

[carrieres]

there is an example in M4L building tools called "clip operations" which will might be of interest. But personally I don't like programming with boxes when it comes to handling, querying, filtering data. A lot of people like it, but I find it more complex than simply looking at the text/code/script.

So, I prefer the JS LiveAPI strategy as it makes a LOT more sense to my way of thinking:

This is what you want:
https://compusition.com/writings/js-liv ... ps-reading

awesome link thank you !

[19oclock]

Anything timing reliant is better off in the max world than JS....

Where are you running into trouble with this? I've had nothing but luck monitoring metro object outputs in Java.

[Angstrom]

Anything timing reliant is better off in the max world than JS....

Cheers
D

you are right there if you are thinking of triggering notes directly out of the the midi output, that's falls down hard.
but when it comes to doing sequency things I think it's a better idea to use Live's midi clip functions for the important sequencing timing
The complicated logic can be better handled by Javascript, and the timing will be done better by Live.

[S4racen]

you are right there if you are thinking of triggering notes directly out of the the midi output, that's falls down hard.
but when it comes to doing sequency things I think it's a better idea to use Live's midi clip functions for the important sequencing timing
The complicated logic can be better handled by Javascript, and the timing will be done better by Live.

This!

Cheers
D