Limitations of M4L (e.g. rack access)

[Surreal]

i would like to request access to the 'red ring.' Every patch that navigates the session view could benefit. (Maybe that is the problem? the prospect of too many red rings?)

Please.

pretty please,

super double dog dare please.

if not, is there some crazy argument against i haven't thought of? cause i would be cool if i knew that the grass is not greener, i just swear my grass is not quite as green as it could be. (but, now it IS pretty damned green. thanks in part to pukunui's example network patch. Many thanks!)

[barstu]

Yeah, you're right, we need to deal with racks better in the API. I'll amend the tickets with this detail.

Thanks

-A

Hi Andrew does this mean we will see Rack device access in a future minor release of Ableton 8? This is currently the one thing stopping me buying the M4L add-on.

[skwosh]

Hi.

Yeah, you're right, we need to deal with racks better in the API. I'll amend the tickets with this detail.

Just wondering if the rack access thing has been resolved (#1 on the list), or whether it is likely to be resolved soon...

Cheers, Alex.

[ST8]

I did think of a list of api limitations but i cant remember them off the top of my head.

One i'd like is being able to access the clip/loop start and end points independantly. At the moment if the clip is looping you can only get the loop start / end, you have to toggle the loop off to get the clip start / end. This also means as long as a clip is looping you cant get a callback on the clip start / end

I think my main issue with m4l is still the speed of live.path, but im under the impression this is the way thats going to stay.

[docprosper]

Another big current limitation IMO is the lack of an ability to route audio via M4L between tracks. From a MSP perspective, M4L currently functions at the track level in a linear fashion. I think the ability to re-route audio globally would be a big M4L game changer, although I also concede that this could be a difficult task on the development side.
-Hamish

[Macrostructure]

I tried M4L a year ago, mostly for access to the API for making modules to assist with live performance - things to set, reset and modulate devices but more importantly the mixer.

It didn't work back then - the communication between the patch and the API seemed unreliable, possibly subject to some kind of bandwidth restriction. There seemed to be crosstalk between, for example, line objects talking to different id numbers at the same time.

M4L talking to the API a lot - eg LFOs on 8 sends at a time, caused frequent crashes in the development stage i.e. when the Max window and the Live window were both open. It was wildly frustrating and support were unable to help. I don't blame them as my patch was massive and, shall we say, rather organic - although ultimately correct layout-wise


I got quite a long way with patches but gave up in the end as good old fashioned MIDI loopback did the job better, more simply, with less overhead and more programmability.

I recently thought I would give it another go and have found everything much more stable, and some nice new workflow assists in the new Max, but ultimately access to the API is still pretty hard work. talking to the mixer using line objects and live.object to control smooth parameter changes is still erratic, in fact inconsistent - which surely is the worst of all worlds? the impression is still buggy, no, more clunky - like the programmes are actually quite hacked together and not properly integrated.

a small example - you can send a full scale deflection signal to an object in the API and it does not go to full scale, it stops a little bit short. grab it wit the mouse and you can move it right round. how is this a correct implementation? how can that be a marketable standard of product? As something fun, but sometimes frustrating, for coders (like me) to play around with - maybe, but I wouldn't perform live with a M4L device. I am sure many do though

So yeah, some sorting our of the API access would be cool.

I was also very disappointed to see the range of Live-specific devices people have made after 12 months. Hardly the vast deluge of quality amxds that one, and indeed Ableton in the M4L release video, expected. Some nice stuff for sure and respect due, but not what I was expecting to come back to. A sad indictment of the Max and Live API documentation i.m.ho. . Although I note some improvements over the original set, still some significant errors, eg duplication in the same html page, in there. I run a company and know what produces this kind of documentation error - time and budgetary restraints limiting quality control - it's not that they don't want to make it better, they just don't have the resources.

My own opinionated view is that Ableton might have done better investing money in a younger sister program, one that is easier to learn, and perhaps to programme, and grown together with it, rather than trying to get already-mature Max to work with Live. If they could have got Outsim's Synthmaker, for example, ported to Mac as well as PC, that might have yielded more user-friendly results in the long term. I know it lacks the Jitter type stuff etc just now but who knows?

[hoffman2k]

I recently thought I would give it another go and have found everything much more stable, and some nice new workflow assists in the new Max, but ultimately access to the API is still pretty hard work. talking to the mixer using line objects and live.object to control smooth parameter changes is still erratic, in fact inconsistent - which surely is the worst of all worlds?

Have you tried using live.remote~ (which also works on the Mixer) for achieving smooth automations?
Live.remote~ works at sampling rates.

[docprosper]

I was also very disappointed to see the range of Live-specific devices people have made after 12 months.

I agree with this to an extent but then again it's all what we make of it, right? I'm still optimistically hoping that the slow start is due more to a Max learning curve, with the assumption that most M4L users are Live users who adopted Max and not the other way around. Max/M4L certainly takes some time to learn properly, especially API-type stuff that uses complex structures (even I am only in the API-hacking phase...), and I'm still hoping there will be an explosion of growth in devices.

I also wish that posts on maxforlive.com were vetted in some way. I am more into making my own devices (and posting a some...) than into DL'ing them, but from other posts and some sniffing around M4L.com it seems like quality is a problem. A site with 50 good devices is far more valuable than one diluted with 70% buggy crap that dissuades growth, and the user/devel group is too small for the quality rating stuff to mean much as few use it. IMO.
-Hamish

[docprosper]

OK Shel, I'll concede this one to you, but I am always hopeful. I think an Ableton share utility wold certainly help matters, as it's not easy to share set-specific devices that require a complex set to be wrapped around them to function properly. As an example, I'm working on a DJing control device in M4L that requires ~20 tracks to function properly, with complex links between the device and the various tracks. I'd be more likely to share something like this if I could wrap it up with the entire set & post it all at once. Just sayin'
-Hamish

[pid]

yes, i agree. maxforlive.com will never grow beyond mediocrity unless it allows uploading of any size .zip files and .als files. not that allowing this would suddenly make its content all great though of course (!). but not allowing those is an inherent misunderstanding of what max and the power of max requires: libraries, not 'devices'.

in response to macrostructure, much of it i agree with. but i am a max user with live (for many years before the marriage) not the other way round, so maybe i am more forgiving. i actually think that max is potentially the best and greatest 'language' for ableton to team up with. and maybe even the best thing that ever happened to live, rather than the other way round. it will just take a while longer to perfect... in the meantime it is still shckingly useful and productive for me personally.

2c

[Pasha]

but you can't deny its easier to have a chain for each instrument rather than a track for each instrument.

Right.
However to overcome CPU Core limitation I often have to split Rack Chains into tracks:
Example:

A mammoth FX Rack with 4 chains takes 60 % Cpu while splitted into individual tracks takes less than 20%.
Live multicore kicks in to ease tracks load not racks (calculated in the same CPU thread I guess)...
Should ask Abes for multi-threaded multi-core dispatch of chains in racks too.

- Best
- Pasha

[Macrostructure]

I recently thought I would give it another go and have found everything much more stable, and some nice new workflow assists in the new Max, but ultimately access to the API is still pretty hard work. talking to the mixer using line objects and live.object to control smooth parameter changes is still erratic, in fact inconsistent - which surely is the worst of all worlds?

Have you tried using live.remote~ (which also works on the Mixer) for achieving smooth automations?
Live.remote~ works at sampling rates.

Yes. The problem with live.remote is that it does not write automation data/undo data. This makes it pretty useless for playing back your live performance's .als file or for use in the studio.

[Macrostructure]

But in the end I do think that Max is more about providing specific solutions for your own specific setup.

Agree

[JuanSOLO]

When looking at myself I too have dozens of patch snippets lying about which either make up an object/patch library or simply experimental stuff. Most of that is stuff which I don't really consider worthy to share.

Agreed. I think the onset of M4L and the majority of resulting patches at maxforlive.com were from users like myself who were displaying their learning progress. All of the patches I have posted there are abandoned ideas out of realizing better ways of doing things. Many of these "better" ideas are just work arounds to some of the M4L limitations/complications, or I just hit a brick wall and said fuck it.

For example I WAS trying to build my own drumRack, something simpler with specific functions related to controlling it in a live performance manner. Better send capabilities along with storing "presets" with clips, etc. This idea has turned into a complex Live Set, with small M4L devices here and there, specific track routing etc. Not something that would make any since posting over at maxforlive.com. And not something I feel even satisfied with YET.

In relation to the Reaktor user library, I imagine the percentage of GREAT things to download is about the same at maxforlive.com. This has to be a result of users being able to post as they learn.

I applaud anyone doing so. I wonder if those complaining about quality are with holding their skills, or just find the limitation/work arounds in M4L so personally specific that they dont bother to post, or maybe they just like to complain?

[docprosper]

All of the patches I have posted there are abandoned ideas out of realizing better ways of doing things. Many of these "better" ideas are just work arounds to some of the M4L limitations/complications, or I just hit a brick wall and said fuck it.

...maybe the problem here is that there are different perspectives on the proper use of the site. I feel snippets would be better posted in the forum and M4L.com should be reserved for more finalized, working devices; objects that could stand alone in someone else's set and function properly. I've only posted a few devices there but I've been pretty careful to properly test them first . The problem with this perspective is that snippets can get easily lost in the forum.

Perhaps maxforlive.com would be more functional if there was a 'snippet/unfinished/untested/etc' category?

I personally am not really bitching about device quality on the site but I've seen enough of the complaints. Some of the device descriptions are deplorable, practically admitting that the posted device is a buggy piece of trash capable of crashing your system. I tend to avoid these and have had decent luck with the ones I have DL'd.
-H