changing tempo through OSC

Hello,
I’m programming a application to control Ardour through pure data.
I managed to contol basic play/stop commands, but I cannot find an easy way to change tempo.
I found only following OSC commands to edit tempo information: Editor/set-tempo-from-edit-range and Editor/set-tempo-from-region. But they don’t work as I would expect. In fact, I’m even not able to use them properly from inside Ardour.
So, basically, I would like to know if there is a OSC command to change global tempo, whitout going into regions.
Thanks,
Andrés

No such command, sorry. In addition there is no single global tempo, at least not in theory. In practice many projects have only a single tempo marker, so effectively there is. It might be trivial to add this.

Thanks,
so, how would I do if I want to change the tempo continously - let’s say, every second?
In this case, I think it’s not a good approach to work in a region-based approach.

You would have a tempo marker in each location you wanted to change tempo at. There would then have to be some way to identify/address a tempo marker via OSC. Probably position.

Ok paul, thank you very much for the answer.
I was imagining there was a continuous tempo control.
But I will manage with that.
Greetings

hi,
just wanted to say that I would very much appreciate an OSC-command for changing the bpm!

That’s highly non-trivial because Ardour doesn’t have “a bpm” but rather a tempo map that may contain arbitrary numbers of different tempos and meters. This isn’t garageband, and there’s life beyond 4/4 …

what does this have to do with 4/4? I just want to be able to sync Ardour with pd without using midi clock. There is an pd object called jack_transport which gives me Ardours absolute position in samples. But without knowing or setting the exact tempo, I can’t sync beat related stuff in pd to it.
In Ardours secondary clock window there is a tempo field to override the current tempo mark. I’d be totally happy if this would be OSCable. For my understanding, this wouldn’t be hard to implement, right?

“In Ardours secondary clock window there is a tempo field to override the current tempo mark” is not correct. it displays the tempo at the current position.
(BTW, you can switch the clock modes, right click on the clock).

There is no single unique tempo/metrum for a session. A possible interface would be “add/replace tempo+metro at position X” or “change tempo/metrum marker #X”. however neither can be done without knowing the current tempo-map nor can it be guaranteed to work. Metrum and tempo can [currently] only be changed on beat-positions.

There could be a special case “set tempo if and only if there is only a single tempo/metrum definition in the session and that is at the beginning of the session”. while this may solve the issue at hand it’s rather limiting.

““In Ardours secondary clock window there is a tempo field to override the current tempo mark” is not correct. it displays the tempo at the current position.”
But if you click on it, it opens a dialog called “Edit Tempo” where you can also tap the tempo in. From what I see, this tempo editing applies to the current (or the last) tempo mark at play position.
So I know there is no single tempo, but there is already a function to edit the current tempo mark, which I think could easlily be reached by a single OSC-command. In a project with a single tempo mark at the beginning, this should then behave like a global tempo change.

setting the tempo will not provide sync. in addition, JACK transport will convey tempo information to all JACK clients. So I am not sure why you say “without knowing or setting the exact tempo, I can’t sync beat related stuff in pd to it.”. The information is all available to pd, as it is to all other JACK clients. Note, however, that Ardour only sends this information - it does not change its own behaviour in response (because we have a timeline, with tempo+meter events, this would be hard(er) to do).

The jack_transport object in pd is a rather basic implementation, it isn’t capable of reporting bpm but only absolute position. I tried to modify it so it receives bpm, but I didn’t had success yet.
To derive relative time like beats and bars, I need to know the bpm. I know this is kind of a workaround but this is just one reason why I want to set the bpm from with OSC. I think it would be generally handy and would complete the OSC-implementation in that respect.

Let me just explain a little further in what context I’d use this OSC function. I’m making a program called MuVisu for learning instruments (similar to Guitar Hero, Rocksmith or Rockband) in pd. Here is a little demo video I made about a year ago: https://youtu.be/nLxiLgX0ABc. Back then I used Reaper as a backend for the song informations (like the playback and the notes to be played) which are streamed to pd and there visualized. The release of Ardour4 made me say goodbye to Reaper.
With Reaper I used to use midi clock for syncing between the daw and the pd-patch. But midi clock only does relative sync and isn’t very stable. Now with Ardour there is absolute sync via Jack but the mentioned pd object for syncing to jack doesn’t provide bpm, only the position in samples.
My goal is that the user can change tempo and song position from the gui of MuVisu while practising. So I hoped I can do all that with OSC and don’t need the bpm Information from jack because I set it myself anyway…

Let me just explain a little further in what context I’d use this OSC function. I’m making a program called MuVisu for learning instruments (similar to Guitar Hero, Rocksmith or Rockband) in pd. Here is a little demo video I made about a year ago: https://youtu.be/nLxiLgX0ABc. Back then I used Reaper as a backend for the song informations (like the playback and the notes to be played) which are streamed to pd and there visualized. The release of Ardour4 made me say goodbye to Reaper.
With Reaper I used to use midi clock for syncing between the daw and the pd-patch. But midi clock only does relative sync and isn’t very stable. Now with Ardour there is absolute sync via Jack but the mentioned pd object for syncing to jack doesn’t provide bpm, only the position in samples.
My goal is that the user can change tempo and song position from the gui of MuVisu while practising. So I hoped I can do all that with OSC and don’t need the bpm Information from jack because I set it myself anyway…

@piesi: do you compile Ardour from source? if so it’s easy to help yourself: https://gist.github.com/x42/ce1f651be959ff17aec1

Adding new OSC interfaces is something that needs to be done with care. Once an interface added it’s impossible to remove it (interfaces need to be backwards compatible).
To do this properly the complete tempo-map would need to be exposed (“quary/add/change tempo at…”) and the tempo map will probably change in the mid-term future to allow tempo-ramps.

It’s probably a good idea to patch the pd-jack object as well to query the BPM and Bar/Beat/Tick position from Ardour (if ardour is timebase master it’ll translate absolute time to musical time and tell jack).

thanks a lot, I never compiled Ardour myself before but I will probably try to do so - it’s got a lot dependencies, right?
Patching the pd-object might be trivial, but I have very little experience on writing pd-objects and using the jack api. So up until now my efforts have been fruitless…