Tidal websocket API

[lpil]

Hello!

I wish to be able to send code to tidal and receive any error messages over some API. Possibly a Haskell API if something language agnostic is too difficult.

Does this exist? Or could you recommend an approach for implementing this?

Thanks

[yaxu]

Here's my ongoing attempt using websockets: https://github.com/yaxu/tidal-websocket

It's prototype quality code.. here's the javascript client https://github.com/yaxu/tidal-websocket/blob/master/data/edit.html

it's a fork of this by @d0kt0r0: https://github.com/d0kt0r0/estuary/blob/master/server/estuaryWebSocket.hs

[yaxu]

Here's a draft protocol, comments welcome! https://github.com/yaxu/tidal-websocket/wiki

[lpil]

This looks great, thank you. Would you need multiple connections to play multiple patterns?

[bgold-cosmos]

Would it be worth it (and possible) to have more detailed communication during the /record command? I'm imagining the audio could take some time to render, so maybe an immediate confirmation of receipt with a later notification when it's available?

And maybe a few commands to just query the server about current cycle/cps/pattern without actually sending anything?

[yaxu]

@lpil Yes that's how it is at the moment, although you can always combine patterns with stack or so

@bgold-cosmos yes all good ideas.. Maybe a way to find out place in the render queue as well

[lpil]

Seems slightly limiting with how people tend to use tidal at the moment. Is there a shift towards using stack for everything?

Or would you recommend people have multiple hotkeys for sending over different connections, and then having people memorise which patterns go to which connections?

[yaxu]

@lpil I initially made it this way for security reasons. A pattern is pure and so can be safely parsed even when from untrusted sources.

The server could maintain a list of patterns per connection, and perhaps parse the d1 from the start to mimick the current behaviour in atom etc.

But I have the feeling that it is better for the client to do this kind of book-keeping.. That the server should do the minimum while supporting a range of approaches in the client.

Stack is a bit fiddly to live code with, I think the future is probably in more experimental editors, e.g. I'd like to return to GUIs/TUIs like texture https://slab.org/colourful-texture/ , and in general explore tangible / visual language and inline visual feedback more.

But all that said it wouldn't be hard to add something that allows multiple patterns per connection and it wouldn't limit things... So probably worth implementing.

[lpil]

Fancy editors could be fun and interesting, but I think it's important to preserve the existing workflow. I'd be unwilling leave (neo)vim, so not being able to specify this with text would be a bit painful.

[yaxu]

My point was that there is no real need for the API to handle combining multiple patterns into one, this could be done in the client. Nonetheless, it would be pretty straightforward to implement in the server.

But what purpose are we looking to serve here - is there a particular problem you were wanting to solve when you opened this ticket @lpil?

[lpil]

I wanted to preserve the current way of working, but make the interaction between the editor and the interpreter more robust. I find the embedding a REPL in the editor quite awkward, especially in vim, and thought if I could throw data over the network interface I could easily built a more comfortable integration in the style of Sonic Pi's. :)

[yaxu]

I see. I guess there's a choice here whether to stick with specifying the pattern number as part of the code (as with d1) or doing this some other way, e.g. switching between concurrent patterns with key combinations. The latter could also allow easier mute/solo of patterns with ui stuff for showing what is playing where. I think the current situation is a bit confusing, for beginners at least..

[jarmitage]

A comment from talk.lurk.org for posterity:

I dunno about Tidal, but Extempore has a 'compiler as a service' model. So it starts up and listens on a port, rather than presents a REPL like Tidal does. Tidal listening on a port would certainly make for a cleaner tidal.el experience. The accumulation of Tidal> prompts in the process buffer is a tad annoying. If Tidal's a service, the repl is just another client and you're not trying to pour everything through it.