Tempo changes via live.remote~ don't actually change the tempo?
Hi folks,
I'm trying to understand why this doesn't work so perhaps one of you can point out what I'm missing :-)
As far as I see there are three possible ways to set the tempo via the Live API:
1) send "set tempo " to a live.object for the live_set.
2) send "set value " to a live.object on the path "live_set master_track mixer_device song_tempo"
3) send / to a live.remote~ object for the path "live_set master_track mixer_device song_tempo"
All three of them change the tempo as displayed in the top left of the screen, but for (3), even though the value is changing visibly, the song continues playing back at a constant tempo. This is surprising to me.
Also, if any of you could comment on whether any of these solutions might be more efficient I would be very interested. When I observe Live's CPU usage via Activity Monitor (crude, I know), (1) and (2) seem comparable and (3) seems a bit more efficient, but since the playback tempo isn't actually change I don't think that counts. :-)
Attached a sample patch which demonstrates the issue. Thanks for the help!
- Tyler
Live.remote~ can control only Live *DeviceParameters* (see help file). Generally Live.remote is more efficient than live.object, in particular because it doesn't write to the undo history.
Thanks for the reply, Broc. It's true for (1) above that it isn't a DeviceParameter, but per the LiveAPI docs "song_tempo" is a DeviceParameter on the Master Track's MixerDevice object. The fact that (2) works and (3) only sorta works is the weird part.
Ok, I didn't realise that 'song_tempo' is in fact classified in the LOM as DeviceParameter. But it seems a special case since there is no associated GUI element in the MixerDevice. So this may explain the weird/inconsistent behaviour.
Great question! Did you get any resolution to your problem? I'm in a similar pickle. =)
Hi Skeji, I've been using option (2) from the original post and haven't run into serious problems, I just don't know if option (3) would be superior if it worked.
From what I can tell on Ableton's Help pages, I'm bringing this issue up in the correct forum (here on cycling74's site), so bring out teh experts! :-)
Thanks,
Tyler
Any News? Its so depressing. In my fantasy world, you would be able to just right click on any parameter and "Remove From Undo History".
But at least they could fix the live.remote~ so that it actually does what it says it does. My bpm sequencer is desperate.
Just FYI the behavior is still the same with Max 8 / Live 10.0.2. That is: changes via live.remote~ still don't actually affect the song_tempo. The only new data point to offer on that is that live.observer of song_tempo observes the changes as though they are happening.
So, I've been working on a tempo control device which largely depends on the live.remote~ object. In trying to troubleshoot this exact problem I came across this thread.
Seems I'll have to go with option 2 and the 'set value' messages for now. Really would prefer if the live.remote~ option functioned as desired however. Curious as to why it doesn't.
If you you take a look at the Live Object Model (accessible, as is so much else, via the Search feature in Max 8) and you search for the specific message, you'll see something that looks like this:
song_tempo
Type DeviceParameter
Access get
Description
[in master track only]
The important part of this is the "Access" listing. Were it possible to set that value, you'd see it listed as "get, set" rather than "get." It's not broken at all, and it's documented that this parameter (as with some others) doesn't support setting that value in the current implementation of the Live Object Model . Observing the tempo works just fine (that's what the get part means). It's always useful to check the LOM for things like this.
Max, from the entry for live_set:
"
tempo
Type float
Access get, set, observe
Description
Current tempo of the Live Set in BPM, 20.0 ... 999.0. The tempo may be automated, so it can change depending on the current song time.
"
Also: getting and observing are not the same thing.
Also, regardless of what the documentation says about accessing the tempo via
"live_set master_track mixer_device song_tempo"
you can still set and observe the value via live.object. This is hardly the first time documentation doesn't correlate perfectly with reality, though.
Still, none of this explains why live.remote~ changes the displayed value without changing the actual tempo.
Actually, sorry Max, you did raise a very good point, I must have been conflating the documentation of the two this whole time. (I checked docs back to Max 6.1 and they're the same on this as they are now).
So, if the listing for 'live_set master_track mixer_device song_tempo' really is _supposed_ to be only 'get', and it's instead a bug that observing and setting via 'set' still work for this DeviceParameter (since this is inconsistent with the documentation), then it makes sense that live.remote~ behaves in a broken manner.