This page is only visible to admin users. Sorry!

This page is only visible to signed in users.

Contact <link>support@cycling74.com</link> if you believe you're seeing this page in error.

You don't have permission to view this page.

Activity

Billing History for { name }

Licenses

There was a problem removing the addon. Please try again.

Are you sure you would like to remove the <name>{addonName}</name> addon from your Max subscription? Your {addonName} addon license will remain active until the end of your current billing cycle.

{name} was successfully removed from your Max subscription.

Remove Addon

There was a problem resuming your subscription. Please try again.

Are you sure you would like to resume <name>{addonName}</name>? Your billing cycle will be reactivated and you will be billed as normal on {renewalDate}.

Your subscription has been successfully resumed.

Resume Subscription

There was a problem cancelling your subscription.

Are you sure you would like to cancel <name>{licenseName}</name>? Your license will remain active until <expiry>{expiryDate}</expiry>, at which point your subscription will expire and the license will be deactivated.

Your subscription has been successfully canceled.

Cancel Subscription

Next, start up the Max application and sign into your account (Help > User Account and Licenses).

Max has been successfully activated.

You must be signed into your account to activate Max.

Activate Max

Create a New Post

Edit Article

The list of what we're discovering about Max and our users grows each day. We tackle everything from hardware reviews to re-reading books from decades past.

Get the Latest on Max and our Community

Articles

Sign Out

Sign in to authorize License

Authorize Max

Filter by Format

Filter by Language

Find books related to learning Max.

Books About Max

Here are the artists and educators helping people get creative in Max

Meet Our Max Certified Trainers

Certified Trainers

{ firstName } { lastName } - Certified Trainer

There are no open positions at this time.

Please check your inbox for further instructions.

Forgot Password

Error

Success

Actions

Create Forum Topic

Edit Forum Topic

{category} Forum

There was an error submitting your details. Please try again.

Thank you for your submission! Someone will be in touch with you soon.

NFR / Industry Accomodations

Please make sure you use the link you received by email.

There was a problem retrieving your invitation.

Your account has been successfully created. To manage your institutional licenses, please go to <authLink>https://auth.cycling74.com</authLink> and sign in with your newly created account.

You must be signed out to view this page.

Create an Account

Find more details on our <link>Status Page</link>.

Under Maintenance

We are currently carrying out a scheduled maintenance of our website. Some functionality is temporarily unavailable. We appreciate your patience.

Name

Sort By

{ category } Packages

Share a Max Project

Edit Project

Image Notes

Important Notes

Max Projects come in all shapes and forms. Over the years, our users have shared over a thousand ideas and projects with us. We're proud to showcase them here.

Find Inspiration from other Max Users

Cycling '74 will review it within a week and may make minor edits before publishing it, so your project looks best and reads well in our project gallery.

Thank you for your submission! Your project is currently pending.

Account Recovery

Bundled

{ name } { version } Release Notes

There was a problem changing your password. Please try again.

You can now <link>log in</link> with your updated credentials.

Your password was changed successfully.

Reset Password

Your purchase has now been linked to this account. Next, start up the Max application and sign into your account (Help > User Account and Licenses).

Retrieve License

Type

Search the Cycling '74 forums and website

Search {query}

Please enter your educational details

Your Max for Live or Live Suite serial number is required for this purchase. <link>Need help finding your serial number?</link>

There was a problem updating your subscription. Please try again, or contact support@cycling74.com if the problem persists.

Cannot add RNBO

Confirm Subscription Addon

Thank you for your purchase

Thank you

Retrieving your order details, please wait...

Contact <link>support@cycling74.com</link> if you have questions/issues.

Couldn't sign in. Please check that your username/email and password are correct.

Sign in with your Cycling '74 account

There was a problem creating an account. Please try again.

Successfully created your user account! Please check your email for one last verification step.

Create a Cycling '74 account

Select a Product

Thank you! Your request has been successfully submitted to our support team. Please check your email.

There was an error sending your application. Please try again.

There was an error sending your request. Please try again.

