Testing Tidal 1.7

1

(We need a forum category for this sort of thing.. Not sure what to call it)

The new Tidal and SuperDirt is ready for testing. They should be upgraded together. Here's a thread for people up for trying it out. We can use it to help each other get it installed, try out the features and get things documented.

First things first - how to get the cutting edge running. I use Linux, but instructions should be similar for other platforms - please share any os-specific findings!

First for superdirt, from a terminal window change into the SuperDirt folder. E.g. under linux that would be:

cd ~/local/share/SuperCollider/downloaded-quarks/SuperDirt

Then get the latest changes, and switch to the development branch:

git pull
git checkout develop

If you have changed some files, this might fail. In this case you can run git stash to undo your changes (they get backed up somewhere) and try again.

If you later want to change back to the stable release of superdirt, you can do this:

git checkout master

The next job is to install the tidal 1.7 release candidate. For simplicity and lack of bugs, I recommend using the old 'v1-' install method with cabal.

For the most predictable experience, it might be best to wipe your haskell packages at this point and start from a clean slate, especially if you have previously installed tidal with the now default 'v2' cabal install method. Under linux/mac os can do this by removing the ~/.ghc and ~/.cabal folders.

Here's how you install tidal 1.7:

cabal v1-update
cabal v1-install https://hackage.haskell.org/package/tidal-1.7/candidate/tidal-1.7.tar.gz

If you later want to change back to a previous version of tidal, you can do this:

ghc-pkg unregister tidal-1.7

If you started from a blank slate, you can then cabal install tidal to get the current release.

Ok share you experiences with that and I'll later share some fun things to try..

8 Likes
2

Fantastic news, I'll install it this afternoon. I have no clue what's new / updated but I'm thrilled to give it a try !

3

Ok here's the main thing to try, control busses. This lets you route an effect via a bus.

-- A simple sax sound
d1 $ sound "sax" # legato 1

-- This doesn't do anything different
d1 $ sound "sax" # legato 1 # squiz "0 1.5 0 1.5"

-- A workaround is to chop up the sounds into parts:
d1 $ chop 4 $ sound "sax" # legato 1 # squiz "0 1.5 0 1.5"

-- But now you can use a bus to change a single sound while it plays:
d1 $ sound "sax" # legato 1 # squizbus 1 "0 1.5 0 1.5"

-- You can add a bus to most things but have to take care to give each thing a different bus number:
d1 $ sound "sax" # legato 1 # squizbus 1 "0 1.5 0 1.5" # lpfbus 2 "400 2000 3000" # lpq 0.2

-- You can pattern things within bus patterns:
d1 $ sound "sax" # legato 1 # squizbus 1 (chunk 4 (fast 4) "0 1.5 0 1.5")

-- A big limitation is that bus patterns are monophonic. So if you do some patterning that layers them up, you'll be disappointed with the results:
d1 $ jux rev $ s "sax" # ampbus 1 ("[1 0 [1 0] 1]*6") # legato 1 

-- A workaround is to add 1 to the bus number, and 0 to the value: 
d1 $ jux (rev . (|+ ampbus 1 0)) $ s "sax" # ampbus 1 ("[1 0 [1 0] 1]*6") # legato 1 

