BeatInfo proof of concept

[honusz]

I've managed to cobble together a working proof of concept for connecting to a controller's BeatInfo service, and subscribing to the stream.

I have it working (at least, for me, with 1x SC6000), code is on the beatinfo branch of my fork.

No super magic here; just connect to the BeatInfo port given by the player in the service request, send an 8 byte request (0x0000000400000000), and the deluge of BeatInfo messages starts coming.

Still haven't totally figured out the messages, but I've included what I think based on analysis so far.

bytes	name	example	note
0-3	id	0x00000002	MessageID i guess? It's always 0x2
4-11	clock	0x0000014d5d13a9f5	A number (bigInt?) that increments every message, pretty sure this is a clock
12-15	id	0x00000002	0x2 again, disregard
16-19	countdownA	0x3faccccc	This starts at zeros, goes to a number below the "zeroTime" and runs up to the "startTime" (see both below) when the track starts playing
20-23	countdown B	0xcccccd69	This also starts at zeros, goes to a number below the "zeroTime" and runs up to the "startTime". It's possible these are a single bigint
24-27	startTime A	0x400ff7d0	I called this startTime, but now I'm not so sure. It only has like 2 values, and one of them is zeros
24-27	startTime B	0x7b6548ba	Same as above. maybe part of one number, maybe not. Needs more research
28-31	trackLoaded A	0x405dffff	This only has two values. Starts at the "zeroTime", goes to another value when the track is loaded UPDATE: this changes when the pitch is adjusted on the player
32-35	trackLoaded B	0xfffffffd	Same as above
36-51	16 bytes of zeros		Always 16 bytes of zeros. Nothing to see here
52-55	zeroTime A	0x405e0000	This value never changes. I call it zeroTime becuase it seems to be around where the track starts. If you subtract this zeroTime from the startTime, or the playhead, you get numbers that start to make sense. It's also the first 4 bytes of the beatData field in the Track's entry in SQL
56-59	zeroTime B	0x00000000	Same as above
60-63	playHead A	0x4057fb36	This starts at zeros, goes to and holds on a value near the "zeroTime", starts incrementing when the track plays
64-67	playHead B	0x7d44e400	Same as above
68-75	16 bytes of zeros		Always seems to have 16x bytes of 0 at the end of the message

That's what I have so far. Try it out, and see if @MarByteBeep or @kkirjala are the kind of people who like puzzles, haha.

[honusz]

Made a quick video demonstration
https://www.youtube.com/watch?v=Ivdk-UmLWqQ

[honusz]

Some observations:

• "zeroTime" is probably misnamed, but I called it thus because its natural state, 0x405e0…, seems to be effective zero, denoting the start of the track waveform (though not necessarily the start of the beat grid). This is bytes 0-7 of beatData in the SQL. Though this is affected by speed changes, so perhaps it is a speed multiplier (zeroTime / 0x405e… = speed adjustment?).
• "startTime" isn't affected by speed adjustments. I suspect this denotes the starting position of the beatgrid on the waveform, relative to 0x405e0…. Whatever startTime is, "countdown" reliably runs up to that number when playback reaches the end of the track.
• "playhead", in the video example, reaches 0x416de17000000000, which is bytes 8-15 of beatData in the SQL for the example track. Other tracks may be higher or lower depending on track length. Starting to get sensible numbers by XORing playhead & one of startTime or reference zero (0x405e…).
• As far as the beatgrid goes, I hypothesize that it starts at startTime ^ referenceZero(0x405e0..), then is drawn based on something like (60 / track BPM * speed modifier). So if a 120bpm track was playing at quartzlock, it would create a 'beat' every .5 seconds (60 / 120 * 1). If you increased the speed fader to +10%, it would draw a new beat every .45 seconds.

[PeteTheVolcano]

Honusz, this is REALLY cool work here. Would be a lot of work, but there's a huge market for people trying to drive their LEDs to the beat... like with WLED and continued evolution of your work + ability to mod effects... man, that will be the day.

[dzelionis]

Honusz, this is REALLY cool work here. Would be a lot of work, but there's a huge market for people trying to drive their LEDs to the beat... like with WLED and continued evolution of your work + ability to mod effects... man, that will be the day.

Agree, there is still plenty of space for all different lighting ideas....even soundswitch is handling wled pretty well atm. still things like synchronizing bpm with resolume (resolume stageLinQ implementation has some bugs) or pangolin beyoind (has now stageLinQ implementation) - that's where all this reverse engineering has a positive impact :D

check this out:
https://wled.discourse.group/t/dmx-effect-mode-refactoring-beta-testing/6498/34

[dzelionis]

Hey, Thats what i have:

tcp = self.services["BeatInfo"]
        while True:

            data = tcp.recv(152)
            h = data.hex()
            #print(h)
            part_list = [
                h[0:8], #0 Packet Lenght 
                h[8:16], #1 id 0x2
                h[16:32], #2 Clock
                h[32:40], #3 ????
                h[40:56], #4 Player1 Current position time
                h[56:72], #5 Player1 end time
                h[72:88], #6 Player1 Pitch ?
                h[88:104], #7 Player2 Current position time
                h[104:120], #8 Player2 end time
                h[120:136], #9 Player 2 Pitch ?
                h[136:152], #10 Plater 3 Current posstion 
                h[152:168], #11 Player 3 end time
                h[168:184], #12 Player 3 Pitch ?
                h[184:200], #13 Plater 4 Current Position Time
                h[200:216], #14 Player 4 end time
                h[216:232], #15 Player 4 Pitch ?
                h[232:248], #16 Player 1 ?
                h[248:264], #17 Player 2 ?
                h[264:280], #18 Player 3 ?
                h[280:296], #19 Player 4 ?

            ]

sample output ( the ones with B letter is already parsed as UBInt64 and rounded a bit...):
2[00009909107cb67a] 3[00000004] B4[13809153234] B5[4646339459] 6[405ccccccccccccd] 7[40751fa32a5986e0] 8[40751fa32a5986e0] 9[4061e40b9a800000] 10[0000000000000000] 11[4081cedde060b1fd] 12[406476eed18ae141] 13[405b0fffffffffff] 14[4070a5c80c983161] 15[4058406100000001] B16[4675548496] 17[415b1b0000000000] 18[40df22eec0000000] 19[41468da3b8be0545]

[dzelionis]

Hey, I just still playing arround, definetly i am not in the position i which i need to be....as i doing some custom python scripts for controling my lightning at home....which includes soundswitch + resolume + pagolin beyond + wled....so sound switch alone is not good enought for me...as it does not work great with idividual adressable leds....i have tryed to use ableton link for my need ... but again its just not good enought for what i need....so only option is to have stage linq decoded and have all the beat data flowing in to my python scripts....which would talk to resolume via api + talk to wled via api + to soundswitch via midi and to pangolin via byond tcp server :D so that's where i am currently...

[dzelionis]

By the way, you was mentrioning that there is some interesting data in db....i had a quic check and i did not find anything usable...i mean...fields witch has names anyway related to beat are containing no data....or i am missing something here ? i know for sure it should be a way to calculate it...as for example resolume has no database (i mean like soundswitch has it own database for each track) and it still see perfectly start time, end time, current posstion , time left, etc.....so we should get there at some stage....

[dzelionis]

i think i may have a clue.... check this out (on terminal its just packets lenght of all packets received + count of the packets every 1 sec), in general you just need to keep eye on the packet flow and not the info.... :
https://drive.google.com/file/d/1neFxT7v6HOrqzy7RKRpzahVdoo7K4kqu/view?usp=sharing

