Add color_id for extended cue memory cues and loops

[ehendrikd]

Whilst integrating Create Digger based Rekordbox export media into Mixxx found that cue_extended_tag_t.color_code, cue_extended_tag_t.color_red, cue_extended_tag_t.color_green, cue_extended_tag_t.color_blue are correct for imported hotcues, however contained junk for memory cues and loops.

cue_extended_tag_t.color_id now gives a correct color table value, as used when also coloring tracks.

[brunchboy]

Thank you, this is very timely, as I am planning to do a release today! 😄

[brunchboy]

Are you sure this is only one byte? Everywhere else we have seen IDs, they are four bytes long.

[ehendrikd]

Could very well be four bytes long, I can double check and commit if needed. Might not be able to get to it in the next day if you intend to release soon.

Was thinking of also updating the other extended cue color field comments to state they are only for hotcues.

[brunchboy]

I can take a look myself, as well as updating the documentation (the big Antora site is even more important than within this file).

I’m not sure how we’ll be able to tell that there are multiple bytes there since the color table isn’t one we can expand, and it would be just as strange for this value to be little-endian (which it would have to be if it is four bytes long) when all the others are big-endian. So I think we can safely assume, as you did, that it is one byte but maps to a color row.

[brunchboy]

Looking at one of my own analysis files where I just assigned colors to some memory cues, it’s clear from the UI in rekordbox that these are coming from the color table as you say, and looking in the file, there is a 01 byte following the color ID byte, so it is definitely only one byte long.

[brunchboy]

Thanks again for reporting this. I only very recently purchased hardware that can display colors at all, so this has been a very unexamined corner of the file format for me.

[ehendrikd]

No problem. Was pleasing to be able to contribute something back to your existing hard work :)

[brunchboy]

This is what open source is all about! I’m delaying the release until I can figure out all the implications of this. I still have to figure out where this byte is found within the dbserver protocol message that sends one of these extended cues, and this affects three different projects, dysentery (the protocol documentation), crate digger itself, and beat link, which embeds crate digger. But tonight I am enjoying the Porter Robinson virtual music festival, Secret Sky. 😄

[brunchboy]

Found it! This byte is at offset 0x22 in the entry structure of extended cue list response messages from dbserver. Updating that section of the documentation now, and resuming preparations to release new versions of the libraries and Beat Link Trigger.