Leigh Marble

Reading through the Live Object Model docs, and not seeing a way to do this:

I would like to fire a scene, but ask Live to ignore any BPM or time signature commands embedded in the name of that scene. Can this be done?

Reason being, I would like scenes to have a default BPM, but if I alter Live's tempo while playing, and then retrigger the scene, I would like the tempo to remain where I changed it.

https://cycling74.com/docs/max5/refpages/m4l-ref/m4l_live_object_model.html

The official LOM, for your reference:
https://cycling74.com/docs/max5/refpages/m4l-ref/m4l_live_object_model.html

m4l-api-is-there-any-way-to-fire-a-scene-but-have-it-ignore-any-bpm-commands

afaik, this is not possible. the reason though is not max / maxforlive / lom, but the live application. unfortunately, whilst live is a great app for some things, it is unbelievably backward to the point of being conceptually retarded when it comes to time / pulse / sequence issues. live only thinks that the world is designed in BPM. 'maxforreaper/nuendo/whatever' would have been fantastic in this regard. however, i may complain but it is still great in other ways.

as far as your question goes, there may be workarounds, but these involve live-centric things mostly. i seem to remember forcing a massive amount of samples to be 'warped' in straight 60bpm regardless once to try and do stuff with them...

This should be possible. All a scene does is act as a button to launch clips that are left of the scene button.

You could make your own scene buttons that launch these clips.

I haven't tested how quickly and how many clips you could trigger from a single live.object, but even using a live.object for each track wouldn't tax the CPU much.

This should be possible. All a scene does is act as a button to launch clips that are left of the scene button.
You could make your own scene buttons that launch these clips.
I haven't tested how quickly and how many clips you could trigger from a single live.object, but even using a live.object for each track wouldn't tax the CPU much.


Bjorn, I did try something like what you describe. The problem is that launching a scene is the only way to launch multiple clips *simultaneously* (when the transport is stopped):

Say you've got 3 clips in a scene, called A, B, and C. You want them all to start at the same time. Problem is, even if you fire them all right in a row, one of them has to come first. And, as soon as you fire clip A, the transport starts rolling. So even though you sent "call fire" to clips B and C *right* after A, *they* don't actually fire until the next Clip Launch Quantization interval (e.g. the next bar, if that's what your Quantization is set for).

1. storing the (modified) session tempo in a variable

2. letting the scene fire and change the tempo to the BPM setting in the scene's name

3. immediately switching the session tempo back to the value I had stored.

However, this exposed some weird timing issues, and produced glitchy behavior. I mean, I had learned that calls to the Live API are asynchronous, and that their timing needs to be managed differently than the regular Max flow. (When you make a call to the Live API, you can't count on getting your results right away.) However, this went beyond that, and the order of what seemed to be regular Max events were being strangely reversed... too befuddling at the time, but maybe later I'll go back and double-check what was going on.

Anyways, the clips (or transport, don't remember which) would stop right away, although I saw the clips' triangular "launch" buttons flash. No good.

1. storing the (modified) session tempo in a variable
2. letting the scene fire and change the tempo to the BPM setting in the scene's name
3. immediately switching the session tempo back to the value I had stored.

Anyways, the clips (or transport, don't remember which) would stop right away, although I saw the clips' triangular "launch" buttons flash. No good.


My current workaround is to rewrite the name of the scene with the new BPM value substituted, and then fire the scene. A bunch of [regexp] and [sprintf] shenanigans are involved, but at least playback and timing-wise it is stable.

Only downside is that you are re-writing the default BPMs of all your scenes. So for each performance you'd need to make a duplicate session file, or at least remember not to save your modified session (although, for me, pressing command-s is a reflex, and "remembering not to save" would never work for me).

my idea: use a different syntax in the scene names so that live doesn't recognize the tempo but that you will, and that you parse these names with max 4 live and apply the tempo setting when you want where you can then easily override the tempo settings when you don't want it.

M4L API: Is there any way to fire a scene but have it IGNORE any BPM commands?