as some packets wireshark is clasifying as SMPP, not sure if thats correct but...still looks promissing...need to play more with that....

[honusz]

By the way, you was mentrioning that there is some interesting data in db....i had a quic check and i did not find anything usable..

The binary fields in the db are zlib compressed. You need to discard the first 4 bytes (ex: 00 00 00 8a), then zlib should be able to inflate it.
In beatData, the first 16 bytes are interesting, I suspect these are the start and end positions of the track.
40 e5 88 80 00 00 00 00 41 6d e1 70 00 00 00 00
No idea what the rest of the data is yet.

as some packets wireshark is clasifying as SMPP, not sure if thats correct but...still looks promissing...need to play more with that....

Yeah, I get the same thing, maybe 1/100 of the packets. I suspect this is an error (something in the occasional packet resembles SMPP) so I just disabled SMPP from the protocol list in Wireshark, then everything comes as TCP.

i think i may have a clue.... check this out (on terminal its just packets lenght of all packets received + count of the packets every 1 sec), in general you just need to keep eye on the packet flow and not the info.... :

Interesting, I hadn't thought to look at it like that. Do different tempo tracks (i.e. 165 bpm vs 120 bpm) have a different cadence of packet transmission? The only thing with being purely based on timing of packets is that the player still sends, as far as I can tell, the same frequency of packets whether the track is playing or not.

I made a reference track, which should work as a good standard candle and (in theory) keep the math simple.
It's 16 bars at 120 bpm, 48khz. The first beat starts exactly 1 second from the beginning of the file.

[dzelionis]

cool, anywy i have full time job....i guess you have one too....so sometimes its hard to find time...I think, good idea with reference track will try to play with that a bit too....and thanks for a tip on db as i am not a fan of sql....(i give preference to nosql db's) ...so i just saw empty field when was doing select....and i tought thats empty.... :D

[MarByteBeep]

You guys are awesome. I'm so sorry as I'm swamped with external work (fixing a roof leakage has a somewhat higher prio than this :)). But once I get things sorted out, I'll give this a look!

[dzelionis]

same here no free time atm...i hope to get some on the weekend....honusz, i have managed to inflate and unzip beatdata from db...so thaks for tips....

[dzelionis]

Thats my reason why i need StegeLinq into my python scripts:
https://drive.google.com/file/d/1IiUDrycsQZ4XKwqKvGImfXbyEi0491HS/view

[dzelionis]

Hi team, i have looked into quickCue data in database, and i found it for cues it is referencing field 16 if i do it on Player1,
so that makes me think that i was wrong regarding ref4 as it is not used for cue references. But i know for sure if i do ref5 -ref4 = it would be equal to 0 at the end of the track

            h[0:8], #0 Packet Lenght 
            h[8:16], #1 id 0x2
            h[16:32], #2 Clock
            h[32:40], #3 ????
            h[40:56], #4 Player1 Current position time (could be wrong name for it)
            h[56:72], #5 Player1 end time
            h[72:88], #6 Player1 Pitch ?
            h[88:104], #7 Player2 Current position time  (could be wrong name for it)
            h[104:120], #8 Player2 end time
            h[120:136], #9 Player 2 Pitch ?
            h[136:152], #10 Plater 3 Current posstion  (could be wrong name for it)
            h[152:168], #11 Player 3 end time
            h[168:184], #12 Player 3 Pitch ?
            h[184:200], #13 Plater 4 Current Position Time  (could be wrong name for it)
            h[200:216], #14 Player 4 end time
            h[216:232], #15 Player 4 Pitch ?
            h[232:248], #16 Player 1 I found it used for a reference position of the quickCues , i think thats could be a correct "current possiion" 
            h[248:264], #17 Player 2 same as one above
            h[264:280], #18 Player 3 same as one above
            h[280:296], #19 Player 4 same as one above

Any ideas ?

[dzelionis]

made python helper script to speed up reverse engineering, It may that you have some thing similar already, but if not you may find it handy...its takes track id as an imput and gives you back interesting fields from track database + creates folder for that track id and inflates and unzips all the interesting data blobs, screenshot: https://i.imgur.com/3xTd3eT.png

script:
https://drive.google.com/file/d/1uHVcUpZld0AQ2kLW37D1VidXnPCAimWw/view?usp=sharing

[dzelionis]

I think i have some progress, let's take a clock as an example, if i take 16bits clock curent value - last value, i am geting 35ms, if record for clock for 10 secs and i take current and last recorded value i getting ~10s, i still think i missing some frames, but anyway thats look correct thing to do....

same applays for different stufff....
so if i apply same logics to ref4 and ref16:
ref4_diff = ref4 current - ref4 last
ref16_diff = ref16 current -ref16 last
and then
ref16_diff - ref_4 diff = result looks like phase as exmple last 4 number was 4,1,-4,2

I have looked up into ableton link source code, and it sounds very similar what we need to do...i don't understand it fully but we may spend more time ther and see.....

ableton-link bpm formula:
inline Float64 ABLLinkBpmInRange(
const Float64 fromBeat,
const Float64 toBeat,
const UInt32 numSamples,
const Float64 sampleRate) {
return (toBeat - fromBeat) * sampleRate * 60 / numSamples;
}

so have to take a break a bit as have some other stuff to work on.....so i park it here...for now

[dzelionis]

I cracked it:
https://i.imgur.com/SH9ObDQ.png

                h[0:4], #0 
                h[4:12], #1 
                h[12:28], #2 
                h[28:36], #3 
                h[36:52], #4 
                h[52:68], #5 
                h[68:84], #6 
                h[84:100], #7 
                h[100:116], #8 
                h[116:132], #9
                h[132:148], #10 
                h[148:164], #11 
                h[164:180], #12 
                h[180:196], #13
                h[196:212], #14 
                h[212:228], #15 
                h[228:244], #16
                h[244:260], #17
                h[260:276], #18 
                h[276:292], #19
          

            ds.append(unpack('>i', load_bytearray(p[0]))) #0 unsigned int 4 - Packet Lenght
            ds.append("")                                                    #1 0x2
            ds.append(unpack(">Q",load_bytearray(p[2]))) #2 unsigned long 8  - Clock
            ds.append("")                                                    #3 still un-known 
            ds.append(unpack(">d",load_bytearray(p[4]))) #4 float 8 - Player 1 - Beat
            ds.append(unpack(">d",load_bytearray(p[5]))) #5 float 8 - Player 1 - total Beats
            ds.append(unpack(">d", load_bytearray(p[6]))) #6 float 8 - Player 1 - BPM
            ds.append(unpack(">d", load_bytearray(p[7])))  # 7 float 8 - Player 2 - Beat
            ds.append(unpack(">d", load_bytearray(p[8])))  # 8 float 8 - Player 2 - total Beats
            ds.append(unpack(">d", load_bytearray(p[9])))  # 9 float 8 - Player 2 - BPM
            ds.append(unpack(">d", load_bytearray(p[10])))  # 10 float 8 - Player 3 - Beat
            ds.append(unpack(">d", load_bytearray(p[11])))  # 11 float 8 - Player 3 - total Beats
            ds.append(unpack(">d", load_bytearray(p[12])))  # 12 float 8 - Player 3 - BPM
            ds.append(unpack(">d", load_bytearray(p[13])))  # 13 float 8 - Player 4 - Beat
            ds.append(unpack(">d", load_bytearray(p[14])))  # 14 float 8 - Player 4 - total Beats
            ds.append(unpack(">d", load_bytearray(p[15])))  # 15 float 8 - Player 4 - BPM
            ds.append(unpack(">Q", load_bytearray(p[16])))  # 12 unsigned long 8 - Player 1 - TimeLine
            ds.append(unpack(">Q", load_bytearray(p[17])))  # 13 unsigned long 8 - Player 2 - TimeLine
            ds.append(unpack(">Q", load_bytearray(p[18])))  # 14 unsigned long 8 - Player 3 - TimeLine
            ds.append(unpack(">Q", load_bytearray(p[19])))  # 15 unsigned long 8 - Player 4 - TimeLine