-- Or replace the control using a different bus number with `#`
d1 $ jux (rev . (# ampbus 2 "1 0 1 0")) $ s "sax" # ampbus 1 ("[1 0 [1 0] 1]*6") # legato 1

Most things work, but some key things like speed, gain, vowel and note don't.

panbus will work, but in the range -1 to 1 instead of 0 to 1. Working on this.. (That range would be better in general, as you could multiply patterns to change amplitude)

7 Likes
4

On mac, deleted ~/.ghc and ~/.cabal folders. Now I have, in terminal, cabal: unrecognised command: v1-update

5

Perhaps you have quite an old version of ghc? In that case, miss off the v1-, i.e. cabal update; cabal install https://hackage.haskell.org/package/tidal-1.7/candidate/tidal-1.7.tar.gz

6

Thanks, looks like that's working. I guess the old version of ghc doesn't really matter?

7

That's right, old versions are fine.

8

Well I haven't tried any of the new stuff yet, but so far nothing seems to be broken for me at least! All my old files still working, no errors in SC or Atom :slight_smile: Will test more tonight.

1 Like
9

Good to hear! Trying existing stuff to see if it works the same is definitely a good thing for people to do..

10

A simpler function that I'm excited about is press. In mininotation terms it basically turns every instance of 'a' into '[~ a]'.. Every beat then becomes an offbeat and so the overall effect is to syncopate a pattern.

A couple of quick examples:

d1 $ stack [every 4 (fast 2) $ sound "drum*4" # squiz 1.3 # speed 2,
            every 2 press $ sound "sd:1*2 sd:4*3 sd*2 sd:2*2"
]

d1 $ jux press $ sound "sd:1*2 sd:4*3 sd*2 sd:2*2"

Funky times ahead

9 Likes
11

I was going to ask about / try and implement a pressBy but press is just pressBy 0.5!

Iā€™m looking forward to updating :slight_smile:

great stuff xxx

1 Like
12

Yes that's right! I didn't find good results for values other than 0.5 yet but need to listen deeper.. You can pattern it if you like e.g. pressBy "<0.5 1%3 0.75>" (where 1%3 is a third)

1 Like
13

I'm super excited ! For me on linux the installation worked perfectly. I did go ahead and delete the ghc and cabal folders before installing.

I've tried some of my old code and it seems to work just fine.

I espaccially wanted to have this update for smooth panning, so the first thing I tried was something like
(water is a long water field recording)

once $ s "water" # panbus 1 sine

which did'nt work. So I realised that you always have to sample out of the continuos patterns so I tried

once $ s "water" # panbus 1 (struct "t*128" $ sine)

this works for the first couple of seconds and then it stops. Ofcourse ! Tidal only really sends messages over the first cycle! Then the solution came to me:

once
$ s "water"
# panbus 1 "0"

d1 
$ struct "t*128"
$ panbus 1 $ slow 4 sine

This works like I intened. Note that the first block sends the actual message for the sound that plays whereas the second block only sends control messages.
I think for the first block it would be cool to have a function panbus' or so that only takes one argument (the busnumber) and no pattern since in that case it doesn't really do anything.
I also think that it would be good to introduce an alias for d1 etc. named c1 which can be used to distinguish between busses that produce sound and control only busses.

These are just my first thoughts and I'm really happy that this is part of Tidal now!

2 Likes
14

Try using panrecv 1 in the first one - hopefully this is the panbus' you're looking for. I might add a sendbus too.

Not also that internally pan goes from -1 to 1, so you'll probably want to change this to panbus 1 $ range (-1) 1 $ slow 4 sine

2 Likes
15

I'm getting some weird results from this:

d1 $ stutWith 3 (1/16) (|* gain 0.8) $ s "bd*4"

The expected result would be for the volume of the stutters to drop by 20% for every stutter but it doesn't seem to have any effect.

This works fine though:

d1 $ stutWith 3 (1/16) (|* speed 0.9) $ s "bd*4"

After further investigation this:

d1 $ s "bd*4" # gain 0

Produces sound so seems like something is up with the gain function as a whole...
Could I have messed up the installation somehow?

16

Ah, good catch! I have the same. You could try with amp in the meantime, although that is scaled a bit differently to gain.

17

This very cool! Great work :slight_smile:

Alpha/Beta Testing?

I installed from source at d82f68638a622a6707b06fc45d03fa3b8fae0b64 and by cleaning out ~/.ghc and ~/.cabal as you suggested.

$ cd path/to/tidal/src    
$ cabal v1-update
$ cabal v1-install

All this is working fine though it didn't immediately click why I need this feature. I guess I just never tried to pattern FX over a single sample, only over cycles. Are there other user cases?

This is very useful for me and I normally do similar things by shifting patterns in time.

I'll test deeper over the next days as I'll be working in the studio on new material.

Thank you!

2 Likes
18

Manually controlling the effects with midi cc?

1 Like
19

Today I found something curious with midi control busses.
When I try to use ccv with ccn then everything works fine like

d1 $ s "midi" # midichan 0 # ccn "100" # ccv "<60 127 0>"

But when I try to replace the ccv with ccvbus then the returned value is always 0 like (I debugged this with MIDI Monitor)

d1 $ s "midi" # midichan 0 # ccn "100" 
     <| ccvbus 1 (segment 256 $ ((saw * "<0 0.5 0!>") + 0.5) * 127)

But the TidalCycles code on GitHub looks fine to me.

Am I doing something wrong or is this is a bug? Does someone made some experiences with ccv control busses?

20

I think the busses won't work with midi unfortunately, they are a way of talking with scsynth. CCs are manipulated independently from notes anyway, so there is no need for busses there.

2 Likes