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.

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.

simple question : is midi the way to send data sequences using Live timeline via a M4L patch ?

Knowing that the data can be mqtt, artnet or other.

Hello,

simple question : is midi the way to send data sequences using Live timeline via a M4L patch ?

What is the common practice for...

data-sequencing

Data sequencing

broc

With recent tests I've noticed that the latency of send/receive seems related to Live's audio buffer size.

So in contrast to earlier versions, there is no jitter and the latency seems predictable to some degree.

Can this result be confirmed by the developers?

latency-of-sendreceive-predictable

I've repeated the test with another setup and this time found latency near 0!
Apparently it depend somehow on the setup, in short: the latency is basically *not* predictable.

The question remains if the *maximal* latency is predictable, ie. determined by the audio buffer.


hey broc, what was your setup for the second test? (sorry for quasi thread hijack).

p.s. - i want answers to all broc's questions too.


My second test was minimal.
No audio track, just 2 MIDI tracks with M4L MIDI effect on each for sending a bang and receiving it.
Time measurement with [cpuclock].

I guess the 0 latency was achieved because in this case both tracks did run on the same thread.
But the behavior may be difficult to reproduce depending on other unknown factors.

Are there any other info about send~ and receive~'s latency?

I just realized this latency by playing my double bass through Max and comparing with and without send~/receive~. The latency is pretty obvious to my ears without any measurement.
This is weird because I've been playing my bass through Max for 6 years and didn't really notice anything. I always have exactly the same settings that I loadbang. 

Does this latency adds up if I have several chains of send~/receive~?

There should be a mention about that somewhere in the help file, reference or tutorials.
Florent


I think send~ receive~ pair have a latency of 1 signal vector, so if you have a large vector and a signal going through a number of these pairs you'll get a noticeable latency

it is always one vector, but if it properly works in live is another question.


thanks guys,
Ok, so theoretically the latency is one vector, but in practice it is not. Am I correct?
Broc's tests above show that it is not predictable and consistent.
Why? What does it depend on?


It is one vector when the signal chain that ends in a send~ has somewhere a receive~


there were similar issues in pluggo with logic, it might be that in live it also makes a difference if you are having 2 devices in different channels or in the same. and as you already found out, the buffer size seems to matter. :)


Hey, sorry if my question sounds stupid, but what is the math to calculate the length of a vector?

For example, if my sample rate is 44.1Khz, my I/O vector size is 64 and my signal vector size is 64, what is the duration of my send~/receive~ latency?
Just trying to figure out if the latency I hear comes from those send~/receive~ pairs or from something else.
thanks
Florent


@broc::
i`ve done a lot of testing some time ago,to me send/reveive had a latency of exactly 30ms.
but maybe this imrpoved by now...
anyway, i started using udpsend/receive which also has unpredictable
latencies but far shorter ones.
another issue regarding m4l is that the entire API is NOT IN ANY WAY
timing-accurate,there`s lots of jitter all over the place with up to 30msec.
which is ,@florent ghys, when the human ear stars to recognize an echo.


thanks RBRT for the feedback
what buffer size did you use for this 30ms tests?


I have arrived to clear up some confusion! >;D

Broc's original post is about send/receive('s'/'r'), the non-signal versions(note the mention of measuring receipt of 'bang').
(When RBRT is addressing Broc, he is making a suggestion about udp offering better latency than the non-signal versions.)
When FlorentGhys rebumped this thread 3 years later, he's now talking about send~/receive~ pairs, the signal-version(where the vector size, as mentioned by others, comes into play).

FlorentGhys can ignore RBRT's findings if he is more interested the latency of the signal-versions.

(...in regular max/MSP, send~/receive~ only added vector of latency when placed in feedback loop, so the pluggo/m4l thing is likely a protection for plugin-style operation...)

I am done now. You may return to your regularly scheduled programming.


Thanks, this is a very good clarification and I apologize for the confusion.


@RBRT
In my experience the latency and jitter of send/receive vs. udpsend/receive are basically the same where the maximum depends on Live's audio buffer size. I can confirm the general inaccuracy of API, even up to 50ms.

Anyway, it's a shame that the diverse latency issues of M4L are not clearly explained in the documentation.


I USED TO BE RIGHT.NOW I M ALL WRONG.
i just did the latency-test again,with max 6.1.9 and live 9.1.5.
there is NO latency with send/receive from one M4L-device to the other anymore.seems someone has fixed this.
I ' m very very sure it used to be 30msec.maybe I should also check the LOM for latencies again..
bye bye udpsend, hello send/reveive.


Interesting. What was your setup for the latency test?
Did you try sender and receiver on the same track or different tracks?


hit hitme..i hope the rest is self-explanatory..


I tried your test (on Live8, Max5) and also got NO latency with send/receive.
Apparently the behaviour was changed already in earlier versions (see also my 2nd post on this thread).
But I still wonder if it's true for every possible configuration.

Any comment from the developers would be much appreciated.


What about sending signals between patches on the same track? Is there a way to compensate latency?
I tried sending from patch A to the immediately following patch B, and sending float has some latency, as well as sending audio. I tried using a third patch, because maybe the sending from A and B have the same latency when reaching C, but it didn't work, they have different as far as I can tell.
I also tried sending the signal (instead the float) form A to B, then delaying patch B's own signal, but it seem to me that the delay~ can only delay a signal by 512 samples, which is weird.
I'm a beginner, so any info or clearing things up in my head is appreciated.