Or in json format:
data_bit_map = {
"clock": unpack(">Q", load_bytearray(p[12:28]))[0],
"player1": {
"beat": unpack(">d", load_bytearray(p[36:52]))[0],
"beatTotal": unpack(">d", load_bytearray(p[52:68]))[0],
"bpm": unpack(">d", load_bytearray(p[68:84]))[0],
"timeline": unpack(">Q", load_bytearray(p[228:244]))[0]
},
"player2" : {
"beat": unpack(">d", load_bytearray(p[84:100]))[0],
"beatTotal": unpack(">d", load_bytearray(p[100:116]))[0],
"bpm": unpack(">d", load_bytearray(p[116:132]))[0],
"timeline": unpack(">Q", load_bytearray(p[244:260]))[0]
},
"player3" : {
"beat": unpack(">d", load_bytearray(p[132:148]))[0],
"beatTotal": unpack(">d", load_bytearray(p[148:164]))[0],
"bpm": unpack(">d", load_bytearray(p[164:180]))[0],
"timeline": unpack(">Q", load_bytearray(p[260:276]))[0]
},
"player4": {
"beat": unpack(">d", load_bytearray(p[180:196]))[0],
"beatTotal": unpack(">d", load_bytearray(p[196:212]))[0],
"bpm": unpack(">d", load_bytearray(p[212:228]))[0],
"timeline": unpack(">Q", load_bytearray(p[276:292]))[0]
}
}

[dzelionis]

some_refertences_of_equations_from_link.txt

[dzelionis]

@honusz did you had some plans for Beatinfo ? :D i still need goof bit of work to put in to get stuff to the level you guys have done on javascript... i dont even have StageMap(thats also semi critical) yet :D but for my project beatinfo is critical so i really glad that we got so far, and all the work you did, it made way easier for me to just jump in and try :D if you know what i mean.....

[honusz]

Hey @dzelionis , sorry for the delayed reply. I kept putting it off until I had a chance to fiddle with the concepts in JS.

did you had some plans for Beatinfo ? :D
No, not really, lol It was mostly just to further understanding of the protocol, knowing that it would be useful to someone, and I'm certainly glad that it has been useful for you! :)
For a project like this, you never really know what end-users are going to need. A lot of the initial interest in StageLinq was from people wanting to generate artist-track overlays for livestreams. Personally, I just believe if you spend thousands of dollars on a device, you deserve to be able to use it to it's full potential.

I'm really interested in what you're working on. I work professionally as a rigging gaffer in film & television, so DMX and lighting control is right in my wheelhouse. And my basement is also synced up (via hue) to be a sound reactive dance cave, which got me and some friends through the clubs being closed, lol.
My current project involves some wall washing up-lights (ws2812 or apa102) that will do a spectrum analyzer type effect. It's very early stages though.

[dzelionis]

i have few more demos on my visualiation stuff, if you interested you can check it out.....
https://drive.google.com/drive/folders/1wTOyHKRTKP8_p7d73bdmYTKmweb978kM?usp=sharing

My end visison is that i would have automated symphony.....

[dzelionis]

@honusz, are you using wled for ws2812 ? if not i would recomend you to check that you.... it really rich in features + API etc

[dzelionis]

I was able to calculate correct beat phase, using as input current beat value, and quantum = 4: and then to make it more readable you can feed that value into calc_phase_str

def to_micros(self,value):
    return round(value * 1e6)

def calc_phase(self,beats, quantum):
    quantumMicros = self.to_micros(quantum)
    quantumBins = int((abs(self.to_micros(beats)) + quantumMicros) / quantumMicros)
    self.quantumBins = quantumBins
    quantumBeats = quantumBins * quantumMicros
    return round((beats + quantumBeats) % quantum)

def calc_phase_str(self):
    phase_str = ''
    for x in range(0, 4):
        if x < self.phase:
            phase_str += 'X'
        else:
            phase_str += '0'
    return phase_str

also current time and end time calculations:

def calc_endtime(self, in_micros=True):
    microsPerBeat =60. * 1e6 / self.bpm
    mictosTotalTillEnd = self.beatTotal * microsPerBeat
    if in_micros:
        return mictosTotalTillEnd
    else:
        return str(datetime.timedelta(microseconds=mictosTotalTillEnd))

def calc_timeleft(self, in_micros=True):
    endtime = self.calc_endtime()
    microsPerBeat = 60. * 1e6 / self.bpm
    currposmicros = microsPerBeat * self.beat
    timeleft = endtime -  currposmicros
    if in_micros:
        return timeleft
    else:
        return str(datetime.timedelta(microseconds=timeleft))

[mhite]

I was able to calculate correct beat phase, using as input current beat value, and quantum = 4: and then to make it more readable you can feed that value into calc_phase_str

@dzelionis - I'm feeling dumb here but what do you mean by "beat phase"?

[dzelionis]

[dzelionis]

[dzelionis]

does what make sense? just run a code i share yesterday and you can see it in action ( i have packed all files which you need to get it running)

[mhite]

@dzelionis - Ok, will get your code going and try to learn more! I also started looking at the "Phase Synchronization" section of the Ableton Link document which provides a high level explanation (I think?).

https://ableton.github.io/link/

[dzelionis]

if i take a diff of beat time (current packet - one before) and plot it i get some interesting data, not sure does that means anything but maybe its more stuff encoded into that, as i can see some paterns (bottom line in the graph is my calculated phase):

[honusz]

hmmm, could the pattern just be related to cycles on the CPU of the controller? Perhaps there is a blocking process that's affecting the interval of the beatInfo messages being calculated and dispatched.
Does playing two or more tracks concurrently have any affect on the timing?

[dzelionis]

you could be right, but still , from what i can see frame rate of packets is really consistent, so i don't think it caused by blocking state. And even if it was, you still may draw more steady line i think. You dont need to constnly speed up and slow down to keep it at same level if you get what i mean....lets take simple example.....:

• lets say you have total 20secons so you couold use 2 packet per second so you could 2 + 2 + 2 + 2 + 2+ 3(in case it got out of synh and you need speed up)+ 2 +2 2+ .....
• and what i see stageLinq is doing if we use same exmple: 1+ 2+ 3+ 1+ 2+ 1+ 3+ 1+ 3+ 2+ 1+
  also, so from a graph we can clearly see base line...
  Its could be meaning nothing....but you never know....
  One of the possible root causes of that i can see tcp windowing... but i dont think thats should impact us to much as we not sending big frames...(by the way, in real life i am senior network engineer ;D )
  Anyway, is something to brain storm a bit when you have nothing to do.....

[dzelionis]

