Link support

[yaxu]

It'd be good to have link support natively in Tidal/Haskell. An alternative is relying on SuperCollider's new link support, but as is noted here, that's not straightforward.

This could help: https://github.com/wavewave/fficxx

[yaxu]

Once again, I've decided that interfacing between Haskell and C++ is completely beyond me. If someone with better understanding of this can help, that'd be great.

[telephon]

There is link support in supercollider, but I am not sure if sending messages to tidalcycles from there would help.

[yaxu]

It's a bit tricky I think @telephon musikinformatik/SuperDirt#185 (comment)

IIRC the current support via a python bridge works by continually checking the system clock time and sending messages relative to that, but I think it's not a perfect approach.

[telephon]

yes, indeed.

[grammoboy2]

Not sure if this is useful and it has not a proper release yet but...

https://github.com/falkTX/Hylia/blob/master/hylia.h

"Basically the idea was to "dumb down" the link stuff to a super simple C API, which is easier to understand than the official C++ templated classes. Plus also making it easier to build, just needs a "make"

It's used in the Carla project https://github.com/falkTX/Carla

[yaxu]

Thanks @grammoboy2 I've made a start on making haskell bindings for hylia. Help welcome!
https://github.com/yaxu/hylia-haskell

[Zalastax]

Hi @yaxu and @fbous, as discussed in yaxu/hylia-haskell#1, we should continue the discussion on how to proceed here. I just managed to get some very simple Ableton link integration working over at https://github.com/Zalastax/Tidal/tree/tidal-link. It is very inspired by Hylia and https://github.com/yaxu/hylia-haskell but done from scratch. Next step will be to look at https://github.com/supercollider/supercollider/blob/develop/lang/LangPrimSource/SC_LinkClock.cpp for inspiration as suggested in falkTX/Hylia#2.

[yaxu]

@Zalastax Nice one, I tried building under linux out of curiosity, it didn't work yet but I think that won't be a surprise.

There are some things like being able to pause the clock that have been broken for some time, it'll be great to get that working again in this process!

[Zalastax]

I've been on a wild goose hunt this last week.

I had a failure to use cabal v1-install for my new tidal library. The error was installed package info from too old version of Cabal (key field does not match id field). This caused me to reinstall with many different versions of Haskell and Cabal. Turns out I introduced this error by naming my library...

library lib
  ghc-options: -Wall

Why did I do that?

I found that cabal v1-repl crashes when I try to do this->link.enable(true);. I therefore went and created an executable to see if that would crash too. This is where I named the library - because cabal v1-repl does not support multiple targets unless you name them.

I found that the executable did not crash as long as I placed some DLLs in a place where it could be found. So I hoped that the issue was in cabal v1-repl. I went ahead and tried to instead cabal v1-install and that is where the wild goose hunt began.

What now?

Many hours later, after removing the name for the lib, I can both produce an executable and install the library but to use cabal v1-repl I need to remove the definition of the executable.
The executable runs fine - this->link.enable(true); works and I can see that the beats start ticking. But cabal v1-repl still crashes and if I load my installed module in ghci it crashes when I try to enable link as well. I don't know how to debug this - from what I can read it is quite cumbersome to load ghci in gdb.

My best guess was that there is some DLL that I need to load in GHCI but I have added the path to the DLLs to the PATH environment variable so I don't think that could be it.

The difficulty of debugging this is a concern to me. I don't know if we could keep the C++ parts in a separate executable instead or if the communication overhead would make it infeasible.

[Zalastax]

Progress!

I switched to building the C++ parts into a shared library which I build separately. The wrapper for this->link.enable(true); now works in both GHCi and in my built executable. I had to build the shared library with flags -static-libgcc -static-libstdc++ or I would get a runtime error.

My suggestion is to continue with shared library over direct FFI. I'll prepare a new small patch as soon as I have tidied it up a bit!

[yaxu]

Good stuff! I don't know if this is relevant or not, but with some help I found building shared libraries helped with making haskell binaries with working haskell interpreters haskell-hint/hint#64

[Zalastax]

Thanks for the comment - it gave some comfort that I was on the right track 🙏

https://github.com/Zalastax/Tidal/tree/tidal-link/tidal-link now contains code that builds a shared library using Setup.hs and places it in the cabal bin directory. The beat time is correct and shows up + syncs with the LinkHut application from Ableton 😄 I hope this is the last time fighting Cabal for a while 😅

[yaxu]

As a proof of concept, tidalvortex has a simple link-based clock: https://codeberg.org/TidalCycles/vortex/src/branch/main/py-vortex/py_vortex/stream.py#L74
What bothers me is the use of osc bundle timestamps relative to the ntp epoch rather than link clock.. It requires continually checking link time against system clock time and still relying upon them being synched between client and server, which is a problem if the processes are running on different systems.
But if we support sending link's global host time in an osc message, the server can ignore any ntp timestamp and use that instead.
Hopefully that's easy enough to support in SuperDirt @telephon ? If e.g. link is active in sclang, and a linktime parameter is in a message, use that to schedule instead of any bundle timestamp?

[yaxu]

Looks like link now has a C wrapper of its own, maybe that simplifies things a little @Zalastax Ableton/link#71 (comment) ?