Testing Tidal 1.7

[tedthetrumpet]

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

[yaxu]

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

[tedthetrumpet]

@yaxu

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

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

[yaxu]

That's right, old versions are fine.

[tedthetrumpet]

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 Will test more tonight.

[yaxu]

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

[yaxu]

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

[iii]

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

I’m looking forward to updating

great stuff xxx

[yaxu]

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)

[polymorphic.engine]

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!

[yaxu]

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

[C-o]

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?

[yaxu]

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

[msp]

This very cool! Great work

@yaxu

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

Alpha/Beta Testing?

@yaxu

Here's how you install tidal 1.7:

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 

@yaxu

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

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?

@yaxu

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.

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!

[cleary]

@msp

Are there other user cases?

Manually controlling the effects with midi cc?

Tidal 1.7 control busses + midi control input =

Hi all, [update] there is now control bus documentation! https://tidalcycles.org/docs/reference/control_busses I thought I'd share a very short experiment with the new control busses and midi input in tidal 1.7 - this immediately reactive control is something that I really missed when I first started getting into tidal, and I didn't have the patience to plumb the setup externally. I'm twiddling knobs on a novation launchkey mini, mapped to djf, squiz, room and size respectively d1 $ …

[mrreason]

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?

[yaxu]

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.

[archaic.tech]

[Edited because @yaxu just said it first]

Given that CC messages are always supposed to act independently from MIDI note messages, I think it might make sense for Tidal to detect CC-related params and send more messages related to those. (Even when CC-related updates occur in the middle of an event).

[mrreason]

Thanks for the explanation! But should we then remove the midi busses in Params.hs to avoid confusions? Or is there a good reason to keep them in the code?

[yaxu]

Yes we should!