These are chat archives for brunchboy/afterglow

21st
May 2017
James Elliott
@brunchboy
May 21 2017 00:04
I wonder why there is so much seemingly wasted space in the beat grid, and why it uses little-endian numbers for the times, when the other messages all use big-endian numbers. And why bother storing the 1,2,3,4,1,2,3,4 beat values in there at all when they are so predictable… very strange!
James Elliott
@brunchboy
May 21 2017 01:10
Also, @Busti, was your question answered? I remain curious what kind of project you are working on. :smile:
Moritz Bust
@Busti
May 21 2017 01:12
I did not attempt to implement it yet. I'll have access to another cDJ in two weeks though.
The project basically comes down to an Idea fo a graphical user interface I had for controlling lighting.
I should have done Mockup graphics for it. I guess I will do that tommorrow.
James Elliott
@brunchboy
May 21 2017 01:16
Cool! It’s really fun working on projects like this. I can’t wait to get CDJ waveforms scrolling along the top of my Ableton Push 2 controller which is running my Afterglow light shows, so I can see ahead of time what is coming up in the music.
Moritz Bust
@Busti
May 21 2017 01:17
I will inform you once I have the graphics done. I think that it might be interesting to you. ☺
Austin Wright
@awwright
May 21 2017 02:15
@brunchboy For the beat grid, it can start on any beat (1..4), and if you program a tempo change in Rekordbox, it's possible to skip beats or duplicate beats.
For the waveform, I think it's the 3 MSb are color (blue through white), and the 5 LSb are amplitude. There's also several bytes at the start and end that don't seem to be part of the track, I don't know what those mean.
James Elliott
@brunchboy
May 21 2017 15:46
Ah, ok, that makes sense about why the beat numbers are stored then, but there are still more than twice as many bytes in the structure as there seems to be a need for! As you said a few days ago, there seems to be a lot of accumulated cruft in the protocol. I’ve started updating the analysis document now that I have some working code, I hope to get an updated version pushed this weekend.
James Elliott
@brunchboy
May 21 2017 15:51
Now for the waveform, it sounds like you are saying it is not one byte per pixel, but rather one byte per segment? So each byte is a color, and the height of the waveform at that point? That makes a lot more sense. I wonder why I was getting 900 bytes for the summary, though, and why it was crashing my player? I need to do another capture to figure out what I got wrong in the request. You don’t happen to have any code that interprets the waveform that is shareable, do you? I couldn’t find anything like that looking through the libpdjl repository. But for now I have plenty to keep me busy documenting what I have already learned, and using the beat grid to generate MIDI timecode.
And thanks, Moritz, I bet it will be interesting to me.
James Elliott
@brunchboy
May 21 2017 16:48
Hey, @awwright, as I am writing the explanation of the different kind of field types, I just realized that the 0x10 kibble which we thought contained two values with a mysterious 0x0f in between them is probably actually two kibbles! 0x10 introduces a two-byte big-endian integer (the message type), and 0x0f introduces a one-byte integer (the argument count).
Austin Wright
@awwright
May 21 2017 18:02
@brunchboy I'm not sure what you mean by segment? More specifically, the waveforms use something like:
let value = value of next byte in waveform data
let colorRGB = ( value & 0b11100000, byte & 0b11100000 , 0xff );
let height = value & 0b00011111;
there's one byte per column of pixels to be drawn.
The waveform summary will be 300px, the entire waveform will be ~150 bytes (and pixels) per second of track.
James Elliott
@brunchboy
May 21 2017 18:24
Right, so when you say pixels there you mean columns of pixels. That’s what I was trying to get at with “segments”. :smile: