Sometimes you need to take a break. A loooooooooong break.
It’s been about 6 months since my last update, in part to do with finishing up my thesis, but also because I’ve been stuck on a blocking issue since March.
The CK payload
The Chunk payload contains data (type determined by values in the payload) sent from the sound console, and is used when all the data is not guaranteed to arrive simultaneously - other packets might be sent along the TCP connection.
I’ve been having difficulties with decoding the data… and I rabbit holed into trying to RE the Universal Control and UC Surface applications on my Windows, Mac, and Android machines. After hours and hours of stepping through a debugger and following the assembly - nope.
Yay for Community
The other day, someone expressed appreciation in the project and decided to help out with decoding the CK payload. Funnily enough, it wasn’t a very difficult process (for them at least; they didn’t rabbit hole in the wrong direction 🤡) - you extract some offsets and metadata, and then combine all of the CK payloads.
“combine all of the CK payloads”
That’s what I didn’t try to do, as I thought that the two payloads I saw were independent. Whilst I was under the impression that the data was zlib-compressed (as researched November 2021), I was never able to decode any data from this chunk payload since the payload wasn’t complete! Doh!
Massive thanks to Frantisek Novaki for discovering how to decode this Chunk payload!
What Now?
With the CK payload now able to be decoded into the ZB payload, we get the initial mixer state which allows us to perform ‘toggle’-like functions, and settings / methods that rely on previous states / values! Importantly, we also get the number of channel counts for each channel type (line, aux, fx, etc…) - which is super useful for reading in metering data and dynamically validating control inputs!
I’ve just (14th August) released Version 1.1.0 (still massively an alpha version though) implementing the CK packet parser - which is a huge milestone as this issue was a project blocker! Though whilst it has been half a year since I last touched this project, it will probably be on pause for a bit longer as I finish up some freelance software project that I’ve found myself :)
Hold on tight, improvements to come, soonâ„¢!
View the project here: https://featherbear.cc/presonus-studiolive-api
EDIT: One week later
Okay! So a bunch of changes - some feature contributions, others structural
Value Transformation
I’ve refactored the value transformer data structure and routine to centralise the parsing of the PV and ZB -> UBJSON payloads. I’ve also updated the lookup algorithm to support ‘double wildcard’ specifiers - as to simplify the need for extraneous explicitly defined keys.
For the nerds out there, I improved the performance of the double wildcard matching process by flipping the lists around once the double wildcard has been found - which turns the O(n^2) operation into an O(n) one!!!!
Functions
Pan, stereo width, colour(ish) and an improved volume level function were implemented.
There is also now support to set fader levels for other mixes, such as the AUX and FX mixes.
Approximations
I have no idea what I’m doing
The API has the functionality to set the volume level linearly (0-100 values), or logarithmically (decibels), however I’m bad at maths and couldn’t figure out how to convert between the two (someonehelppls). For the time being I threw some empirically obtained data into a curve fitting tool and copy-pasted the approximate curve function.
Here’s a little peek at the different computed curves
I also un-complicated the linear volume setting function (again I’m dumb), since it turned out that the values were just packed as a float32 value (honestly I have no idea why I didn’t try it, or maybe I did but overlooked it).
