Update latency value via osc message

[jeffgca]

Is your feature request related to a problem? Please describe. Latency may vary depending on the specifics of the software and hardware being run on link, for example some hardware runs link. For any UI or app controlling Open Beat Control via OSC, it might be useful to update the latency value via an osc message, similar to the midi clock "offset" in the iOS "Link to MIDI" app.

/latency set 22 /latency get /latency stream

Describe the solution you'd like

When I'm debugging a CDJ + Link setup, i want to be able to play a simple loop on the pioneer hardware ( metronome, basically ) and a similar loop on the Link-enabled system and align them precisely by adjusting the latency, similar to the Link to MIADI iOS app:

https://www.dropbox.com/s/lri0cr0oeiw3whw/IMG_0672.jpeg?dl=0

Describe alternatives you've considered The only alternative is to guess the latency you need and repeatedly stop, start and test the latency to see if it sounds correct.

[brunchboy]

That’s an interesting idea, and wouldn’t be difficult, although I’m not yet convinced I want to add complexity to the OSC API for something that is mostly configure-and-leave-alone. This would be another good first issue for someone to try their hand at, though.

[jeffgca]

Thanks for responding so quickly @brunchboy! I take your point that this might be a good first issue however I don't know clojure or java that well so the initial learning curve is not something I relish. In case someone else finds this issue, I'll explain the use case further:

One of my key uses of Link is to synchronize a bunch of midi-enabled hardware on one side of a roon with an audio workstation running Live on the other side of the room. I accomplish this really well using the iOS Link to Midi app running on an iPad and connected to an iOS-friendly MIDI interface, however when I start working with this setup, I often need to tweak the latency setting on Link to Midi slightly in order to get the timing tight.

As I've been testing using open-beat-control to sync up my XDJs with Ableton running on a laptop, I have run into the same situation where I hear differences in alignment between the XDJs and Live, and it is time consuming to have to stop and then re-start the open-beat-control process when compared to how this works in the iOS app.

When using a laptop, this is why using the GUI for beat Link Trigger might be more convenient however my goal is to test this all working on dedicated hardware with control from a web app or physical buttons and knobs is interesting to me.

[brunchboy]

That’s cool @therealjeffg, I only tagged it that way in case anyone was watching and eager to dive in, not to specifically try and push you to solve it. 😄

I would like you to try to test my implementation for me though, as I don’t have a convenient way to send OSC messages right now. The preview just updated with a new jar that adds a /set-carabiner command that should let you do this dynamically. Here is the documentation: https://obc-guide.deepsymmetry.org/open-beat-control/messages#set-carabiner

Please let me know if this seems to work for you, and we can close the issue.

[brunchboy]

Also, I didn’t bother to set this up as a stream that reports changes, because the only way the value can change is if you change it yourself using this command.

[brunchboy]

@therealjeffg do you think you will be able to see if this is working for you? I’d like to close the issue if it is.

[jeffgca]

@brunchboy I apologize I've been meaning to get back to this.

I did some testing and am at a loss to tell if it works or not. When I run open-beat-control I set latency to 20 by default.

Calling

/set-carabiner latency 400

...neither raises an error nor does it seem to audible change synchronization. What should I expect?

My other comment is, osc servers can be multi-client so it might be useful to query the server to get it's currently configured state. I can fake this by going by maintaining the data in a second service that is also updated with the current running state whenever values change. I'm prototyping so it's just awkward, but a production system would need to work differently.

[brunchboy]

I would expect that you would be able to hear a difference. Perhaps you happened to hit on a multiple of the current tempo’s beat interval, which masked it? I guess I will try to set up an OSC client and do my own testing in order to close this.

I don’t quite understand what you mean about the value of querying, or trying to have multiple clients working with open-beat-control. I think that is getting fancier than I intend to support for this side-project of a side-project of a side-project, though, so while I would entertain a pull request to add this, I am unlikely to do so myself.

[brunchboy]

Ah! I bet I know what might have happened! The latency change will only have affected the synchronization if something changed with respect to the CDJs, causing a new message to be sent to Carabiner (for example, if you jumped to a different point in a track, or changed the tempo).

Probably I should force a new Carabiner synchronization whenever you change the latency. That would give you immediate results and feedback. I’ll look into that when I am not already up too late on a work night. 😄

[jeffgca]

Thank you very much for getting back to me James! [ @brunchboy ].

To be clear I was expecting instant audible feedback actually, again the use case is adjusting the latency value and listening because things aren't "quite" in sync.

To your earlier point about having a way to read the current state: based on my experience, not being able to query what the current latency value was, made debugging harder. It changed the question from "I set the latency value and nothing happened, the effective latency stayed the same", to "I think I set the latency value but when running audible tests with my own particular hardware setup I couldn't hear the difference" which is a lot more ambiguous.

I am happy to test the solution you're talking about where you force a new carabiner synchronization. I get that this is a side-side project, and also from my point of view I'm really just prototyping something.

[brunchboy]

Thank you for your patience! I’ve confirmed by a glance at the code that I had sent you on a wild goose chase because the latency change would not have an effect until some random point in the future where communication with Carabiner was necessary, so your attempts at testing were doomed. Nudging a tempo fader would have given you feedback, but you should not need to do that. It should be pretty easy to fix that, I hope to have another build available to you sometime today which does re-sync as soon as you change the latency, and if you do have a chance sometime to test with that I’d appreciate it. Otherwise I will try to find time to do so myself.

[brunchboy]

(And this was a simple oversight on my part because it’s been a while since I worked with that code.)

[jeffgca]

Awesome! I'll try to get some time to test the new build in the next couple of days, once it's available.

[brunchboy]

I take that back! Looking deeper at the code, it is correct, and will resynchronize with your new latency as soon as a beat packet is received from the player that is the tempo master. I tested it by setting up a numeric control in Max/MSP that would generate /set-carabiner latency n messages whenever its value changed, and once I had Open Beat Control running in bridge mode, a track playing on the CDJ, and LinkHut running so I could hear the metronome associated with the Ableton Link session, I was able to smoothly or abruptly adjust the latency, and hear the results immediately

Something must not have been hooked up or configured right in your testing? What was the exact scenario?

[brunchboy]

If I don’t hear confirmation that this is still a problem, along with a way to reproduce it, I am going to close this issue due to inactivity.