Accurate range conversion

[Christoph Hart]

You're a bit off-track and scripting and macro controls are definitely the wrong tool for the job.

Some of these FX have BPM Knobs, which should automatically receive tempochanges by the DAW using Transport Handler. Since i have no idea, how to connect them in that moment

Just use a tempo-sync node and connect it to whatever faust parameter you need to be synced. The tempo sync node automatically converts the current tempo to a ms value (and if you want to connect it to a frequency parameter you can use a converter node with the appropriate mode).

[toxonic]

@Christoph-Hart Hmm, but the tempo sync node updates tempo changes in 64t at best, correct? Thats 's not really accurate, right?

[toxonic]

Okay, i got it working now by scanning the array with all HardcodedMasterFX References for a parameter called "bpm" and if available, assign to the Transport Handler function.

const var HardcodedMasterFX = [Synth.getEffect("HardcodedMasterFX1"), Synth.getEffect("HardcodedMasterFX2"),
Synth.getEffect("HardcodedMasterFX3")];

const var th = Engine.createTransportHandler();

th.setOnTempoChange(false, function(newTempo)
{
	for (x in HardcodedMasterFX)
	{
		var bpmknob = x.getAttributeIndex("bpm");
		if (bpmknob != -1) x.setAttribute(bpmknob, newTempo);
		else continue;
	}
	
});

The result of one day of trial and error... sad but true! :-( But yeah, every beginning is difficult! ;-)

[Christoph Hart]

Hmm, but the tempo sync node updates tempo changes in 64t at best, correct? Thats 's not really accurate, right?

No, that's just the smallest divisor. The host tempo is converted to milliseconds using the full double precision but if your faust class expects a parameter as BPM, you will have to convert it back to BPM values.

The formula is BPM = 60.0 / (ms * 0.001) so you could just use a control.cable_expr node, but I've also added a converter mode to the control.converter node that does this for you.

[toxonic]

@Christoph-Hart said in Accurate range conversion:

No, that's just the smallest divisor. The host tempo is converted to milliseconds using the full double precision....

Aha, okay, then i got that wrong. It seemd to me, that it only updates the ms values in dependence to the tempo.

...but if your faust class expects a parameter as BPM, you will have to convert it back to BPM values.
The formula is BPM = 60.0 / (ms * 0.001) ....

I have already converted the values inside some of the Faust files according this formula.

....so you could just use a control.cable_expr node, but I've also added a converter mode to the control.converter node that does this for you.

Ah, nice, that you already added the MS2BPMModeto the converter node! :-)
Just one more question: The solution i posted in my above post seems to me quite satisfying at the moment, but due to my lack of experience i just want to ask you, if you think, if there's something to complain about. What do you think?

[Christoph Hart]

@toxonic Yes you're using a asynchronous tempo callback so the tempo update will be dragged through the UI thread and might be updated a few milliseconds later if the UI is busy.

Whether you can live with that kind of hack is up to you, but the cleaner solution is to use a tempo_sync node like I suggested.

[toxonic]

@Christoph-Hart What about putting it into an inline function to get it synchronous?

const var th = Engine.createTransportHandler();

th.setOnTempoChange(true, TempoChange);

inline function TempoChange(newTempo)
{
	for (x in HardcodedMasterFX)
	{
		local bpmknob = x.getAttributeIndex("bpm");
		if (bpmknob != -1) x.setAttribute(bpmknob, newTempo);
		else continue;
	}
	
};�```

[Christoph Hart]

@toxonic Yes, but then you get a string comparison function in a loop whenever the tempo changes in the audio callback.

[toxonic]

@Christoph-Hart Yes, right - you mean, this is a question of CPU usage? I thought, it would maybe suck more ressources, if i have multiple instances of the tempo sync node / converter nodes running ? No?

[Christoph Hart]

@toxonic It won't burn your CPU to use this, but it's vastly more ineffective than a tempo sync node, which is just a virtual function call with the new tempo value which is basically free unless you have thousands of tempo sync nodes (with your solution you also get the overhead of calling into HiseScript).

It's not critical per se but you asked me what's wrong with the code and I would do it differently.

[toxonic]

@Christoph-Hart okay, thank you for the explanation. I'll change this in my project after i compiled the latest commit for the converter node.