jbone1313

According to the documentation of Ableton’s Max For Live LiveAPI Object, it is no longer possible to configure JavaScript functions to run in the high-priority thread of Max’s scheduler. So, Max For Live JavaScript functions run in the low-priority thread. However, I could not find any information on whether these functions are latency compensated or not.

Are Max For Live's JavaScript functions, which run in the low-priority thread, latency compensated?

For example, say I create a Max For Live device, which uses JavaScript functions, and the MIDI processing inside those functions takes 50ms. Assuming Live's latency compensation is enabled, will the 50ms of latency my Max For Live device induces be correctly compensated by Live?

According to the documentation of Ableton’s Max For Live LiveAPI Object, it is no longer possible to configure JavaScript functions to run ... 

are-max-for-live's-javascript-functions-which-run-in-the-low-priority-thread-latency-compensated

My understanding is no - the low thread is the UI or "main" thread so it does not have any audio timing plumbing.  If you want to run code in Live in the high priority thread, you can use my Scheme for Max project, which can run in either the high or low thread (you must pick one). 

However, it's also worth nothing that any Live API calls should come from a low thread object anyway as they will get deferred to the low thread, so using JS for Live API calls is fine. This is the same as the Live API for Python control surface scripts btw - all control surface actions are running in a lower priority thread.

This is the same as the Live API for Python control surface scripts btw - all control surface actions are running in a lower priority thread.

Ah! You are talking about the Python MIDI remote scripts, right?

If that is the case, and since I already have my project implemented with Python + MIDI remote scripts and I am happy with its performance, then I should also be fine with the performance I would get if I implement it in Max For Live!

I really appreciate your reply! That is very helpful, and I think I have given myself a green light to invest the time to attempt to implement my project in Max For Live. FWIW, I am interested in porting my project to Max For Live, since it seems like it can probably run on the new standalone Push (apparently user remote scripts cannot) and since if, down the road, I decide to try to monetize it, it will be easier to do that with Max For Live, since there is a lot more support for selling Max For Live devices compared to MIDI remote scripts.

I have seen your Scheme for Max project, and I am going to take a closer look at it. 

Thanks again. 

I'm actually talking about the Python SDK that is used for commercial control surfaces, but I would imagine that is the same  or very similar under the hood. (I made Python scripts in Live years ago when you could only do this with the reverse engineered tools floating around the web!)  I am also not sure whether the kind of latency and jitter you will get running JS in an M4L device is goi ng to be exactly the same, but I would expect it would be similar. 

I can say, having been working on this sort of thing a lot over the last couple of years, that you have a lot of options in M4L, so I think it will be well worth the time investment. One of the tricks I have used when I need something to happen sooner is to have Live tracks using midi loopback devices so that Max devices can listen to the plugsync~ output (which runs in the audio thread) and can update parts of live through MIDI remoting. This is sometimes a better solution in my work than the Live API calls. I use both approaches a lot. In my own Live setup, I use both low and high priority S4M objects and have them message each other to ask for function calls - something that is very easy in Lisps as you can just send a list of symbols and have the recipient excecute it with eval and apply.

It's also worth pointing out that latency, performance, and jitter are all different. So for example, if you trigger a live API call from a clock running in your high thread, there may be some jitter depending on how long it is until the next pass of the low thread. But as this does not accumulate, it often doesn't matter. Real acoustic musicians have huge jitter, but we don't notice so much because it doesn't get progressively worse. 

Are Max For Live's JavaScript functions, which run in the low-priority thread, latency compensated?

Thomas Grey

Hello,
I would like to know the overall Live latency (input latency + output latency) through a query performed in a Max For Live Device.
Does anyone know a way to do this?

Hello,
I would like to know the overall Live latency (input latency + output latency) through a query performed in a Max For Live Device.
Do

get-overall-live-latency


record a click directly from an anlog signal and its delayed version through whatever gear.

then you can easily see the time difference.

how you record it is almost irrelevant, but i would use a PC (for example the one  you are going to test)