By submitting this iLok request, you understand that you will be notified when an asset is deposited to your iLok.com account. After receiving that notification, you can transfer the asset to your iLok USB stick. Please be aware that all iLok requests are manually processed so it can take up to 48 hours to fulfill your request during normal business hours (Monday-Friday, 9am-5pm Pacific Time).

Important Information

Thank you! Your request has been successfully submitted.

Please note that we are no longer taking submissions for Tools and no longer supporting the Tools section, so you may run into broken files and URLs. You can contribute to the Cycling '74 Community by submitting a Package or using the forums instead.

Max Tools Archive

Edit Tutorial

Tutorials are an ideal way to accomplish a task, learn a new strategy or brush up on your skills. In addition to our in-app Examples, Tutorials and Help Files, you can find new ones here.

Explore the Online Tutorials

Tutorials

Thank you. Please start Max and sign in to use your license

Upgrade

Sign In

Your account requires verification. Please check your inbox, or <link>click here to send the verification email again</link> if you didn't receive it.

Unverified Account

Do you have an activation code?

Already own Max 8 and ready to authorize?

Trouble? Please email <link>support@cycling74.com</link> for help.

If you're new to Max, this is just for you.

Thanks for verifying your account!

You're one step closer to being part of the Cycling '74 Community.

Verify Your Cycling '74 Account

Failed to request a new verification e-mail: {message}

A verification email has been sent to { email }. Please check your inbox.

Can't find your verification e-mail or only have an expired one?

There was a problem verifying your email change. Please try again.

There was an error verifying your email address.

Your email address has been successfully verified. Thank you!

Verify Your Email Address

A user token is required to verify your email address. Please follow the link you received via email.

Tom Auger

Hey folks, I've been at it 4 hours and it's time to ask for help.

The patch below is behaving (to me) strangely. The intent is to find a Looper device on the same track as this patch. I was using class_display_name but for debugging purposes just switched it to "name" and that has shown me that my "loop" isn't working as intended.

Here's a quick visual of the patch and here's the debug output:

The weird part is that I actually had this working, and then I faffed about and now it's no longer working.

What I'm seeing is that it's listing all 3 device IDs and then listing 3 (of the same) device names. In the past it would list: device ID THEN device name and then the next device ID and so on.

I'm missing something about program flow or it's late and I'm missing something obvious.

Can you help me find the flaw in my logic?

Hey folks, I've been at it 4 hours and it's time to ask for help.

The patch below is behaving (to me) strangely. The intent is to find a...

inconsistent-liveobserver-liveobject-behaviour

Inconsistent live.observer / live.object behaviour

Pipotron4000

I got a padkontrol and i used personnal Mackie and Tranzport emulation, added Bome midi translator to get even more controls (like cycling through the folders in Browser view,very cool and simple :D)

But now i'm bored with such a mess...too much things at the same time

Two ways for me now, at least to eliminate emulations :

-make my own controller python script , like Korg should have done :D , based on nanokontrol Myr or the FCB1010 looper scripts : they work on AL8 (python version changed on AL8), so i just need to add some old decompiled python from other controllers scripts ;)

-use M4L, with python or regular patches, to access the same API

-can i do the same things with API in M4L than with controller python scripts ?

Are the objets,method... exactly the same, so i can integrate controller python scripts directly inside M4L, with minimal recoding ?

May be the question is already asked thousand times, but i can't access the Search function here : every time i click on Search, it disapear (old IE6 crap at job ;)

Two ways for me now, at least to eliminate emulations : 

-make my own controller python script , like Korg should have done :D , based on nanokontrol Myr or the FCB1010 looper scripts : they work on AL8 (python version changed on AL8), so i just need to add some old decompiled python from other controllers scripts ;)
OR
-use M4L, with python or regular patches, to access the same API

-can i do the same things with API in M4L than with controller python scripts ?
Are the objets,method... exactly the same, so i can integrate controller python scripts directly inside M4L, with minimal recoding ? 

controller-python-script-or-m4l

Before MFL was released I tried to control Ableton Live through the Python interface of LiveAPI. This works! In fact the LiveAPI in MFL is at best a wrapper around the Python interface.

I'm working on Windows XP. When there is a syntax error in the Python script Ableton Live crashes. In my case the resources for ASIO are not freed and and my PC has to be rebooted in order to use ASIO again. 

I installed Iron Python on Visual Studio. That helped me to discover syntax errors before compiling with Python. But every development loop required me to restart Ableton Live. Tedious and very time consuming.

The LiveAPI is still not officially documented. There are small differences from one minor update of Live to the other. For instance some boolean value has changed for true/false to 1/0 (or the other way around) without any notification. The parent property was silently introduced recently to facilitate the workings of MFL.

Debugging is close to none-existend in this Python environment. You have to setup your own try/except structures and create a way to communicate debugging messages. I have used a UDP-stream with an external console for this.

This means that the Python interface is hard to work with and errorprone at best.

After licencing MFL I have created a very straightforward Pythonscript for my Novation Nocturn. All it does is forward Midi CC's to a MFL device and echo the changes from MFL back to the led's around the knobs and in the buttons.

From this patch I can do anything I want with the CC Changes using the real-time programming possibilities of MFL. No crashes, only messages to the main MAX window.

After struggling with Python this sure is a relief!


I used python backdoor since 2 years.
with m4L, all became official/supported etc.

I was afraid to loose some access to API (like non implemented objects, functions...)

That's clear, the big advantage with M4L is support !!!
When Ableton change the API, python version... they tell nobody
And some things stop working (like the LockButton in generic midi remote in AL8, solved now)

Now with MFL, they are obliged to tell at least cycling74 ;)

And debugging/crashing is another very good reason :  i want to make music, not spend hours of debugging, crashing/restarting :D

You convinced me with your experiences and arguments ;)


in 2008 june, I had the chance to meet Gerhard B (Ableton CEO) & Robert Henke in France (a little workshop around Ableton Live before a monolake performance)
We discussed about python API. At this time, they couldn't tell me anything about max for live (announced in 2009 january) but they just told me that:
"it works with the current version. if you want to build things, go. But we cannot assure you we'll support this in the future" ... They convinced me at this time :)

"And debugging/crashing is another very good reason : i want to make music, not spend hours of debugging, crashing/restarting :D"
I agree 200% !

If you're interested in API/interface/hardware, you can check my page: http://www.julienbayle.net/diy/protodeck/

and especially this part : http://www.julienbayle.net/diy/protodeck/#m4L
unfinished yet, but I will!

"I was afraid to loose some access to API (like non implemented objects, functions...)"

I'm not sure each and every feature of Python can be accessed from MFL's Live Object Model.

If you really need access to a property or function that is not supported in the LOM you can always write a Python script for UDP or OSC. 

One more reason in favor of MFL is latency. The Python LiveAPI lives at a clock with 10 or 12 clocks per second. You must defeat latency to make this to good use. 

I have not done extensive explorations, but some simple tests show that the MFL timepoint bangs within 10ms of the specified time-point. I expect that experienced Max/MSP users can teach us ways to do even better.


Reviving this old thread (awesome by the way)... So if m4l is a wrapper for the python live api, how can it beat the latency issues of python?  i ask because I'm wondering if m4l is able to do anything that the python api cannot in terms of access to live functionality.

It would be cool if you could make controller scripts using m4l.  I like not having to drop an m4l in a set to be able to use my interface.  A plus i see with with the python api is you dont have to own suite in live 9 to be able to use it.  if i make some controller interface i want everyone to be able to use it.  I don't know if theres another workaround for this...


A good number of latency limitations that plague this sort of thing aren't inherent in m4l or Python:  they are due Live itself.  The thread process used for Python is locked at a minimum of 60ms latency or more, and there are certain ways to get things done faster than that in your Python routines, but that doesn't speed up Live's interaction with Python any (for instance, even if you poll the position of a clip at faster increments, Live's engine only updates the pointer to that position every 60ms).

