how can i send out the BPM as a steady number instead of a beatclock pulse?

is this even possible? i'm trying to use traktor together with another external visualization program. i'm sending the beatclock or other messages to my other program via a virtual midi controller. works fine and dandy so far. what i would need now, is to send out the BPM to the other program, but not as a pulse (the beatclock). I would need for example 100bpm to be sent as the value 1.0, and 150bpm to be sent as 1.5 and so on. is this even possible?

i fiddled around with all the midi out's i thought made sense, eg the tempo adjust seemed promising, however it only corresponds to the tempo adjust slider and not the actual bpm.

not that you get my wrong, my visualization program is able to recieve the beat clock, however as a pulse going constantly from 1 to 0 dependant on the bpm speed. which is also very useful. what i need though is a static value that corresponds to the speed.

 

You can't. You need to get the beat ticks and work out the bpm from them using their timestamps. Traktor will only send its slider value which isn't what you need, or a midi clock.

Thats how i understand it anyway

 

thanks. beat ticks and midi clock are two seperate things?

also, i was a little bit successful with sending out "set master tempo", however i realized that my initial idea was flawed from the beginning. because 'set master tempo' needs a range, eg from 40 bpm to 200 bpm. however all these bpms in-between are reduced to 127 steps, 127 numbers, because midi. obviously the resulting values are kinda strange. while i managed to get 40 as 40 and 200 as 200, 100 comes in as 99.213 and 80 as 79.055 . i didnt think of that. a workaround would be to use a bpm range of only 127, but then still i'd be restricted to only full numbers and no decimals.

 

thinking about it, traktor is not yet officially able to send out OSC messages right? that would eliminate the "127 numbers problem" (which is.. about 7 bits?) because OSC supports 32 bit floats which should be more than enough.

well now, my vizualization program cant understand OSC's yet anyway, but it's a thought worth pursuing i think.