Thank you very much Roman for your reply.
I happen to have used this solution in the past, however I think I need to further detail my current needs.

For live performances, I need an automatic way to indicate the overall system latency to a number of MaxForLive Devices, in order to compensate for the latency that comes from using hardware to which I send audio signals that I then send back to process in these Devices, to work primarily on BPM-synchronised echo FB.
In order for the echo to be synchronised, I need to compensate the latency by advancing the first "reflection"; this is where I need to know the latency of the system.

The latency value cannot be static, because with every new version of Live, or computer / audio interface change, this value is likely to vary, and I don't want to have to make a new manual measurement every time I change a part of the system.

What I was hoping to find is the ability to call a kind of "get overall latency" using a MaxForLive object such as [live.object} or [live.path].
I've done some research in this direction and haven't found anything yet, so maybe the solution won't be that simple.

What Roman suggested is your only chance.
Make a device that sends click to whatever hardware you use,
and compare time offset to received audio back.
publish the measured time to delay offsets or whatever you need.
That exists in form of lateny measure patch since max 4
just needs to get simplified for your use.



if the value you need includes plug-ins´ latencies and/or different DSP settings - and you need that value programmatically in m4l - maybe it is possible that yout measure these components one by one, or different setups, write them into a coll and then sum them up where you need them?


As I said, I've used this method in the past (for the last 10 years, both in Max and Reaktor).

But, since Live "knows" the latency, I thought it would be more efficient and elegant to get this info using the Live API, as I need to give it to MaxForLive Devices.
If this info is not yet accessible / cannot be obtained (for technical reasons) via the API, then I will continue to use the old pragmatic method.

Roman, what you are proposing is precisely the direction in which I am currently heading.
Thank you for your input!

Hi OP,

Did you have any luck with this? I am also interested in a way to programmatically ascertain a current Live set's latency so that I can pass it to a Max For Live device.

Any info you have is greatly appreciated.


Get overall Live latency

Neil Baldwin

Just finishing up a large-ish project that contains 25+ external (bpatcher) files and was wondering about a couple of things:

Is it prudent/good practice to try to make your external file names somehow unique e.g. prefixing with "MYCOOLPROJECT_"  ?

What are the advantages/disadvantages of using the 'Embed in parent' option for bpatchers? Almost all of the externals referenced in the project are of use only to my project and often are only abstracted this way for convenience (instancing etc.)

How do people go about distributing updates or future versions of their projects? How do you update the device in Live? During development I've just been manually deleting it from my Live library and installing again but this doesn't seem end-user friendly.

Is it good practice to include a version numbering schema in the package filename e.g. MYCOOLPROJECT-1-0-0 ?

Just finishing up a large-ish project that contains 25+ external (bpatcher) files and was wondering about a couple of things:
Is it ... 

packagingdistribution-best-practices

Those are good questions. I'll try to give what insight I can. As far as bpatchers, I had a similar set of projects with a lot of bpatchers in them. I should of made a guide to bpatchers while it was fresh because they definitely caused me some confusion too. Looking at my project, I did not use the 'embed in parent' option. One thing I remember doing was under "Show Containing Project" on the bottom toolbar I used the '+' to make sure the subpatchers were listed as "Explicit" dependencies. This made freezing work consistently without issue because Max knew exactly where to find the files.

I made my file names unique as well. It seems likely a good idea in this instance.

I did not include a version number in the name of the .amxd file. If the update was big enough I may add V2 to the name, but otherwise I would find another place to indicate an incremental update version number. Some sites like maxforlive.com or Gumroad in my case help show version numbers too. I haven't had to do either kind update yet, but my general advice would be to test as much as you can to figure out the best strategy and then communicate to your users well about how to approach an update. I'll try to remember to follow-up on this thread as I get more info. Good luck with your release!

unique names with nametags and/or project names are obligatory 1. locally during development 2. when you want to give the project to a friend for testing 3. when you want to use it on another computer and 4. when you want to combine two programs into a single one one day.

