BPM value from the DAW

[MikeB]

How do I make a BPM knob continuously take the BPM value from the DAW?

So if I change the BPM value in the DAW, the BPM value in the plug-in automatically adjusts.

[A Former User]

You could use a timer with a long timer tickrate to avoid unnecessary CPU usage alongside Engine.getHostBpm() to update the knob value in the timer callback

Edit:

const var timer = Engine.createTimerObject();
var BPM = Engine.getHostBpm();

timer.setTimerCallback(function()
{
    if (Engine.getHostBpm() != BPM) //only updates if the BPM has changed
    {
        BPM = Engine.getHostBpm();
        Knob.setValue(BPM);
        Knob.changed(); //make sure to call .changed()
    }
}

timer.startTimer(200); //Checks every .2s

If you need to update more frequenty, use a smaller number in timer.startTimer()

[ulrik]

@iamlamprey @MikeB or you could use this, then you don't need any timer. It will react as soon as the daw tempo change

const var HostBpm = Content.getComponent("HostBpm");
const TH = Engine.createTransportHandler();

inline function tempoChange(newTempo)
{
	Console.print(newTempo);
	HostBpm.setValue(newTempo);
	
	//	if you only want the tempo displayed and
	//	not to trigger the HostBpm CB you dont need this line
	HostBpm.changed();
}

TH.setOnTempoChange(true, tempoChange);

[A Former User]

@ulrik oh right transport handler exists, yeah use that lol

[Christoph Hart]

@ulrik you're example is almost perfect, with the exception of the first parameter of setOnTempoChange() which defines whether the callback should be executed immediately or should be deferred to the UI thread. This might have serious implications on the audio performance (if you're doing heavyweight UI stuff in the knob callback) so it should be addressed carefully.

In your example it's set to true, which means, well ... no idea, I have to look up what the bool value means EVERY SINGLE TIME. This is bad and has nagged me for quite a while now (in fact I changed some functions for the broadcaster last week to address that problem there). Also I should have learned from the great masters of API design because JUCE also had some old methods using a bool value instead of a more descriptive notification type and they (or Jules alone back in the days) changed the API interface to use a enum instead.

So a breaking change in the API interface is out of the question as this is a bit too old so many people might already use it. So what I did was to define two global variables with some magic numbers, SyncNotification and AsyncNotification and all methods that have previously taken a bool value (spoiler alert, bool means synchronous) will now accept and handle the magic number value accordingly. The bool value will still work like before so it won't break older projects, but the way going forward is this:

TH.setOnTempoChange(SyncNotification, tempoChange);

which makes it immediately clear how this function will be executed (and also what the argument does at all, which was especially confusing with function calls that had another bool parameter).

[ulrik]

@Christoph-Hart thanks for explaining!