Tidal UI ongoing ideas thread

Communities TidalCycles
1

This is a thread to suggest and discuss ideas for Tidal UI, that is, the text interface that the end user works with in Tidal. Even more specifically, everything that is or could be in here: https://github.com/tidalcycles/Tidal/blob/master/src/Sound/Tidal/UI.hs

Frequently in the past ideas have popped up in talk.lurk.org and been forgotten, whereas not every proposal is ready to be raised as a feature request on GitHub for implementation. Therefore this thread can act as a middle ground for ensuring ideas don’t get lost, and that they have an open space to develop and be visible.

Although this is a discussion of UI, I might suggest that in this thread we refrain for now from discussing non-textual UI, as that is probably deserving of its own thread (that someone is welcome to start).

2 Likes
2

Here’s one that I mentioned in the chat recently that I want to move to here, lightly edited for clarity:

Since was updating tidal.el I was reflecting on p, hush, list, mute, unmute, solo, unsolo, once, asap, nudgeAll, all, resetCycles that are now in BootTidal.hs. maybe you’re already thinking about this but it seems that we’re not far from being able to experiment with stuff like a kind of top for tidal which could run in its own buffer, e.g.:

name     status           last updated     first added       ... (pan, gain, etc)
-----------------------------------------------------------------
pat4      t (xfadeIn 8)    0 cycles ago    0 cycles ago       
pat3      muted            1 cycle ago     1 cycle ago
pat2      soloed           2 cycles ago    12 cycles ago
pat1      active           4 cycles ago    23 cycles ago
pat0      silenced         20 cycles ago   49 cycles ago

Other possible functions could be listSoloed, listMuted, listHushed, listSilenced, etc. And the other idea i had that would be INCREDIBLY useful would be to string match with these functions, e.g.:

mute "pat" -- mute all patterns with "pat" in the name
mute "d" -- mute all D patterns

And also unsoloAll as a common mixing desk feature. Together the his would give a super simple way to transition substrucutures of larger compositions. Maybe theres a totally better approach to this but that’s just some thoughts before i fall asleep and forget

The above ideas all came from trying out the new list and seeing that it still lists patterns after you have silenced them which isn’t that useful IMO. All of the above kind of look like a Tidal API of sorts that could enable a bunch of new UI features and compositional approaches.

That’s all for now!

Edit: For the record, I only just realised that list is informative in terms of mute, solo etc:

tidal> tidal> "abracadabra"
("pat1") - muted
("pat2") - muted
"pat3"
"pat4"

Liking this direction.

1 Like
3

Just to mention things on my list, I’ve been trying to learn about the parser to see if a few things could be done and try implementing them:

  1. have the “!” recognized as a “step” in patterns like "<a ! ! b>", right now Tidal thinks there’s only two things in that pattern, not four
  2. have each part of a euclidean pattern recognized as a “step” as well, so "{a(5,8)}%4" would turn into "<[a a ~ a] [a ~ a ~]>"
  3. pattern substitution, both from earlier “matches” or from an extra argument. For example:
    "[a b]# c c $" -> "[a b] c c [a b]", and
    subst [every 2 rev "[a b]", "c"] "<$0 [$1*2] $1 $0>" -> "<[b a] [c c] [c] [a b]>"

1 is quite possible, I think 2 is technically impossible for the most general case but there’s a fudge that works pretty well, and 3 I’ve gotten working with a toy parser but haven’t figured out how to integrate it into Tidal yet.

1 Like
4

I think something to visualize streams would be really useful. It’d be good see volume and panning and frequencies to help with mixing.

5

On my phone, but I’ve always thought it would be awesome to have midi CC (or osc) control over numbers in Tidal, so turning a knob could sweep a value in real time. I realize that’s not an easy thing but it would be cool to automap a range of CC’s to the first X live numbers on the screen. Just a thought I’ve had for a while.

6

Do you mean something different to this?

https://tidalcycles.org/index.php/Controller_Input

7

Cross-posting this from https://talk.lurk.org/channel/tidal for posterity…

I was on the plane yesterday and came up with a UI concept for tidal that would involve exposing the pattern parser to the host editor. Essentially the idea is to give the user coupling and decoupling actions as keyboard shortcuts, which either take a pattern string and turn it into code, or vice versa. This amounts to using tidal’s pattern parser to provide refactoring tools to translate to and from pattern strings.

Examples:

d1 $ s "bd*4"
-- user does a "decoupling" action
-- code above is replaced by the following
d1 $ fast 4 $ s "bd"
-- user does a "coupling" action
-- code above is replaced by the following
d1 $ s "bd*4"

d1 $ stack [
	   s "bd ~ [~ bd] ~",
	   s "~ cp ~ [cp cp]"
     ]
-- coupling action
d1 $ s "bd cp [~ bd] [cp cp]"

d1 $ s "bd:2 cp [~ bd:1] [cp cp:3]"
-- decoupling action(s)
d1 $ struct "t t [~ t] [t t]" $ n "2 0 1 [0 3]" # s "bd cp bd cp"

I think this would be super powerful for both improvisation and composition. Watching myself and others use tidal, i think we do these things already all of the time, yet we are just re-parsing tidal patterns which tidal already knows how to do, so why can’t the editor do this for us? It could also open up some interesting possibilities like “serialising” entire tidal compositions into strings. A challenge could be how to pass the re-parsed output from the ghci interpreter to the editor and replace it in the right location.

Relevant existing GH issue: https://github.com/tidalcycles/Tidal/issues/217

1 Like
8

Another UI concept… get (could also be named something like copy / follow / watch / listen):

d1 $ n "0 1 2 3" # s "arpy"

d2 $ note (get n d1) # s "superpiano"  -- would play `d2 $ note "0 1 2 3" # s "superpiano"`

Hopefully self explanatory, but the idea is to get patterns from other patterns and re-use them.

2 Likes
9

I mean that but with visual feedback inside of the editor. So instead of

d1 $ sound "bd" # speed (cF 1 "hello")

it might look like:

d1 $ sound "bd" # speed (cF 1 "hello" 39)

where there 39 would go up and down based on the controller value. That way you could have the tactile control w/ the visual precision of knowing the number it’s posting to Tidal. But that would be a major change as it would require editor plugin that did the work of updating the screen.

1 Like
10

I take it this would be kind of like some synths that have a “panel mode” vs “preset mode” and so you can bounce from immediate control to the preset with a flip of a switch.

11

Hmm I’m not quite following you there. Could you provide an example?

Yeah I would love to see this but the idea of creating something so desirable just for say Emacs really puts me off for some reason.

Also given how far @charlieroberts has taken inline dynamic visualisations with Gibber, I feel like it would be important to do something building on that state of the art, but I don’t really know what kind of editor that would require! Perhaps something altogether different. I have been exploring Pharo and Glamorous Toolkit recently to that end.

12

sorry I was forking the thread. The panel thing is like your coupling / decoupling idea. As in the panel switch decouples the knobs from the current preset and vice versa.

For the editor connected nature of my idea, I agree that’s what seems tough and hard to maintain.

A visualizer of the midi data decoupled (or in the background) would work, especially if you could color code the cF based on name or something. That way the visualizer could match the color of (1 cF “blue”).

13

I think about ideas like this a lot too.

But perhaps we should make this thread more specific to “Tidal language UI features”, and break out your discussion to “Tidal feedback features” or something?

[Meta: evolving forum topics to be highly specific is a feature that gets used a lot in some other forums like this. Is that something we feel is worthwhile experimenting with here?]