AudioLemon

I would like to change tempo for example from 120bpm to 150bpm with the time ramp lasting 4 bars or 7680 ticks. So I would like a tempo ramp starting at beat 1 at 120bpm and ending at 150bpm on the first beat of a new bar (4 bars later).

The [line] to tempo is handy but I cannot figure out what the ramp time should be. Anybody know how I might do it. I tried to figure it out but I keep getting confused between ticks/ms/bpm/bbu.

maths-not-max-problem

I know this isn't the issue, but have you tried with an automation in a sequencer (DAW) using rewire~ to control your tempo? Most sequencer will do this pretty easily. Or even Max4Live?

Ya it's for M4L really. I'd like to be able to press a button and it would start a ramp from X to Y BPM over a set bar length. It would be handy for playing live. Right now I set cue markers in Lives Arrangement window. Hitting a cue will jump to a part in the arrangement where I have automated a tempo ramp or new tempo. It works well but you have to pre-arrange your set and it is a little problematic as you cannot set loop points at the end of the tempo ramp so there is a chance your automation curve might run out or go on to a part where you have automated another ramp. It would be better if I could do it live with a button no automation just direct control over the transport. I can do it but just not to a set bar measure.

Well you have a start tempo, an end tempo, and a rate

If I am not mistaken, the formula for bpm to ms is:

You may want to use a phasor to control the tempo ramp.

To convert ms to freq, you use f = ms/1000

I would recommend using two phasors, one to control the

tempo and one to control the rate of change in the tempo.

I am at work right now, but when I get back to the studio

Well you have a start tempo, an end tempo, and a rate
of change between the two.

If I am not mistaken, the formula for bpm to ms is:
ms = 60000/bpm

You may want to use a phasor to control the tempo ramp.
To convert ms to freq, you use f = ms/1000

I would recommend using two phasors, one to control the
tempo and one to control the rate of change in the tempo.

I am at work right now, but when I get back to the studio
I can whip up an example.


Okay, if you want to use line to do this, here is what makes sense to me. You're basically trying to convert 4 measures to the milliseconds that line uses.

16 beats * 1/X minutes/beat = 16/X minutes

16/X minutes * 60seconds/minute = 960/X seconds

960/X seconds * 1000milliseconds/second = 960,000/X milliseconds

Now the problem is that there isn't a single bpm to use. If you're switching from 120 to 150, and you're making a perfectly smooth linear transition, then I would imagine that the X you want to use is actually halfway between 120 and 150.

i.e. X in the above conversion is what you would get when you average 120 and 150

Now if you want to set the number of measures, just replace 4 with whatever number you want and out comes your time in ms.

In other words, if X is your initial tempo, Y is your final tempo, and Z is the number of measures you want to switch over, your expression would be:

This is what sounds correct to me. I haven't tested it yet, so I don't know for sure. If you already have your previous patch set up though, it shouldn't be that hard to try out.

Also, this is just how you might do it using line~. I'm only a couple months into Max/MSP myself so using a phasor~ as Anthony is suggesting might be a better idea for all I know. Perhaps try them both.

Lets say that X is your bpm
In that case we have

4 measures * 4beats/measure = 16 beats
16 beats * 1/X minutes/beat = 16/X minutes
16/X minutes * 60seconds/minute = 960/X seconds
960/X seconds * 1000milliseconds/second = 960,000/X milliseconds

This is what sounds correct to me. I haven't tested it yet, so I don't know for sure. If you already have your previous patch set up though, it shouldn't be that hard to try out. 

Also, this is just how you might do it using line~. I'm only a couple months into Max/MSP myself so using a phasor~ as Anthony is suggesting might be a better idea for all I know. Perhaps try them both.


Sorry that was awfully wordy and probably confusing. Maybe this example patch will make more sense:

One potential problem with doing it this way is that its slow. Unlike an msp object like phasor~, this updates the tempo every ms rather than every sample. I'm not sure how big a difference that makes for your application.

Also, if anybody has any idea how to initialize all those parameters without an ugly mess of loadbang wires please tell me.

I think I was doing something similar to that yesterday but it was out all the time. I was just taking the average of the ms times eg (4bars@120bpm=8000ms)+(4bars@150bpm=6400ms)/2 and then using the average 7200ms for the ramp time.

It was out a little so I did not think it was right. I had less faith in my addled math than I had in max/lives timing but maybe if I try it at audio rate like Anthony said it'll be tighter.

I think I was doing something similar to that yesterday but it was out all the time. I was just taking the average of the ms times eg (4bars@120bpm=8000ms)+(4bars@150bpm=6400ms)/2 and then using the average 7200ms for the ramp time. 

It was out a little so I did not think it was right. I had less faith in my addled math than I had in max/lives timing but maybe if I try it at audio rate like Anthony said it'll be tighter.


Oh wow, that's quite a bit simpler, good call :b.

but i think pid's method needs to be linked to transport using tempo message to be accurate:

Thanks all for the help. PID that's very clean. I was using [line]. Below is the M4L patch.

I have one small problem. If you control Live's transport at audio rate you cannot change it anymore from Live. I would like to turn on/off the audio rate control of Lives Transport. I set up a gate and I wanted to use line~s end of ramp bang to turn off the gate (freeing up Lives transport) but I had problems. One was that the ramp was not completely finished (due to snapshot~ still doing stuff) so I added a delay and this caused lots of feedback between Lives transport and the device. I tried a few other things like [==] (starttime/endtime)and onebang but I got feedback from Lives transport. Anytime the ramp gate was off and I tried to changes Lives transport it turned the ramp gate on/off randomly (not sure why?)

Basically I have to switch it off manually (not a hassle) but it would be better if it switched itself off after the end of the ramp.

It's lovely little device but if I could fix that it'd be perfect - once it's finished I'll put it up on maxforlive.com

Thanks all for the help. PID that's very clean. I was using [line]. Below is the M4L patch. 

Basically I have to switch it off manually (not a hassle) but it would be better if it switched itself off after the end of the ramp. 

It's lovely little device but if I could fix that it'd be perfect - once it's finished I'll put it up on maxforlive.com


terry's ace completion just needed the [change] object.

personally i would do it more like this i guess (pasted below).

although this is very quick and a bit hacky and not rigorously tested, just an example/...

i would not use that huge [live.property] abstraction - seems a bit overkill to me. and going in and out signal domain a bit iffy, although i guess best to use line~. i was thinking to whack it straight into live.remote~ then remembered we cannot do 'tempo' with that.

p.s. - never try and waste resources / logic by making up messages with commas in them from pack / pak / sprintf / combine type hacking - remember a comma is just a way to separate messages.

Very nice PID. Your message ordering is much better. It still has a slight problem in that it does not update the start tempo box correctly. it falls a little short. It does updates Live transport correctly and it turns itself off so that's good. I might change it a little. I had not thought of [change 0.] to trigger a gate. A new little trick :)

instead of [line], why not use [bline]? It works not with ms, but with events so the transport from 120 to 150 will be done in exactly 7680 ticks... no time unit convertions!

Maths not Max problem.