Session skip = no status update
samkuhn opened this issue · 16 comments
Thanks for this great little tool!
I've been playing around a bit and noticed that if I force-beat-at-time via Carabiner the link session skips as expected - but if I do this from another app the session skips but Carabiner doesn't send me a status message to reflect the change.
Is a status update supposed to be sent in this instance?
Hello, and thanks for the note! I’m not sure exactly what you mean. As far as I know, if you actually do change the timeline in your other app, Carabiner should notice and report that. But very few programs are willing to do that: Ableton strongly discourages it. I had to in Carabiner because CDJs are blissfully unaware of Ableton Link, and so they are quite happy to break the rules.
If your other app is just locally readjusting its notion of what beat is the current beat, which is what well-behaved Ableton Link applications do, there is no change to the underlying timeline for Carabiner to report.
Have you tried using Carabiner on another host to do its blunt force-beat-at-time and see if that gets reported?
Hi and thanks for getting back.
We've actually got a slightly unusual use case as we're sequencing visuals and using link to connect everything together. We use bpm detection (ios app connected to link) to sync up with a live DJ set and occasionally have to jump position to get the visuals back in time - causing a small flick in visuals but no real harm done since the audio isn't in the link session.
I can confirm that if I run two copies of my app (both connecting to carabiner) and post a force-beat-at-time message from one of them the other doesn't receive a status update. Even if I set enable-start-stop-sync beforehand in both copies.
Resolume Arena 6 and our other link apps all react to the force-beat-at-time sent from Carabiner, just not the other way round.. I haven't had a chance to dig into the code yet but could take a look when I have some free time.
Ah right.. the "another host" part has just sunk in. Trying that now!
I've tried running two copies of my app on different hosts with different instances of Carabiner. Sending "force-beat-at-time" from one doesn't cause a status update on the other, while sending "bpm" does.
Thanks for investigating this! I was suggesting trying to telnet to Carabiner running on another host and issue the command, but having your app do it would lead to the same result.
It sounds like you are very much on the right track in investigating this. If you can figure it out, a pull request would be most welcome. I don’t have any way of reproducing this here, nor any free time to work on Carabiner, unfortunately. And I don’t have any ideas what the problem might be, but thankfully there is not a lot of code to examine!
I will try to remember to re-learn the code and think about this more deeply when I have a chance, but if you can beat me to it, that would be even better. 😄
Thanks yep knee deep in it :)
What isn't clear to me is what's supposed to happen according to the link spec when forceBeatAtTime is called. Is there supposed to be a tempo callback or a start stop callback? There must be a callback as everyone would need to know about an event like that.. I've added a few debugging lines to Carabiner and neither of these callbacks gets invoked by link when the beat is forced.
Having trouble finding this info online.. thanks for your help will keep investigating.
Neither of those callbacks seem precisely appropriate. It would seem there should be a specific callback when the timeline is force shifted. We may be running up against a limitation of the Link protocol itself; this use case may not be properly supported.
(Or it may just be a gap in the documentation, since they don’t want to think about people doing this. 😉)
I saw your question in the Link repository, and it looked great. I am hoping that they come up with a good answer for you (which may even be a new release of the library).
…although I saw your phase followup as well, and you’re right about that. And I’m sorry I did not remember this, because I have worked on so many complicated implementations since then, but I had to do the same kind of periodic polling to align Beat Link Trigger to the Link phase. If I had remembered that properly, I could have saved you some research.
As a silver lining, it would be nicer if we did not have to poll to achieve this… perhaps your issue—even though you closed it—will persuade them to add a new callback.
It looks like you found another way to do what you need, shall we close this?
I’ll close this soon if there are no further thoughts.
Thanks for continuing to think about this - I haven't actually had a chance to revisit yet but will as soon as I get a chance. On re-reading my issue and followup on the link repo I'm actually not quite sure what I meant now. Haha anyway will take another look at things!
I am assuming this is safe to close, unless I hear more details by the end of the week.
Closing due to lack of actionable information.