Se Connecter:     

Forum: VirtualDJ Technical Support

Sujet: Extended OS2L parameters in VirtualDJ
I'm attempting to write my own lighting control synced to VirtualDJ. While taking a quite different path, it will fundamentally be quite similar to SoundSwitch, and, crucially for this question, require the same information (current songs playing, state of faders, etc.).

This is information that SoundSwitch today can receive from VirtualDJ. Looking at the communication between the two using Wireshark, it seems like they are using the OS2L protocol, but with some additions - the lighting control can send an 
{"evt": "subscribe", "trigger": ["...some VDJScript here..."]}
which then, when the value of the given VDJScript changes, receives an 
{"evt": "subscribed", "trigger": "..."}
from VirtualDJ.

Sadly, I haven't gotten further than that and have been unable to replicate the same in custom code, despite the messages being seemingly identical to what SoundSwitch sends. So I'd like to know if there is any sort of documentation about these additions to the OS2L protocol (even if it's just a few scribbled notes) and how to use them.

I've asked this question from your support however they just redirected me to ask this question here on the forum, so I hope that this'll get me an answer!
 
Posté Sat 09 Nov 24 @ 8:17 pm
Should indeed work like that, what did you send exactly? (perhaps the vdj script you tried has a bug?)
 
did you find a solution for this ? i get { evt: 'beat', change: false, pos: 21, bpm: 121.96, strength: 0.9 } only info like this
 
I found this post by accident this is awesome. I got it working and I'll post my code for others but it really needs a clean up first.

Are there any other undocumented OS2L evt's.... or parameters/tricks I should know about when subscribing?
 
New option in BUILD 8630 that wasn't in the build notes
setting os2lBeatOffset [ms]
 
That's interesting, OS2L only sends an update every beat so you have no idea of the exact track time. In my current OS2L server code I just continue counting but this adds complexity (was track paused, is it in a loop, etc).

I was going to attempt to send an update every millisecond using either repeat_start and sending an os2L_button command to the server or now that I know about this I could subscribe to it. However I guess I'm going to face the speed of the script engine? Makes me wonder if the delay will be the same between subscribing vs sending and OS2L command with repeat_start.

Would love to know if anyone had tested the expected latency on subscribing to these events.

Also if anyone knows of a way to unsubscribe that would also be handy, I tried the unsubscribe event but no luck.
 
Ran some tests myself, I subscribed to get_time elapsed and found there was 100ms between OS2L events.

However sending an OS2L command with repeat_start there's a 30ms delay, the delay of the script engine.