M4L can do lots of things that the Python API can't do simply because it provides more tools, and has a faster timing mechanism.  But it still contains the same limitations for interacting with Live (with the exception of the [live.remote~] object, which can be used at audio vector rate) as do any of the native Python processes for the most part. In m4l, there is additional latency induced by having to pass through an extra layer to get to the same processes.

m4l (C) -> Python -> Live(C) -> Python -> m4l(C), with the introduction of an extra step to get to javasript at each end if you do things like I do and use js for the API interaction:

--Even though you can do things faster in Max than Python (regarding latency), getting to Live via m4l is slower because it has to pass through several translation layers.

--Less overhead is required for processing events, since there's no extra layer(s) to go through.  In addition, MIDI assignments can be made directly through Live to their intended targets, without the need for extra processing time to be taken by going through the MxDCore layer and Max's own machinations.

Making calls to Python can be generated faster than the 60ms update barrier, and they are processed as they are received.  There's just (currently) not a way to spawn a thread in Live's Python and have it run any faster than 60ms without prompting from some external call.  I'm working on that bit right now, actually.....

As far as I can tell, all m4l activity (except for [live.remote~]...I haven't investigated its mechanism at all) is handled by a single MxDCore instance.  Presumably (pure speculation on my part), all Python activity is limited to a single thread.

What does all this MEAN?!  Well, I tend to think it is faster and more efficient to include as much API interaction as possible in a Python script, and then do the things that are not possible with it (or are not timing sensitive) in m4l.  This works well, but requires a certain amount of "hacking" to get things to work.  If there were a reliable means to script all of the stuff I do directly from Max, I might consider it....but, in the end, Python is generally faster and more efficient.

Thanks heaps for that extensive breakdown.
this begs my next important question, because m4l is only available with suite now from live 9 onwards, perhaps we are better off with python anyway and dodging m4l so more users can utilise what we build using max runtimes and such.

Apart from live.remote~ which is an important one-
Is there no equivalent in the python api for this?  id love to know how it does its magic!  maybe its jumping the python step and going straight from m4l into LiveC

On another note, can live.remote~ be recorded into automation?  I'm guessing note since it disables the parameter in lives interface.


Another question, if an mpc uses the same python controller scripts by default with midi, how come it doesn't have these latency call problems?  Im pretty sure if i press a midi note on a controller it doesn't suffer from large latencies.  thanks again guys.


Apart from live.remote~ which is an important one-
Is there no equivalent in the python api for this? id love to know how it does its magic! maybe its jumping the python step and going straight from m4l into LiveC

No.  That doesn't enter Python, as far as I can tell.  Abe's wrote some hooks (or, more likely, exposed existing ones to the Max extension) that are accessed directly for this.

On another note, can live.remote~ be recorded into automation? I'm guessing note since it disables the parameter in lives interface.

I'll leave that one for someone else...I honestly don't use [live.remote~].....ever. Functionality vs. performance hit has never been a fair trade off for my work, which usually sees my LiveCPU @ 40%+  the way things are without it ;)

Another question, if an mpc uses the same python controller scripts by default with midi, how come it doesn't have these latency call problems? Im pretty sure if i press a midi note on a controller it doesn't suffer from large latencies. thanks again guys.

Yeah, there's an important concept to grasp at the center of that:  a great deal of the Python _Framework implementation is built around forwarding commands to Live.  So, for instance, if I want to map a CC to a parameter, I send c_instance Live a message and tell it to assign CC#blah to live.parameter['blahblah'].  Live does all the work after that, and Python doesn't see any of the interaction, unless we explicitly forward the CC# back to Python by telling it we want a callback.  

In that example, the CC# going out to the control is going to be updated without the 60ms latency limitation.  However, if we are forwarding the data to Python and then doing something with it, we get the latency.

So, for MIDI Mapping purposes, things are pretty fast.  But for scripted functionality, things aren't so much.

Another note:  sending MIDI in and having the script process it takes more time than sending the script a message, say, from an m4l object, and telling it to send MIDI out.  This seems to be instantaneous, and I've have faster results sending MIDI loopback through an IAC bus from LivePy than I going from track to track in Live.  (Figure that one out??!)

On the other hand, I might just be crazy.


Max For Live Forum