Hey guys, i have already managed to do 10+ re-packed firmware updates for my prime4 :D still not finished fully breaked in, as having some difficulties with debuging port, as its only giving me the output from console but does not take my input back, so its bit hard to do all changes i need, only inside firmware (not having terminal input) and reflash it.....but i am getting there :D and when i will be there, we could see it from inside :D

[icedream]

@chrisle You have no idea how frustrated I am that I was able to get all sorts of software up and running but Doom (at least chocolate-doom) somehow only gave me headaches so far lol. It really does not want to cooperate with the Mali GPU on this…

[erhan-]

Yes, you both and @dzelionis should work together, great guy. I should have posted the links here earlier but I thought everyone is aware already. This will get quite attention when you have the usual Doom poc. You could already give a hint to djtechtools if you want to. It will spread from there (but also to Denon unfortunately). Let's see where this takes us.

[icedream]

I was hoping to at least get away from basing on the Denon-provided firmware (and especially their update tool) before I spread the word to everyone, for legal reasons of course. Once I am able to provide my own updater I will immediately delete the one I've already built and replace it.

Definitely gonna continue working on getting Doom running, but currently Mixxx got the priority, also because I want to see how far I can get with buildroot in regards to building the rootfs from scratch instead of relying on the firmware.

[dzelionis]

agree, would be handy to be able to build system from a scratch, as example (not related) project https://github.com/Freetz-NG/freetz-ng is approaching its scope correctly, and eventually, we should be in the exact same position. This project is for upgrading FritzBox Router with a custom firmware and to make it happen it would take latest original firmware, then using builidroot etc, you can do menuconfig and add/remove additional kernel features and add/remove additional software packages and then will it will build a firmware for you which includes not modified web interface to vendors gui, and additional web service which has additional configurations/settings for apps you have selected....etc...this approach is ideal i think.
Firmware is made for arm...so we may take something from this project as alot of components would fit...

[dzelionis]

Heads up that we have been able to create a SSH firmware for the Prime4 so exploration is much easier now. See https://github.com/icedream/denon-prime4 (and the releases section for the actual firmware)

Nice, Thanks

[mhite]

No super magic here; just connect to the BeatInfo port given by the player in the service request, send an 8 byte request (0x0000000400000000), and the deluge of BeatInfo messages starts coming.

Just poking around on my Prime 4 to see if I could get BeatInfo to respond. Has anyone tried this on a Prime 4?

I was trying this:

echo -en '\x0\x0\x0\x4\x0\x0\x0\x0' | netcat 192.168.68.198 39619

... where 39619 is the BeatInfo port on the Prime 4.

Alas I only get the TCP ACK back, but no data response.

Hopefully I'm missing something obvious?

[honusz]

@mhite The device won't respond unless you've first sent a discovery message announcing yourself on port 51337.

[mhite]

Hmmm. I've tried that, too. I'm using @icedream's library to send an hello/howdy announce every 1s.

[dzelionis]

Far as i remenber you need to have some delay in between service request and sending (0x0000000400000000)

…

On Tue, Sep 27, 2022, 07:02 Matt Hite ***@***.***> wrote: Hmmm. I've tried that, too. I'm using @icedream <https://github.com/icedream>'s library to send an hello/howdy announce every 1s. — Reply to this email directly, view it on GitHub <#12 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ67VUKM5TOUPFBUYMRZH4LWAKEXFANCNFSM5MS6CGOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dzelionis]

Looking at @dzelionis code snippet, I can see my issue. I didn't perform the "in-protocol" service request (as seen in his CreateDataForServiceSubscription function) prior to sending the 0x0000000400000000 sequence.

Correct, you have to subscribe first then delay and then only send 0x0000000400000000. I just tested it this evening, also video i have shared is fresh too...

[mhite]

Looking at @dzelionis code snippet, I can see my issue. I didn't perform the "in-protocol" service request (as seen in his CreateDataForServiceSubscription function) prior to sending the 0x0000000400000000 sequence.

Correct, you have to subscribe first then delay and then only send 0x0000000400000000. I just tested it this evening, also video i have shared is fresh too...

@dzelionis - Excellent. I've added this and now I see the firehose! I'm definitely playing catch up with both you and @honusz on this little project so thank you for your patience and getting me this far.

[dzelionis]

when you get data decoded, then you will need to do some calculations to get phase...etc...basically, i have reverse-engineered AbletonLink to understand how all the calculations is done and reused the same formulas to get all fancy beat/phase data...
Here is the main code with all the formulas....Sorry, its not so clean and readable, but still would be usable....Have fun!

from MyClass import *
from log import *
from struct import unpack
from myByteBuffer import load_bytearray
from ReadContext import *
#from controller import smap
from StateMap import sData
from time import time_ns
import datetime
from json import loads

import re

def render_bit_map(raw_data):
    p = raw_data
    data_bit_map = {
        "clock": unpack(">Q", load_bytearray(p[8:24]))[0],
        "player1": {
            "beat": unpack(">d", load_bytearray(p[32:48]))[0],
            "beatTotal": unpack(">d", load_bytearray(p[48:64]))[0],
            "bpm": unpack(">d", load_bytearray(p[64:80]))[0],
            "timeline": unpack(">Q", load_bytearray(p[224:240]))[0]
        },
        "player2": {
            "beat": unpack(">d", load_bytearray(p[80:96]))[0],
            "beatTotal": unpack(">d", load_bytearray(p[96:112]))[0],
            "bpm": unpack(">d", load_bytearray(p[112:128]))[0],
            "timeline": unpack(">Q", load_bytearray(p[240:256]))[0]
        },
        "player3": {
            "beat": unpack(">d", load_bytearray(p[128:144]))[0],
            "beatTotal": unpack(">d", load_bytearray(p[144:160]))[0],
            "bpm": unpack(">d", load_bytearray(p[160:176]))[0],
            "timeline": unpack(">Q", load_bytearray(p[256:272]))[0]
        },
        "player4": {
            "beat": unpack(">d", load_bytearray(p[176:192]))[0],
            "beatTotal": unpack(">d", load_bytearray(p[192:208]))[0],
            "bpm": unpack(">d", load_bytearray(p[208:224]))[0],
            "timeline": unpack(">Q", load_bytearray(p[272:288]))[0]
        }
    }
    return data_bit_map


@dataclass
class TimeLine(MyDataClass):
  tempo : float = 0
  beatOrigin : float = 0
  timeOrigin: int = 0

@dataclass()
class TwoValueBuffer():
    buff: list = field(default_factory=list, repr=False)

    def __post_init__(self):
        self.buff = [0,0]

    def add(self, value):
        self.buff.pop(1)
        self.buff.insert(0,value)

    def __str__(self):
        return self.buff[0]

    def __repr__(self):
        return self.buff[0]

@dataclass
class Beats(MyDataClass):
    mValue: int


    def _post_init_(self):
        pass

    def Beat(self,beats):
        if type(beats) == float:
            self.mValue = round(beats * 1e6)
        else:
            self.mValue = beats



