Deep-Symmetry/carabiner

question: is it normal that the server socket is bound on 127.0.0.1 ?

toxnico opened this issue · 12 comments

Description
Hello, I'm developing a program on ESP32 that connects to a carabiner instance running on a computer in the network.
But I'm facing an issue : carabiner's server socket is bound on localhost, and is unreachable from another device. I think it should listen to 0.0.0.0 (any address)

Potential solution
Would it be possible to add a command line parameter, in order to replace the default IP, and not only the port ?

Thanks for the good work !

Hello, @toxnico and welcome!

Unfortunately, it would be incorrect for Carabiner to bind on to port 0.0.0.0, because for the code to work, it needs to be running on the same machine as the code that is talking to it, so they have a shared time base (the system monotonic clock). Synchronization will not be correct otherwise. Once you are synchronized with the Link network by talking to Carabiner on the same host as your other software, then Link itself works properly in a distributed fashion to other hosts.

I had some language which suggested this requirement but did not spell it out enough in the README. I just updated it to be more explicit. Look for the sidebar titled “About Link Timestamps” near the middle. I’m sorry about the confusion!

Hi @brunchboy, thanks for these explanations, I now understand the fact that the system clock must be the same :)
Just to clarify the reason I was asking this : my project is to build a pocket wifi headphone adapter for drummers who want to join our live session (without needing a computer).
The adapter (ESP32) gets the bpm from Carabiner, syncs to the beat, and runs on its own clock.
Surely, it derives from the Link session, but I can realign it to the beat from time to time.

Thanks again for your clarifications, and I finally built a Carabiner version listening to 0.0.0.0 ;)

But thinking about it, I could also write an android app using the embedded carabiner version !
(edit : no, I read the supported architecture list)

Cheers :)

Yes, unfortunately in order to get that to work, you will need to run Carabiner (or some other code which links to the Ableton Link header-only C++ library) on your pocket WiFi headphone adapter. It might be easier just to figure out how to link against Link directly, and skip Carabiner? Can you compile and run C++ code?

I was going to suggest that you just use Ableton’s Android SDK for Link, but I see (to my surprise) that there is still only an iOS version, no Android version. So you will need to start with the same open-source Link library that I used to write Carabiner.

Ohoho, a PR was merged 4 days ago on Link repo, concerning the support of ESP32 !
I'll sure have a look at it right now and see how to send it on the microcontroller :)

Excellent! Yes, I saw the conversation while they were working on it. Best of luck!

I would have prefered micropython instead of plain old c/c++, but I'll make it ;)

Thanks for this enlightening conversation !

You’re welcome, I am always delighted to find people exploring these integrations.

Hehe, me too :)
Finally, I'm too lazy to start developing my stuff inside the esp_idf environment, so I'm exploring another way according to my simple requirement: a wireless metronome synchronized to the Link tempo.

  • I wrote a c++ program (desktop, QT) that embeds the Link library.
  • This program runs a server socket à la Carabiner, and accepts client connections (in this case, the ESP32 wifi microcontroller)
  • At every new beat, it writes to the socket the current beat position modulo the quantum defined (position in the bar). So no slow command/response is needed, just read from a socket.
  • The microcontroller knows where we are in the bar, and will be able to produce an audio click to headphones, potentially different on bar start :)

The latency seems small enough, and I can program my microcontroller with micropython :D
ERFw4s_UYAA4f7c

Nice, sounds like a great approach!

And if you need to, you could add latency compensation, to write the packet a configurable number of milliseconds before the actual beat.