Interpreting Tidal

[yaxu]

A few issues in one, we want to:

1. make the interpreter compilable to e.g. JavaScript
2. make it easier to distribute a binary for easy installation (Tidal installer for Linux #284, Tidal installer for Windows #283, Tidal installer for Mac #282)
3. make a smaller download (still important for worldwide reach I think)
4. make new code-based UI possibilities easier/possible (e.g. via Emit code position of currently firing Event #245)
5. explore syntactical sugar beyond what ghc offers

Sound.Tidal.MiniTidal is now part of the main repo, originally from a need to solve the first issue, but it puts the others in much closer reach too.

An alternative to solving issue 2 (but not the others) is using ghc, is using hint. This has the potential advantage of giving full access to the whole of haskell, but with disadvantages of still having to ship a large part (500M) of the ghc libraries.

[yaxu]

Things that don't (yet) work in MiniTidal

• Function composition - d1 $ every 2 (rev . fast 2) $ s "bd sn"
• Transitions - xfade 1 $ s "sn bd"
• fmap / <$> - d1 $ s (reverse <$> "db ns")
• Applicative <*> and friends <* *> - d1 $ n ((+) <$> "0 1 2" <*> "3 4")

[dktr0]

Function composition and transitions should be very straightforward in the existing MiniTidal model. fmap is less clear to me as a desiderata for the reason that it's main use is to lift generic haskell functions (such as reverse) or lambda functions into the Pattern context - and I don't know how far it makes sense to go down that road (there are a lot of Haskell functions and are they really more important than other things or not?) Similar issues with the Applicative functions. Both the fmap and applicative examples could be "avoided" by providing pattern specific functions - indeed the Applicative example with + is already supported in MiniTidal by the far more intuitive "0 1 2" + "3 4"

[dktr0]

There is an "ambiguity" in the Tidal project - regarding whether it intends to become a superset of Haskell versus a separate language influenced by Haskell - that bears directly on this issue...

[yaxu]

Agreed but I think it's worth making a long list of things that don't work, even though some will be not worth 'fixing', or even best not fixing.

[yaxu]

Some more examples of parsing haskell with parsec here that could be interesting to look into: https://www.reddit.com/r/haskell/comments/7jz570/parsing_haskell_with_parsec/

[XiNNiW]

My 2 cents regarding the ambiguity @d0kt0r0 pointed out... One thing I appreciated about tidal being implemented in haskell as opposed to being a haskell like DSL in some other language (eg. js) is that it gave me a head start in learning how tidal worked inside and helped me overcome areas where tidal wasn't yet able to do what I wanted. Perhaps the same would be true of a haskell like DSL in js. You would gain the advantage of being able to run tidal in the browser. What are some of the tradeoffs of Parsec and GHCjs versus MiniTidal versus hint?

[dktr0]

(Just in case this isn't clear: MiniTidal is Parsec and when deployed in Estuary it is compiled with GHCJS.)

I think people will learn a lot about Haskell by using Haskell-ly languages like MiniTidal. And they can easily jump to other environments when they need to.

[yaxu]

I guess the pros are

Minitidal

• can be compiled into other languages like JS
• allows us to do custom syntactical sugar (e.g. barewords) beyond what ghc allows
• allows us to make editors that are more code-aware, allowing building in visualisations and UI elements
• allows us to more easily distribute as easier to install binaries, without shipping with much of ghc

Hint

• you potentially get all of tidal and haskell
• efficient
• easier to implement

(the opposite of each being the cons for the other one)

[dktr0]

Not sure about the "efficient" advantage with Hint... If by efficiency you mean computational efficiency I think that would just depend on a lot of things. It is possible that MiniTidal could be more computationally efficient (ie. during parsing - after parsing there is no difference) given the more constrained syntax.

(By the way, the computational cost of parsing has a measurable effect on performance in collaborative, browser environments...)

[XiNNiW]

thanks @d0kt0r0 I didn't know that!

There is to be a lot to be said for each route. What would the impact be on the users of the platform?
For example, I notice that someone like kindohm defines lots of custom functions and evaluates them before starting. What would that look like in minitidal versus hint?

[dktr0]

There are undoubtedly limits to the definition of custom functions in the MiniTidal approach. However, nothing stops those people - and they are relatively few - from using Tidal in the "original" way, as a Haskell module in a ghci session.

[diegodorado]

Is MiniTidal ready to be compiled in JS?
I am looking for a way to interpret a pattern (particulary sound string patterns) into some sort of event stream.
Say I have a pattern like [bd snare, hh*8]/2 .. then if I ask give_me_events_of_cycle(100) it returns

0: bd
0: hh
1/4: hh
1/2: hh
3/4: hh

And if I ask give_me_events_of_cycle(101) it returns

0: snare
0: hh
1/4: hh
1/2: hh
3/4: hh

I tried to use tidal.pegjs but it doesnt seems to be cycle aware, and doesnt understand commas or curly braces.

Sould I look for MiniTidal for this? Or collaborate to refine tidal.pegjs to match my needs?

Thanks

[dktr0]

MiniTidal has been compiled to JS in Estuary from the beginning, ie. as part of large standalone GHCJS project. It is possible to use GHCJS to make JavaScript libraries that are used by JavaScript applications but that is a very different workflow than what I'm used to with Estuary. Far easier to just use Estuary if you want Tidal in the browser...

[dktr0]

PS - when you use GHCJS to make a JavaScript library I believe you still end up with the full GHCJS runtime as part of the web application - so it would probably be just about as "heavy" as Estuary...

[yaxu]

Closing this for now, not because it's solved, but because discussion has moved on..