@dataclass
class playerDataRaw(MyDataClass):
    id: int
    phase: float = 0
    phase4str: str = ""
    phase4buff: list = field(default_factory=list, repr=False)
    phase8str: str = ""
    phase8buff: list = field(default_factory=list, repr=False)
    phase16str: str= ""
    phase16buff: list = field(default_factory=list, repr=False)
    beat: float = 0
    beat_last: float = 0
    beat_buff: list = field(default_factory=list, repr=False)
    beat_diff_buff: list = field(default_factory=list, repr=False)
    beat_diff: float = 0
    beatTotal: float = 0
    bpm: float = 120
    bpm_buff: object = field(default_factory=object, repr=False)
    count: int = 0
    timeLine: int = 0
    timeLine_last: int = 0
    timeLine_diff: int = 0
    buffer: list = field(default_factory=list, repr=False)
    buffer_max: int = 512
    start_time: int = 0
    time_left: int = 0
    time_left_str: str = ""
    end_time: int = 0
    clock: int = 0
    quantumBins: int = 0

    def _make_player_name(self,id):
        return f'self.p{str(id)}'

    def reset(self):
        self.timeLine_last = 0
        self.timeLine = 0
        self.buffer = []
        self.beat_buff = []
        self.beat_diff_buff = []
        self.beat_last = 0
        self.beat_diff = 0
        self.count = 0
        self.beatTotal = 0
        self.beat = 0
        self.bpm = 120
        self.bpm_buff = TwoValueBuffer()
        self.phase4buff = TwoValueBuffer()
        self.phase8buff = TwoValueBuffer()
        self.phase16buff = TwoValueBuffer()
        self.start_time = 0
        self.time_left = 0
        self.time_left_str = ""
        self.end_time = 0

    def start(self):
        self.reset()
        self.start_time = self.clock

    def __post_init__(self):
        self.bpm_buff = TwoValueBuffer()
        self.phase4buff = TwoValueBuffer()
        self.phase8buff = TwoValueBuffer()
        self.phase16buff = TwoValueBuffer()

    def to_micros(self,value):
        return round(value * 1e6)

    def calc_phase(self,beats, quantum, as_string=False):
        quantumMicros = self.to_micros(quantum)
        quantumBins = int((abs(self.to_micros(beats)) + quantumMicros) / quantumMicros)
        self.quantumBins = quantumBins
        quantumBeats = quantumBins * quantumMicros
        phase = round((beats + quantumBeats) % quantum)
        if as_string:
            return self.calc_phase_str(phase,quantum)
        else:
            return phase

    def calc_phase_str(self, phase, quantum):
        phase_str = ''
        for x in range(0, quantum):
            if x < phase:
                phase_str += 'X'
            else:
                phase_str += '0'
        return phase_str

    def calc_endtime(self, in_micros=True):
        microsPerBeat =60. * 1e6 / self.bpm
        mictosTotalTillEnd = self.beatTotal * microsPerBeat
        if in_micros:
            return mictosTotalTillEnd
        else:
            return str(datetime.timedelta(microseconds=mictosTotalTillEnd))

    def calc_timeleft(self, in_micros=True):
        endtime = self.calc_endtime()
        microsPerBeat = 60. * 1e6 / self.bpm
        currposmicros = microsPerBeat * self.beat
        timeleft = endtime -  currposmicros
        if in_micros:
            return timeleft
        else:
            return str(datetime.timedelta(microseconds=timeleft))

    def append(self, raw_data):
        data = self._parse(raw_data,self.id)
        #data = self._parse(raw_data, 2)
        self.clock = data[1]
        data = data[0]
        self.beat = data['beat']
        self.beatTotal = data['beatTotal']
        self.bpm = data['bpm']
        self.bpm_buff.add(data['bpm'])
        self.timeLine = data['timeline']
        self.update_buffer()
        if len(self.buffer) >= 2:
            self.timeLine_last = self.buffer[1]
            self.timeLine_diff = self.timeLine - self.timeLine_last
        self.update_beat_buffer()
        self.phase = self.calc_phase(self.beat, 4)

        phase4 = self.calc_phase(self.beat, 4, as_string=False)
        self.phase4buff.add(phase4)
        self.phase4str = self.calc_phase_str(phase4, 4)
        phase8 = self.calc_phase(self.beat, 8, as_string=False)
        self.phase8buff.add(phase8)
        self.phase4str = self.calc_phase_str(phase4, 8)
        phase16 = self.calc_phase(self.beat, 16, as_string=False)
        self.phase16buff.add(phase16)
        self.phase16str = self.calc_phase_str(phase16, 16)
        self.phase8str = self.calc_phase(self.beat, 8, as_string=False)
        self.phase16str = self.calc_phase(self.beat, 16, as_string=False)
        if len(self.beat_buff) >= 2:
            self.beat_last = self.beat_buff[1]
            self.beat_diff = self.beat - self.beat_last
            #self.beat_diff_buff.append((self.phase,round(self.beat_diff * 1e4)))
        self.end_time = self.calc_endtime(in_micros=False)
        self.time_left_str = self.calc_timeleft(in_micros=False)
        self.count += 1

    def update_buffer(self):
        self.buffer.insert(0,self.timeLine)
        if len(self.buffer) > self.buffer_max:
            last_index = len(self.buffer) - 1
            self.buffer.pop(last_index)


    def update_beat_buffer(self):
        self.beat_buff.insert(0, self.beat)
        if len(self.beat_buff) > self.buffer_max:
            last_index = len(self.beat_buff) - 1
            self.beat_buff.pop(last_index)


    def _parse(self, raw_data, id):
        data = render_bit_map(raw_data=raw_data)
        data.pop("player4")
        data.pop("player3")
        #print(id, data)
        #print(self.to_tuple())
        return (data[f'player{str(id)}'], data['clock'])

    def render_for_output(self):
        data = self.to_dict()
        #output = {}
        output = []
        data.pop("buffer")
        id = data.pop("id")
        data.pop("beat_buff")
        for key in data.keys():
            value = data[key]
            output.append((key, value))
        #output[f'Player{id}'] = tmp_list
        return output


@dataclass
class clockRaw(MyDataClass):
    clock: int = 0
    count: int = 0
    clock_last: int = 0
    clock_diff: int = 0
    buffer: list = field(default_factory=list,repr=False)
    buffer_max: int = 512
    last_error: str = ""

    def append(self, raw_data):
        clock = self._parse(raw_data)
        self.clock = clock
        self.buffer.insert(0,clock)
        if len(self.buffer) > self.buffer_max:
            last_index = len(self.buffer) - 1
            self.buffer.pop(last_index)
        if len(self.buffer) >=2:
            self.clock_last = self.buffer[1]
            self.clock_diff = self.clock - self.clock_last
        self.count += 1


    def _parse(self, raw_data):
        data = render_bit_map(raw_data)
        return data["clock"]

    def render_for_output(self):
        data = self.to_dict()
        output = []
        data.pop("buffer")
        #id = data.pop("id")
        for key in data.keys():
            value = data[key]
            output.append((key, value))
        #output["Clock"] = tmp_list
        return output


@dataclass(order=True)
class PlayerState:
    playing: bool = False
    ExternalMixerVolume: float = 0
    faderPosition: float = 0
#    def __gt__(self, other):
#        if self.playing == True and other.playing == False:
#            return True
#        else:
#            if self.ExternalMixerVolume > other.ExternalMixerVolume:
#                return True
#            elif self.ExternalMixerVolume == other.ExternalMixerVolume:
#                if self.faderPosition > other.faderPosition:
#                    return True
#                else:
#                    return False
#            else:
#                return False

#    def __le__(self, other):
#        if self.playing == False and other.playing == True:
#           return False
#       else:
#           if self.ExternalMixerVolume < other.ExternalMixerVolume:
#               return True
#           elif self.ExternalMixerVolume == other.ExternalMixerVolume:
#               if self.faderPosition < other.faderPosition:
#                   return True
#               else:
#                   return False
##              return False