so even if it is not required when you target is a live device or standalone application, it still makes sense. and this applies to everything in a project, i.e. patches, media files, images, shader, preferences/coll.txt, you name it.

naming packages including version number? not the worst idea. i do it, too. i do it with everything else, too. for example with music projects or software collection. it is really nice mainly when you share files. we all know that: you download an update to your favorite free text editor and the file is called "installer.zip", just like the last version. the other da you dont know which is which. no, it should read "texteditor 3.0.1.zip" please.

the exception for /packages would be that you make a proper installer which updates the existing version. then you can put the version number info somewhere inside instead of renaming the package.


@trevorbeingtrevor I really appreciate your reply, thank you so much 🙏

Packaging/Distribution Best Practices?

monty_mcmont

Hi, I'm using the Jitter components of the Max for Live software, using Live 8.1.3.

I bought the full version of Max for Live about a month ago, and until today Jitter was working perfectly. Since this morning, every few seconds all video output to my Jitter rendering contexts stops and the window turns grey. This goes on for a couple of seconds until rendering resumes. This cycle then repeats. Audio seems to continue just fine, the picture just stops rendering.

It's not just my patches that have this problem; the help page example patches do the same thing. When the rendering context of the jit.alphablend help patch temporarily stops, it shows the error "View disabled in editor: Jitter is not authorized". It was about 30 days ago that I installed Max for Live, and if I try to load the standalone version of Max it tells me that my free trial has expired and that I need to authorize it. 

I don't need to run the standalone version, I only ever need to run Max/MSP/Jitter from within Live.

Does anyone know how I can sort this out? 

view-disabled-in-editor-jitter-is-not-authorized

It worked previously because you were in demo mode.Owners of the full version of MaxMSP and Jitter do not have this restriction, which is only present ion the MFL editor. Jitter patching in your devices will still display correctly when running in Live.

Can not get this to work. I have bought max 8 months ago. tried re installing. 

"View disabled in editor: Jitter is not authorized"

Michael DeFiore

I'm creating a device which sends out raw midi values via midi out. A message box contains the midi values, which is sent to [midiout] via a bangs. Some of the values are sysex which are 8 values.

Do I need to be concerned about different sysex values interleaving with each other? 

For example, I send sysex value "F0 01 02 03 04 05 06 07 F7" and sysex value "F0 01 02 03 04 05 06 07 F7"  at the same time via the same midiout. Does Max somehow deal with such a situation or is this something I need to deal with in my device?

Hi,
I'm creating a device which sends out raw midi values via midi out. 

raw-midi-values-via-midi-out-issues-with-interleaving-or-interference

You should be concerned about MIDI interleaving. It's easy to corrupt sysex streams in Max, and some hardware don't like corrupted datas (like old iConnect interfaces that just freeze when this happen).

It does not seem like Max has objects needed to ensure non-interleaving. Can anyone advise how to deal with the potential issues?

it is not max, but ableton, which merges all midi out objects in a device
into single out stream.
in max you use separate midi objects without such problems.
in live, you have to time or better say put in a queue sysex messages.
or try 3rd party direct out midi externals, like imp.midi for example


Many thanks SourceAudio. Imp.midi worked very well to resolve the midi corruption I was getting when sending sysex. I've suspected for a while that Ableton's under-the-hood midi implementation left much to be desired; this experience confirmed it. 

Raw MIDI values via MIDI OUT:  issues with interleaving or interference?

Mellon

After updating to Live 11.3.2 all messages to live.object are returning some variation of "invalid syntax" to the console. . Neither my own nor the included m4l devices are functionctioning in regards to LOM use. Anyone else running into this? I am using the bundled MAX.

Screenshot 2023-05-23 160122 INVALID SYNTAX.png

After updating to Live 11.3.2 all messages to live.object are returning some variation of "invalid syntax" to the console. . 

11-3-2-broke-lom-interactions

