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.

sorry that didn't help did it...

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...

that didn't help either i expect.

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.

Thanks for the feedback.

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).

The first workaround I tried was:

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.

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.