class BeatInfo():

    clock = object
    p1 = object
    p2 = object
    p3 = object
    p4 = object
    p1state = object
    p2state = object

    player_list = []
    tcp = object
    active_player = ""
    _on_beat_cb = []

    def __init__(self, player_count=3):
        self.clock = clockRaw()
        self.p1 = playerDataRaw(1)
        self.p2 = playerDataRaw(2)
        self.p1state = PlayerState()
        self.p2state = PlayerState()
        #self.p3 = playerDataRaw(3)
        #self.p4 = playerDataRaw(4)
        for i in range(1,player_count):
            #setattr(self, f"p{i}.id", i)
            #setattr(self, self.get_pName(i), playerDataRaw(i))
            self.player_list.append(self.get_pObj(i))
            sData.add_stateCB(self.stateCB)

    def get_pName(self, id):
        return f'p{str(id)}'

    def get_pObj(self,id):
        return getattr(self, self.get_pName(id))

    def load_bitstram(self, binstream):
        self.clock.append(binstream)
        for player in self.player_list:
            player.append(binstream)

    def get_state_value(self, id, vName):
        if 0 < id < 5:
            iName = f"EngineDeck{str(id)}"
            sinst = getattr(sData, iName)
            pinst = getattr(sinst, vName)
            if pinst:
                value = ""
                string = ""
                type = ""
                json = loads(pinst)
                if "type" in json.keys():
                    jtype = json['type']
                    if jtype in [1, 2]:
                        state = json['state']
                        return state
                    elif jtype in [0,10]:
                        value = json['value']
                        return value
                    else:
                        return False
                    #if "string" in json.keys():
                    #string = json['string']
             #   if "value" in json.keys():

              #  if "state" in json.keys():

    def find_active_player(self):

        p1playState = self.get_state_value(1, "PlayState")
        self.active_player = getattr(self, "p1")

    def add_beat_calback(self, f, q):
        self._on_beat_cb.append((f,q))

    def phare_state_key(self , key):
        rr = re.compile(r'\/\w+\/(\w+)(\d)(\/|)(\w+)')
        result = rr.match(key)
        if result:
            dev, id, tmp, func = result.groups()

            return (dev, id, func)

        return (False, False,False)

    def stateCB(self, id, key, value):
       #print()
        l.info(f'{id}, {key}, {value}')
        print()
        dev, id, func = self.phare_state_key(key)
        if dev == "Deck" and func == "Play":
            tmp_class = getattr(self, f'p{id}state')
            tmp_class.playing = value['state']
        elif dev == "Mixer" and func == "faderPosition":
            tmp_class = getattr(self, f'p{id}state')
            tmp_class.faderPosition = value['value']
    #       if key == "/Engine/Deck1/Play" 0,/Engine/Deck1/Play,{'state': True, 'type': 1}
        if dev == "Deck" and func == "":
            tmp_class = getattr(self, f'p{id}state')
            tmp_class.ExternalMixerVolume = value['value']
        #print(self.p1state > self.p2state)


    def onChangeTracking(self):
        p = self.active_player
        ### Bpm
        #print("on chgeck")
        #if p.bpm_buff[0] != p.bpm_buff[1]:
        for cb, q in self._on_beat_cb:
#            if q == 4 and self.p1.phase4buff.buff[0] == 0 != self.p1.phase4buff.buff[1]:
             if q == 4:
                 cb((self.p1.phase4buff.buff[0], self.p1.phase4buff.buff[1]))
 #           elif q == 8 and self.p1.phase8buff.buff[0] == 0 != self.p1.phase8buff.buff[1]:
             if q == 8:
                cb((self.p1.phase8buff.buff[0], self.p1.phase8buff.buff[1]))
  #          elif q == 16 and self.p1.phase16buff.buff[0] == 0 != self.p1.phase16buff.buff[1]:
             if q == 16:
               cb((self.p1.phase16buff.buff[0], self.p1.phase16buff.buff[1]))
   #         elif q == 0 and 0 == self.p1.phase4buff.buff[0] != self.p1.phase4buff.buff[1]:
             #cb((self.p1.phase4buff.buff[0],0))
             #cb((self.p1.phase4buff.buff[0],0))


    def render_for_output(self):
        output = {
            "Clock": self.clock.render_for_output(),
            "Player1": self.p1.render_for_output(),
            "Player2": self.p2.render_for_output(),
        }

        return output

    def read_stream(self, ss):

        while True:
            raw_data = ss.recv(4)
            size = unpack('>i', raw_data[:4])[0]
            if size != 0:
                break
        raw_data = ss.recv(size)
        data_hex = raw_data.hex()
        if len(data_hex) > 288:
            self.clock.last_error = f"size {len(data_hex)} more 288 "
        buff = load_stream(data_hex)
        if "00000002" != data_hex[0:8]:
            self.clock.last_error = f"unkonwn marker {data_hex[0:8]}"
            return False
        return data_hex

[dzelionis]

class BeatInfo(): is the main class all stuff would call from it....so start there..

Worker Thread:

bi = BeatInfo()
def BeatInfo_worker():
    headers = False
    while True:
        if ctrl.services["BeatInfo"] is None:
            sleep(0.2)
        else:
            if not headers:
                c.print_headers(["Clock", "Player1", "Player2"])
                headers = True

            data_hex = bi.read_stream(ctrl.services["BeatInfo"])
            #print(data_hex)
            bi.load_bitstram(data_hex)

            output = bi.render_for_output()
            c.print_data(output)

            bi.find_active_player()
            bi.onChangeTracking()


at = threading.Thread(target=BeatInfo_worker, args=())

to get on beat executions you subscribe to callbacks...

[mhite]

@dzelionis - Awesome. I'm sure I will have more questions once I dig further in! Thank you for your help.

[mhite]

Just going through the thread and the code to sketch out the latest understanding of the packet format a bit more formally. Does this look right?

u4be = 4-byte unsigned integer, big endian
u8be = 8-byte unsigned integer, big endian
f8be = 8-byte ieee float, big endian

[honusz]

@honusz - Ah! So for you, what bytes appear in the 4 bytes starting at position 16 (directly after the clock sequence)?

@mhite By jove! 0x0 0x0 0x0 0x2!

[mhite]