getinfo and get scenes worked for me on Live 11.3.2. You could try to  send a separate message "path live.set" to the live.path object instead of baking into the path. After that, use a live.device object to bang the message once it loads to make sure the API is ready to go before querying it. I am not 100% if this necessary when using the live api directly in max, but this is similar to the practice recommended by the JavaScript documentation.

thanks, that kept me going to keep working on a fix! In case anyone else is stuck, re-installing Live twice did the trick.

11.3.2 broke LOM interactions

Korzybski

Does anybody else have this problem?
OSC TouchOSC device does not remember OSC address settings when I reopen a live set.
Any solutions will be great..

Does anybody else have this problem?
OSC TouchOSC device does not remember OSC address settings when I reopen a live set.
Any solutions will

m4l-connection-kit-osc-touchosc-osc-address-settings

Hi Korzybski, the OSC address settings should be correctly recalled in the OSC TouchOSC device from the latest version of the Connection Kit!

Hi, 
I think the issue has not been solved. 

I installed the last version of Connection Kit (April 2020) and OSC addresses are still not remembered afterI reopen the live set. This is a very bad problem if you have to relearn all the addresses....

For giving you more information, I am running it on a Win 64 bit and I see OSC data well received in the OSC TouchOSC device. It only does not remember addresses when re-opened. I also went to Github and copied the last version of the device to the Connection Kit folder. The issue persists.

Can you check this an provide a solution?


Same problem here 
With the latest Live 10 and Connection Kit version installed.

Reconstruct:
Open a Live Session, and load the OSC TouchOSC device from Connection Kit
Make it work and configure it (IP/Port) to work proper over OSC
Map some of the OSC addresses to Live Parameters and test it
Save Session
Close
Open the previosly saved session in Live
None of the configured parameters will work!
You should see the yellow dot, so the OSC data is coming in, but it is not changing anything in Live anymore.

Any solution for this? And what is the problem?
It's a usefull plug in, so it would be great if it works.

I tried the same with the OSC Send pluging from the same kit and this one seems to reload just fine.


Similar issue here, running on Mac OS Mojave, Ableton Live Suite 11.

When reopening a saved LiveSet with parameters mapped it does actually show my parameters as still mapped (e.g. OSC address: /fader1 mapped to MIDI address: VCF Cutoff), but when I move that /fader1 in TouchOSC it doesn't change the parameter in Ableton / doesn't react (although I do get the Port blinking, showing me that Connection-Kit is receiving signals from said fader). 

So it's basically the same problem in that I would have to relearn the parameters, the only difference being that the address (/fader1) is shown as "mapped" when opening the LiveSet.

did anyone figure out how to recall OSC settings from the "OSC TouchOSC" device?

in my case the addresses are recalled but they don't function unless remapped.

https://www.mediafire.com/folder/3470ksaq12jdl/OSC+Max+For+Live+Device+Fixed

also added speed limit control (for osc messages) and a midi version of the device.

I just tried your patch, and it does not feel like it works. When I open back the Ableton Project, if I use the osc channel it snaps back the value to 0 but doesn't allow me to interact unless I learn again. Any insights?

I'm running the latest version of Ableton Live 11.2.11. 

Thank you Alan, those work great !
The mapping on the 2nd line seems to self-duplicate on the 3rd when blank, but I didn't have this issue when using all 8 slots of the plugin.

m4l Connection kit OSC TouchOSC OSC address settings

wackazong

I experience serious performance issues with M4L:

Create a new Live Set. Delete the MIDI track. Duplicate the audio track about 10 times. CPU load: 2% or so.

Do the same, but before duplicating, put a new M4L audio effect into the track. Now, with 10 empty M4L effects, the same 10 tracks use about 10% CPU! 

How is that possible?? It does not really matter whats in the device, the device itself seems to be very resource-intensive.

m4l-is-a-cpu-hog

