Decode PV fader response values / transform between logarithmic<->linear values

[featherbear]

presonus-studiolive-api/src/lib/Client.ts

Lines 97 to 106 in 3e926a5

	name = simplifyPathTokens(tokenisePath(name))
	value = valueTransform(name, value, {
	'line.*.volume'(value: Buffer) {
	return value.readInt32LE()
	}
	})
	this.state.set(name, value)
	})

For volume, the ZB value is a float32 (BE), 0.0 - 1.0, linear - so represents the linear fader position
But the PV packet contains c3 f5 68 3f at max, and ba c5 66 3f at min

---

From previous research (see here), we know that the PV values increase non-linearly (when parsed as a uint32 LE). See the pink curve above.

We can create a LUT / approximation curve function like the below

presonus-studiolive-api/src/lib/util/valueUtil.ts

Lines 6 to 10 in 3e926a5

	export function logVolumeTo32(db) {
	// Gaussian / Bell Curve fit - https://mycurvefit.com/
	const curveFunction = (x) => Math.trunc(
	1064974000 * Math.exp((-Math.pow(x - 17.99124, 2) / (2 * Math.pow(238.1057, 2))))
	)

---

I'm not sure what the best internal representation for the fader positions should be - Should they be stored as a linear scale, or logarithmic scale.

I'm thinking, store the values as a linear scale - [0.0, 100]
Doesn't matter too much since Node.js can handle it, but for optimal performance maybe we shouldn't use floats; and store from [0, 65535]? Or just [0, 100]?

How many different values should be represented? Is 100 steps enough?

---

• VLC uses a float to represent volume - https://videolan.videolan.me/vlc/structaudio__output.html#a38d3e01f0ae4d0a266510a7321b3a9f2

[fis-cz]

Is that same for all channels? I have no mixer to check now.

[featherbear]

I haven't fully investigated for other changes yet, will check later this week

[featherbear]

Channel faders

float32 LE	hex	note
0.9014545679092407	ba c5 66 3f	-84 dB
0.9041860699653625	bd 78 67 3f
0.9043974876403809	98 86 67 3f
0.9052431583404541	04 be 67 3f
0.9057416319847107	af de 67 3f
0.9059569239616394	cb ec 67 3f
0.9063875079154968	03 09 68 3f
0.9066029191017151	21 17 68 3f
0.9068899154663086	f0 29 68 3f
0.9071770310401917	c1 3c 68 3f
0.9074641466140747	92 4f 68 3f
0.9076794385910034	ae 5d 68 3f
0.9079665541648865	7f 70 68 3f
0.9081820249557495	9e 7e 68 3f	-10 dB
0.9082160592079163	d9 80 68 3f
0.908353328704834	d8 89 68 3f
0.9084905982017517	d7 92 68 3f
0.908593475818634	95 99 68 3f
0.908636450767517	66 9c 68 3f	-5 dB
0.9087307453155518	94 a2 68 3f
0.9088336229324341	52 a9 68 3f
0.9089022278785706	d1 ad 68 3f
0.9090737700462341	0f b9 68 3f	-0.19 dB
0.909090995788574	30 ba 68 3f	0 dB
0.9091423749923706	8e bd 68 3f
0.9092795848846436	8c c6 68 3f
0.90934818983078	0b cb 68 3f
0.9094854593276978	0a d4 68 3f
0.909545481204986	f9 d7 68 3f	5 dB
0.9096226096153259	07 dd 68 3f
0.9097256064414978	c7 e3 68 3f
0.9097942113876343	46 e8 68 3f
0.9098284840583801	85 ea 68 3f
0.9099313616752625	43 f1 68 3f
0.9099657535552979	84 f3 68 3f
0.9100000262260437	c3 f5 68 3f	10 dB

[featherbear]

Also see #25

[fis-cz]

Did you figure out what this number means? I am not so clever from these values (0.901-0.91) There has to be some formula used, but I didn’t find how it works yet. I wanted to try to debug the UC but I dind’t find a time for that yet.

[featherbear]

A sample of the values plots, they are linear to the logarithmic volume

So we can convert it to a linear value.

---

Otherwise, we can read the MS packet which additionally also has values for the main fader and other auxes
#26

[featherbear]

I'm not sure what the best internal representation for the fader positions should be - Should they be stored as a linear scale, or logarithmic scale.

I'm thinking, store the values as a linear scale - [0.0, 100]
Doesn't matter too much since Node.js can handle it, but for optimal performance maybe we shouldn't use floats; and store from [0, 65535]? Or just [0, 100]?

Internally implementing as a [0-65535] seems sensible. It has 16-bits of precision, and isn't as taxing as a float would. As as interface (get volume, set volume), implement as a ratio [0.0-1.0]

Implement as a [0-100], the UC app only allows so many values anyway

[featherbear]

Tried curve fitting the values for a few hours, but something wasn't working...
In any case, we should still use the MS packets values for volume levels, rather than the PV value

Note that for AUX mixes, a request is sent for line/ch1/aux1, but responses for both line/ch1/aux1 and line/ch1/dca/aux1 are received.

line/ch1/aux1 follows the standard float32 LE
line/ch1/dca/aux1 follows an inverted version of #17 (comment), where level0 = c3 f5 68 3f