@honusz - Oh, nice! So then that is record count! (It's also the assumption I made in the code I developed.)

[mhite]

Also, I still don't understand the semantic meaning of some of the data in the BeatInfo message. Need to dig in and document this. For starters, is that clock value encoded in any "standard" way? About all I can tell at this point is that it's an ever-increasing value.

Seems clock is just the nanoseconds since device start.

[honusz]

Also, I still don't understand the semantic meaning of some of the data in the BeatInfo message. Need to dig in and document this. For starters, is that clock value encoded in any "standard" way? About all I can tell at this point is that it's an ever-increasing value.

Seems clock is just the nanoseconds since device start.

Yeah, that's it, probably the same value as timeAlive in the timeStamp messages, but would have to check.

[dzelionis]

on "clock", I think depends what is your scope, if you just trying to get beatinfo data from device and you not planning to do any synchronization with another device you can ignore it... as when i was reverse engineering ableton link code, had a feeling that clock is really important in it. but for my scope, i just need beat data for my lighting so it does not matter..

[mhite]

Ok, the next head scratcher for me -- what are these "Timeline" values? Are they really integers, or could they be floats? Is there a consensus on what these represent?

[honusz]

but elapsed time should be different depending on your speed (bpm) isn't ? so you need to take that in the calculation...

@dzelionis It depends on what you want to know. If you want to the actual playing time, you'd need to apply the tempo change as a multiplier.
The Denon units display the absolute track time, regardless of tempo change. E.g. If you set the pitch/tempo slider to +100%, the track time just runs twice as fast.

I believe the use of this value is to show where in the file the device is playing. So say if you were drawing a waveform that you wanted to follow while the track was playing, you'd use this value to set the progress. Samples are the easiest way to do this.

[honusz]

Could it also be the sample rate of the output the device is working with?

@icedream I'm pretty sure it's the file sample rate. If I jog the track up to 01:40 (100 seconds) on a 44.1k file, the value is 4410000.
I suspect whatever resampling, dithering, etc is taking place in some DSP-land that's way downstream from where StageLinq is operating on the device.

[honusz]

If I could offer a conjecture, I suspect the reason these sample fields are at the end of the message, rather than grouped by layer/player as the other values are, is because they were added afterwards.
I suspect this is beneficial for displaying scrolling waveforms. TimeCodeSync uses them, and I would bet if/when they have stacked waveforms across devices, this would be needed as well. Having this as a native value (instead of calculating it on the fly) keeps latency as low as possible.

[mhite]

I believe this is the current position of the track in samples, I'd have to double check.
If you divide it by the sample rate of the file, should give you the elapsed time in seconds

@honusz - Ah, did a few experiments and the theory holds up! 🥳

[dzelionis]

anyway, i know for sure, that using these:

def calc_endtime(self, in_micros=True):
    microsPerBeat =60. * 1e6 / self.bpm
    mictosTotalTillEnd = self.beatTotal * microsPerBeat
    if in_micros:
        return mictosTotalTillEnd
    else:
        return str(datetime.timedelta(microseconds=mictosTotalTillEnd))

def calc_timeleft(self, in_micros=True):
    endtime = self.calc_endtime()
    microsPerBeat = 60. * 1e6 / self.bpm
    currposmicros = microsPerBeat * self.beat
    timeleft = endtime -  currposmicros
    if in_micros:
        return timeleft
    else:
        return str(datetime.timedelta(microseconds=timeleft))

I am getting exactly the same values as denon is displaying on the screen, and it takes into calculation your current speed.

[mhite]

I wonder if there is "stop" command that can be sent to the BeatInfo service. Maybe some variation of the sequence we sent to initiate the stream?

Does anyone have packet captures of a "real" Stagelinq program hitting the BeatInfo service? Would be interesting to see if there is a "stop" sequence sent from client to server when shutting down the client application gracefully.

Also, @honusz comment about adding the timelines in a later protocol version made me think that the start sequence might also somehow encode a request for a BeatInfo stream of a certain protocol version.

If I could offer a conjecture, I suspect the reason these sample fields are at the end of the message, rather than grouped by layer/player as the other values are, is because they were added afterwards.

[honusz]

I wonder if there is "stop" command that can be sent to the BeatInfo service. Maybe some variation of the sequence we sent to initiate the stream?.....Would be interesting to see if there is a "stop" sequence sent from client to server when shutting down the client application gracefully.

There are DISCOVERER_EXIT_ messages that some programs send over UDP:51337. I don't think the players bother to do it.
I'm pretty sure the timeAlive messages are used for determining if a service is still connected. If those fail, the device probably forgets about you.

Does anyone have packet captures of a "real" Stagelinq program hitting the BeatInfo service?

Most of the programs I've come across (Resolume, TimeCodeSync, SoundSwitch) use it.
Nothing special to see, they're just absorbing the info from the players, there isn't really any data back to the player.
Actually instructing a StageLinq device to adjust the playback is done by the Syncing service I suspect.

[honusz]

Also, @honusz comment about adding the timelines in a later protocol version made me think that the start sequence might also somehow encode a request for a BeatInfo stream of a certain protocol version.

It would probably be on earlier device firmware, maybe even prerelease. Just to clarify, the reason I think they added these fields at the end of the message is so they wouldn't have to deal with versioning protocols. An earlier version of the protocol would just shift out the bytes it was expecting and function normally. If there's fields left in the buffer it would just ignore them, thus maintaining backwards compatibility.

[mhite]

That makes sense! 👍

[mhite]

It would also make a lot of sense if the "start beatinfo stream" message format looked like this:

Where the last 4 bytes ("command") represent the BeatInfo command being sent from client to server. In the case of start stream, the command is 0x00, 0x00, 0x00, 0x00.

Might be interesting to fuzz those last 4 bytes and see if there are any other commands the client can send.

[mhite]

Might be interesting to fuzz those last 4 bytes and see if there are any other commands the client can send.

It seems sending 0x00, 0x00, 0x00, 0x00 starts the stream and 0x00, 0x00, 0x00, 0x01 stops the stream. A start stream message must be sent before a stop stream message [obviously].

[dzelionis]

Hi Team, just something i have come across recently, but you may be aware of it already, anyway...
Was working on a networking project, where i needed to create and emulate traffic streams..For that, i have used Ostinato, but if you want an executable - you pay, if you compile it from the source it's free....So, while i was compiling i found out that it's using protobuf, and the definition for protobuf sounded very tasty:
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data
So i thought, need to find some examples of how to use that library for my python stagelinq implementation, as it would make my code way more structured. So, i thought that ArtNET protocol is popular enough and i might find some implementations of it using protobuf and then i came across some javascript application that looked like a sister of stageLinq, looking into code had such stuff like tokens, subscribe to service, file transfer, etc... so, it could be handy for you in some sense..here is the link https://github.com/topics/ubisoft-api?l=typescript
In case you have used protobuf in the past, tell me what you think about it.
Thanks
Dzelionis

[mhite]

@dzelionis - I've not played with protobuf directly. My understanding is that it is a standard for how data is serialized / deserialized on the wire, much like JSON or XML. It is extremely efficient and compact. It also looks like it would be significantly harder to reverse engineer without special analysis tooling given the specialized encoding. Thankfully -- from what I've seen thus far -- you can get pretty far analyzing Stagelinq with just Wireshark and a decent hex editor/viewer... and well, also plenty of trial and error!

But I think in the spirit of your discoveries and research, I have indeed wondered if Stagelinq is "built on top" of a generic transport framework. Or have they really invented their own bespoke protocol?

Also, Ostinato looks awesome!

[honusz]

@mhite have you seen this?

https://github.com/mixxxdj/mixxx/wiki/Engine-Library-Format#beatdata-format

[dzelionis]

@mhite have you seen this?

https://github.com/mixxxdj/mixxx/wiki/Engine-Library-Format#beatdata-format

I just wondering if they know that @icedream has a project for porting Mixx on denon hardware?. :D

[mhite]

@mhite have you seen this?

https://github.com/mixxxdj/mixxx/wiki/Engine-Library-Format#beatdata-format

@honusz - Yes! They have done an amazing job reversing engineering the library format. Super impressive.

I just wondering if they know that @icedream has a project for porting Mixx on denon hardware?. :D

@dzelionis - @icedream has a lot of projects! 🥇

[mhite]

@mhite @dzelionis believe me, we should all be very thankful StageLinq doesn't use protobuf. It's a reverse engineering nightmare.

A mobile game I used to hack switched to a protobuf like serializer. Unless your idea of fun is spending hours in IDA setting breakpoints, trying to find the serializers in memory. It's making me anxious just thinking about, lol

It's hard enough as it is even when you can decipher the ascii in wireshark.

I guess theoretically you can "reverse" a raw protobuf payload back out into something describing the structure.

https://stackoverflow.com/questions/7343867/raw-decoder-for-protobufs-format

Haven't tried it myself. Really have only done some simple experiments of compiling proto files into generated Go code.

[icedream]

@dzelionis I think they know 😄 mixxxdj/mixxx#4027 (comment)

That's a PR to implement the Denon Prime 4 mappings in Mixxx, and the project got mentioned there.

[mhite]

Somehow I forgot to mention it on this thread, but I put in a pull request to the @icedream library for BeatInfo support. There's an example app included in cmd/beatinfo/ that spits out the BeatInfo feed -- it would be great it some folks gave it a try!

Since it's not exactly obvious how one tests something like this, here's the quick-and-dirty guide on how to compile the PR:

clone it

$ git clone https://github.com/icedream/go-stagelinq/
Cloning into 'go-stagelinq'...
remote: Enumerating objects: 127, done.
remote: Counting objects: 100% (127/127), done.
remote: Compressing objects: 100% (69/69), done.
remote: Total 127 (delta 59), reused 109 (delta 41), pack-reused 0
Receiving objects: 100% (127/127), 176.56 KiB | 2.49 MiB/s, done.
Resolving deltas: 100% (59/59), done.

change dir

$ cd go-stagelinq/

fetch the pull request into local beatinfo branch

$ git fetch origin pull/19/head:beatinfo
remote: Enumerating objects: 18, done.
remote: Counting objects: 100% (18/18), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 11 (delta 6), reused 11 (delta 6), pack-reused 0
Unpacking objects: 100% (11/11), 4.42 KiB | 754.00 KiB/s, done.
From https://github.com/icedream/go-stagelinq
 * [new ref]         refs/pull/19/head -> beatinfo

checkout the local beatinfo branch

$ git checkout beatinfo
Switched to branch 'beatinfo'

update go dependencies to reference local beatinfo checkout

$ go mod edit -replace github.com/icedream/go-stagelinq=$PWD

inspect change

$ more go.mod
module github.com/icedream/go-stagelinq

go 1.15

require (
        github.com/stretchr/testify v1.6.1
        golang.org/x/text v0.3.4
)

replace github.com/icedream/go-stagelinq => /Users/mhite/lx/go-stagelinq

build beatinfo test app

$ go build -v ./cmd/beatinfo/
github.com/icedream/go-stagelinq
github.com/icedream/go-stagelinq/cmd/beatinfo

run it!

$ ./beatinfo 
2022/10/09 10:59:07 Listening for devices for 5s
2022/10/09 10:59:12 192.168.72.128 "testing" "Icedream StagelinQ Receiver" "0.0.0"
2022/10/09 10:59:12 	attempting to connect to this device...
....

I hope to continue to submit PRs for the other Stagelinq protocols once I get the first PR approved and merged!

[icedream]

May be able to take a look at it late into this weekend, though I'm unfortunately pretty busy handling IRL things since last week.

[mhite]

@icedream - That would be fantastic and much appreciated! 🙏

[mhite]

Oh, hey, @icedream merged the BeatInfo PR back in February.

I started playing around with Fyne and made a stupid "hello world" UI for the BeatInfo service. Here's a fugly animated GIF of the prototype!

[honusz]

Holy smokes this is dope! 😍 My head is buzzing with ideas, including a realtime waveform on stream.

Totally!
The waveform can be constructed either from using fileTransfer to retrieve the music file from the player, or if low res is acceptable, retrieving the overviewWaveFormData field from the database.

I was going to suggest that to @mhite , the overviewWaveform is a fixed width of 1024 fields where each field is 3x bytes. I'm not exactly sure of what each byte is, it's something like high/mid/low, but Engine uses them to render a stacked area chart to draw the overview waveform.

[jaygarcia]

This one is tough because the SC6000Ms suffer some serious performance issues. Some of which have been exacerbated by the recent updates. These issues include frame drops, and loading of databases across devices being really slow. :(

I have one main 6KM servicing 3 clients and with 100Mbs network interfaces, I can see things getting congested very quickly.

[honusz]

There's no reason it has to be done remotely.
You could copy the contents of your USB to a local folder on the machine running the lib, and just work on local files.

[mhite]

Thanks @honusz - looking forward to seeing what you've been working on!

@jaygarcia - Right now this little BeatInfo toy just uses the BeatInfo data stream which doesn't include anything other than what you see displayed already. At some point I'll wire up a UI to the normal StateMap service to make things a bit more interesting. As for waveforms, I haven't finished implementing the FileTransfer service in the Go StageLinq library. I started and need to pick it back up again if I want to mess with waveform stuff I think.

@honusz - Curious if in your tests you ran overviewWaveform through the decompress algo?

https://github.com/mixxxdj/mixxx/wiki/Engine-Library-Format#compression

Docs in the wiki seem to indicate the waveforms are stored in a compressed byte array format.

I need to get my head back into this, I miss brainstorming with ya'll!

[honusz]

@honusz - Curious if in your tests you ran overviewWaveform through the decompress algo?
Docs in the wiki seem to indicate the waveforms are stored in a compressed byte array format.

Indeed, the binary fields are zlib compressed.
I actually hadn't seen the wiki when I figured it out, I just popped the data from the field in to HexEd.it, and it's file format identification gave me some clue that led me to QT, and I gleaned how QT deals with writing binary data.

Here's the method I use:

import { inflate } from 'zlib'

async zInflate(data: Buffer): Promise<Buffer> {
    return new Promise((resolve, reject) =>{
      Inflate(data.slice(4), (err, buffer) => {
        if (err) {
          reject(err);
        } else {
          resolve(buffer);
        }
       });
    });
  }

I'll have to do a write up of the process with a bit more detail, but basically I had loaded the now-uncompressed data into a Google Sheet (which I usually use to try and find patterns in data), and I noticed the repeating 3-byte segments.
I playing around creating some different graphs of the data, and bam, one of them immediately looked almost exactly like the preview waveform.

[mhite]

Indeed, the binary fields are zlib compressed.
I actually hadn't seen the wiki when I figured it out, I just popped the data from the field in to HexEd.it, and it's file format identification gave me some clue that led me to QT, and I gleaned how QT deals with writing binary data.

Ok, cool! As usual you are 100 steps ahead of me. :)

[dzelionis]

@mhite , i can share my implementation if any use for you:

https://drive.google.com/file/d/1uHVcUpZld0AQ2kLW37D1VidXnPCAimWw/view?usp=share_link

[mhite]

@mhite , i can share my implementation if any use for you:
https://drive.google.com/file/d/1uHVcUpZld0AQ2kLW37D1VidXnPCAimWw/view?usp=share_link

Awesome, thank you! I hope to have some cycles to dive back in soon!

[dzelionis]

@honusz , hey dude...your project is starting to look very fancy + documented.....well done!!! Happy Easter!!!

[honusz]

@dzelionis haha, thanks! I'm going to make a thread and detailed post as soon as I have some free time this weekend.

[dzelionis]

@dzelionis haha, thanks! I'm going to make a thread and detailed post as soon as I have some free time this weekend.

On that thread, don't forget to say that you accept donations ;) as i think you well deserved it.

[jaygarcia]

@dzelionis haha, thanks! I'm going to make a thread and detailed post as soon as I have some free time this weekend.

On that thread, don't forget to say that you accept donations ;) as i think you well deserved it.

I asked for the same 😍. @honusz i would certainly donate as well!