TidalProc.hs

TidalProc.hs

module TidalProc where

  import Sound.Tidal.Stream
  import Sound.Tidal.Pattern
  import Sound.Tidal.Parse
  import Sound.Tidal.OscStream

  port = 5000

  procShape = Shape {
    params = [
      F "hit" (Just 0),
      S "view" (Just ""),
      F "fade" (Just 0),
      F "a" (Just 0),
      F "b" (Just 0),
      F "c" (Just 0),
      F "d" (Just 0)
    ],
    cpsStamp = True,
    latency = 0.1
  }

  procSlang = OscSlang {
    path = "/proc_osc",
    timestamp = NoStamp,
    namedParams = False,
    preamble = []
  }

  procStream = do
    s <- makeConnection "127.0.0.1" port procSlang
    stream (Backend s $ (\_ _ _ -> return ())) procShape

  hit = makeF procShape "hit"
  view = makeS procShape "view"
  fade = makeF procShape "fade"
  a = makeF procShape "a"
  b = makeF procShape "b"
  c = makeF procShape "c"
  d = makeF procShape "d"

This is finally all wired up and used like this:

vis <- procStream

vis $ hit "0 0 1 1 0" # view "view1" # a sine # b "0.2 0.3 0.8"

Questions:

1. What is the cpsStamp bit for?

cpsStamp = True,

2. What is the entire OscLang part for? I know that the path is used so that the server can look for messages with my particular path (e.g. /proc_osc), but what about timestamp, namedParams, and preamble? It looks like I'm just using default values. Are they required?

  procSlang = OscSlang {
    path = "/proc_osc",
    timestamp = NoStamp,
    namedParams = False,
    preamble = []
  }

3. I'm guessing that the last bit for procStream just ties everything together. Is there a better way to explain what these lines do?

  procStream = do
    s <- makeConnection "127.0.0.1" port procSlang
    stream (Backend s $ (\_ _ _ -> return ())) procShape

• cpsStamp adds the current cps to the message
• timestamp - when you send a message over a network, you get 'jitter' - timing issues. This is a problem with dodgy wifi networks, or if you want really tight timing in general. You can get really accurate timing by sending messages ahead of time, with a timestamp for when the message should be acted upon. You have it set to NoStamp which turns off this behaviour - instead there is no timestamp in the message, the message just gets sent at the 'right' time, and the other end won't get it until a bit later. This is completely fine for triggering visuals, especially if the message is being sent locally.
• namedParams - if True, for every parameter you send two values - the name of the parameter, and the value of it. Furthermore, only the parameters are sent that have values in the pattern. If False, only the values are sent, but they're all sent, so you can tell what a value is for by its position in the message. In the latter case, default values are used for parameters without values set in a pattern.
• preamble are just extra values to add to the start of a message. You'd only set this if you're sending to someone else's osc server, and it happens to have some data that needs to be added to the start of a message that never changes.

Yes the last bit ties it together.. I think it's a bit longwinded because the same code gets used for midi connections.