try doing the same experiment twice more, but first with 10 simple small vst plugins (e.g. a small delay or so), then repeat with ten vst hogs, e.g. instruments, like 10 reaktors or 10 kontakts. you'll find that cpu varies wildly. therefore, one cannot determine anything from what you have said because we have no idea what is inside your m4l device. a simple m4l midi device will use next to nothing. a m4l 32 voice poly~ device with spectral processing will take up a massive amount of cpu. such is life (and physics). m4l DOES take a little more cpu than other things because it is an entire programme embedded in another, but it is not excessive. also, a badly programmed m4l device will always be shit. what are you using?


Hi, what I meant with "new M4L audio effect" is a completely empty M4L device (only containing plugin~ and plugout~). Sorry if that was unclear. It is clear to me that the content of the device matters. The problem I am describing here though is that the simple existence of a M4L device with nothing in it is already taking a lot of CPU.

Can you maybe correct me on these assumptions:

- M4L shares memory with Ableton Live, both together cannot exceed 4GB.
- M4L runs inside Ableton and is not multiprocessor-capable, i.e. all M4L devices need to run on one CPU?

There was a topic about something similar regarding multiprocessor capability. That topic confirmed your assumptions.

https://cycling74.com/forums/cpu-usage-on-new-macs-use-max4live

I personally agree with you. It is acceptable that M4L is heavy, but both M4L and live in it self uses a lot of CPU power. When comparing ableton live to logic I can see that the sequencers are very different in CPU-usage, Logic being stronger.


This sucks. Big time. Well, I will just have wait until M4L grows up then, I guess.

Ableton and Cycling74, two things on the wishlist for Christmas (see, I give you some time):

- 64 bit Ableton and M4L
- M4L with real multicore capability and leaner plugin architecture

yep, everything in Ableton is 1 core per track, meaning m4l is sharing that one core w/ whatever other devices are on that track.

Live uses one core per signal path, which might be more than one core if a track has multiple chains in parallel: https://help.ableton.com/hc/en-us/articles/209067649-Multi-core-CPU-handling#h_01F748QZVVM1MCQ2T6D6J9HQQ5 

M4L is a CPU hog?

Antti Ikonen

Hey, I've been trying to get a simple program working; I would need to automatically get an ableton live project playing after opening the project. I have a max for live object in empty track with loadbang connected to transport. Nothing happens. What did I do wrong? Thanks already in advance!

Hey, I've been trying to get a simple program working; I would need to automatically get an ableton live project playing after opening the ... 

autoplay-ableton-live

transport has nothing to do with that.
this is as simple as it can be


i made the same mistake myself. thanks for the solution.

Autoplay Ableton Live

Joney Jey

Hello! In random time all M4L plugins (midi, instruments, effects) just don't react on clicks. And all animations of plugins are frozen. Like an image. But all parameters work. Sometimes reload Live can help me. Sometimes I should do it several times. But there are projects where I can't use M4L plugins anymore because it doesn't help. BUT when I open new project M4L plugins always work! Also it doesn't matter what Live version I have - all 11 Lives have same issue on my PC.
Windows 11 Pro 21H2 (22000.318)
Help me please.

Hello! In random time all M4L plugins (midi, instruments, effects) just don't react on clicks. And all animations of plugins are frozen. 

Cycling '74 Forums

It's also worth pointing out that latency, performance, and jitter are all different.

Hi OP, Did you have any luck with this? I am also interested in a way to programmatically ascertain a current Live set's latency so that I ...

@trevorbeingtrevor I really appreciate your reply, thank you so much 🙏

Can not get this to work. I have bought max 8 months ago. tried re installing.

Many thanks SourceAudio. Imp.midi worked very well to resolve the midi corruption I was getting when sending sysex.

thanks, that kept me going to keep working on a fix! In case anyone else is stuck, re-installing Live twice did the trick.

Thank you Alan, those work great ! The mapping on the 2nd line seems to self-duplicate on the 3rd when blank, but I didn't have this issue ...

Live uses one core per signal path, which might be more than one core if a track has multiple chains in parallel: ...

Perfect, it works! Thanks a lot! :)

Hello! In random time all M4L plugins (midi, instruments, effects) just don't react on clicks. And all animations of plugins are frozen.