beattime reporting on tempo changes?
Is beattime supposed to automatically report on tempo changes?
It seemed like could use [beattime] in place of the right outlet of [transport] (divided by 480), except I'm a little concerned that it's outputting when the tempo changes during forward playback.
The reference says: "Beat time, also reports on time jumps."
In a DAW like Live being able to report on time jump seems useful, considering both non-linear/looping playback options as well as transport navigation while not playing back, but I definitely don't think of tempo changing during forward playback and a time jump as being the same thing.
------
The follow up question to this would be: if my existing code is polling [transport] and using only two of its outlets, is there any performance win by switching to using two of the separate "component" objects (e.g. beattime) in RNBO instead of just sticking with [transport]?
I don't think that beattime should output when the tempo changes, just when the transport position changes. In a brief test, that seems to be the case.
Banging transport will likely be more expensive, as each bang triggers a few extra calculations, instead of the single call to beattime() that happens in the beattime object.
Thanks Ben. When I relaunch Max and make up the most trivial case of beattime and tempo change I didn't reproduce either, but once you have two rnbo~ that changes.
I just submitted a bug report for this, but:
*STEPS
- New from clipboard with the trivial patch below
- New from clipboard with the trivial patch below (a second one)
- start transport
- start setting tempo in one rnbo~ instance
>>> beattime in the other instance starts outputting values.
FWIW my normal case hasn't involved setting tempo in rnbo~ , it was usually being set in a transport object while in Max and would be set using Live API in practice.