@WINGEDFINGER: hmm I cant reproduce with my patch regarding the float...I am not talking about audio here in general,only about messages.audio will have some sort of delay and I dont think that
can be changed..
did U use the patch I set up?
@BROC: I just checked about LIVE's API again,and it seems somebody has been working on it.I get
only 10 msec of delay now for starting LIVE's transport from M4L.this used to be 30 msec.
I totally agree with you that timing inaccuracies intoduced by the LOM should be documented..

Hey there, in order to have one midi track sending midi notes to several „layer children tracks“ with instruments on them,  I am using s/r. The “Master“ track has a send device on it (midiin —> s chan1) and the midi tracks with the instruments each have a recieve device on them (s chan1 —> midiout).
When starting the clip on the “master“ track and havin abletons metronom playing aswell, the instrument tracks are randomly off grid/quantisation of the metronom (getting randomly long delayed, due to latency I guess).

I am using Ableton Live 10.
Is there any way known by now, to get rid of the latency issues, when using  s/r over multiple tracks?

it's a pity to hear this issue still hasn't been taken care of in Live10/Max8.
from what i remember (i think by reading posts on this thread some time ago), it's not advisable to use send/receive for routing audio/midi in maxforlive unless you really don't care about timing issues.
in your case, i would suggest to use LOM messages for the routing instead of S/R.




You know that you can address other tracks from M4L in Live 10 now correct, both audio and midi. 

@Malte I am actually getting super good results in the exact same situation. Do you have a small buffer size in your preferences? M4L runs in audio in interrupt so you better have a small i/o buffer size

there is also an easy workaround if you want to bypass Max's send and receive objects: use Ableton's built-in routings in which all your "children" tracks receive from the main track. Then from your main track assign a midi value such as pitch bend, cc, program change... to each midi note with the midiformat object, and then on your children track, unpack and select. Something like this: 

@Florent GHYS  - M4L doesn't seem to have the option to change the buffer size, which makes sense to me as I would think the host would determine that. I'm doing a super simple one MIDI track transposes another setup and getting variable and high latency values. I thought a workaround could be the track delay compensation and just have the master track have negative delay so it starts earlier in playback but that doesn't seem to affect max messages. 15 MS is definitely too much 


hey, yes buffer size is determined in Ableton's preferences
the negative track delay + pipe within your M4L patch should be working, I'm doing it all the time

 @Florent GHYS  no the track delay definitely isn't affecting the control side of things. It does the control stuff then delays the audio it looks like. In a set with nothing in it, the timing looks to show no delay also. However that's not a real world situation. Also, this would be something to share. I can't require that the user set their buffer size in Ableton for it to work. Other ideas ? 

How fast and consistent is device mapping controls ?  Some use audio rate. Its messy, but is there a workaround to talk between devices trying to do simple things like note transposition using a different method ?

The above tests are lying .... I plopped that on the og transposer device and it measured 0 ms between received notes on the native track and the sent ones from the master track. However even at 5ms delay the native track will outpace the sent notes sometimes as I can hear (just bouncing back and forth an half notes transposing a semitone and back down. So I can't even diagnose it. I re-read through all the comments where people thought there wasn't latency anymore and I suspect it may be because timer is lying. 

Just did again some tests with send/receive and noticed that the latency depends on the actual configuration. When moving the send/receive devices around on different tracks, I got either latency 0 or x, where x depends on Live's audio buffer size. So the occurrence of latency is not predictable but the possible maximum value.












@broc So we are saying that faster than audio buffer is possible, and it won't exceed this ? If using clunky live.remote / LOM methods is that always at buffer latency ? I see discussion in this thread of variability there and I'm wondering if I should even be exploring that. 

The latency of live.remote/live.object when used with Max messages is subject to the activity in Live's UI thread. So it can be higher than with send/receive.



@Florent Ghys : thank you so much for the PitchBend trick to route MIDI from different tracks ! 

Hi, I reviving this topic, trying to see if there is any latency when using send/receive between m4l devices. 
I made these two devices to testify there is any latency. It seems to prove that there is no latency, as the value displayed by the receiver is always the same as the sender. 
Am I correct, or is my way of testing wrong ? 

latency of send/receive predictable?

Lorand Sebestyen

I have mapped plenty of effect parameters to my midi controller. And there is a "device select" command which I can also assign. But it 'd be nice to see what I am doing whenever I change any parameter on any device. 

I dont want to assign a whole single button on my controller just for selecting the device.

I can assign "device select" to any parameter change but only to a single one. So If I want to select the device I' always had to change that parameter only which is not so convenient. 

Is it possible to do in Max for Live to automatically select (and jump to) the device on wich I changing the parameters? 

I have mapped plenty of effect parameters to my midi controller. And there is a "device select" command which I can also assign. But it 'd...

automatic-device-selection-when-changing-parameters-on-that-device

automatic device selection when changing parameters on that device

uncle_meat

I'm trying to midi map or key map a live.tab object in Live, but it's the same in max. The live.tab object has 3 tabs and I'm expecting that I can assign each tab to a different midi or key command. The only way it works is to have one single midi or key command that cycle between tabs. 

Let's say I have the default live.tab that comes with 3 tabs labeled "one" "two" "three". Let's say I would like to assign the numeric keys "1", "2" and "3" to the tabs in order to directly control the switching. I can' find any possible way; I can assign only one command.

Max For Live Forum