Is there a way to print values to the console?
There are times where I'm not sure what values I'm sending (like MIDI input for instance), so I'm curious if there's a 'print' or similar way to see the values displayed.
Thanks.
Funny-- I was thinking about this earlier today; I wanted to know what the current cps was, and wondered if I could print it out to the console...
2 Likes
I came across this: https://github.com/musikinformatik/SuperDirt/blob/develop/hacks/posting-tidal-parameters.scd
It seems to output the OSC coming from Tidal to the SuperCollider console which is useful but doesn't cover every scenario as far as I imagine. Is there a way to get messages from Tidal to the Tidal console?
Is there any feature for this @yaxu?
I know of two things you can do:
:t sound -- e.g. in Atom
t>sound :: Pattern String -> ControlPattern
so that gives you the haskell data type of whatever you pass to :t and
run 4 -- e.g. in Atom
t>[](0>¼)|0
[](¼>½)|1
[](½>¾)|2
[](¾>1)|3
which gives you a textual representation of a pattern.
2 Likes
Yes basically if you miss off d1 $ you get the events for the first cycle.
E.g.
sound "bd cp" # n 3
says
(0>½)|n: 3.0f, s: "bd"
(½>1)|n: 3.0f, s: "cp"
So the first event has an event with 'n' set to 3 (the f means it's a floating point number), and 's' set to "bd", that starts at cycle position 0 (i.e., the start of the cycle) and finishes halfway through.
If you did this:
slow 2 $ sound "bd"
You'd get this:
(0>1)-2|s: "bd"
The (0>1)-2 means that it is active from position 0 to position 1, but that's only part of the event, as it carries on until position 2. That's because it's an event that would last two cycles, but you're only showing the part of it active in the first cycle.
2 Likes
When I'm debugging things, I use wireshark to 'sniff' the network packets going from tidal to supercollider. It knows about the "open sound countrol" protocol that tidal and supercollider uses, so if you click around on a packet you can get a nice representation of the data. A filter to only look at tidal trigger messages osc.message.header.path=="/play2"
I use something similar for debugging MIDI - midisnoop. It's only for linux, I'm sure there'll be something similar for other platforms.
2 Likes
Hm, actually there isn't an easy way to read the current cps! That would be super useful.
Here's a quick hack, if you run each of these lines in turn:
import Control.Concurrent.MVar
import qualified Sound.Tidal.Tempo as T
cpsnow = T.cps <$> (readMVar $ sTempoMV tidal)
Then you can run cpsnow to find the current cps.
4 Likes
The original question was about midi input into Tidal. Again, no easy way to display that. You could use a midi snooper, or wireshark (as supercollider turns the midi into osc).
If you notice missing functionality, feel free to make an issue here:
https://github.com/tidalcycles/Tidal/issues/new/
The feature request / bug report templates there are only there for a guide, you don't have to fill in everything.
1 Like
Okay thanks @yaxu
I've now had some success wiring OSC into Tidal via Max. (I'm now trying to explore when to use the appropriate type assignment for control in Tidal. It's a bit confusing when to use cT vs cF but I'm getting through it by trial and error.)
I do feel that the documentation is a bit misleading as I outlined above though if you agree there should be a fix to the docs.
How's the documentation misleading? Sorry can't see an outline of that above.
https://tidalcycles.org/ is a wiki, so if you create an account it's possible to edit the pages if you like.
The "sf" is redundant here and doesn't need to be included in the OSC message:
/ctrl sf hello 0.4
But it's entirely possible that the reason I think that is Max/MSP related.
Thanks.
(And I'm happy to edit it if you confirm that I'm correct.)
https://tidalcycles.org/index.php/Controller_Input
Ah I see the confusion - the "sf" isn't a parameter, but a "type tag" that is part of the OSC message. I guess Max will construct that for you. The 's' and 'f' say that there are two parameters, and that they should be a string and a floating point number respectively. The page could be clearer - please do feel free to edit it.
1 Like
Thanks, Alex! That's super useful!
Bryan
The name of this function ... https://en.wikipedia.org/wiki/C._P._Snow
Also, the song by the dBs https://www.discogs.com/The-dBs-Stands-For-Decibels/master/36561
Using that function, I find that Tidal's default cps is 9/16, and that's 135 bpm? Any specific reason?
I recall @yaxu saying that he was tired of seeing so many performances at 120 bpm, which is not the most natural tempo for dance music, and that if most people weren't to change the cps most of the time (I plead guilty to that), it should at least default to something more common like 135 bpm.
Anecdotal semantics of "120": When I type sheet music I use a lilypond template (for lead sheets in a "real book" format) that contains the line bpm=120, which I change - or don't. So "120 bpm" is equivalent to "no tempo specified (didn't bother)" for me and bandmates. But computers ... perhaps Tidal could make the default cps random - forcing authors to think about it. But then they'd just write (the equivalent of) bpm = 120.
And yes, I rarely change Tidal's default cps. Probably because I use it more often in the armchair, or in the classroom, than in the club. (Actual numbers: once a month, once a year, never ...)
It's been a while since I force myself to set the bpm for every piece of music I play/compose on tidal, and I do this way:
do
bpm 111
d1 $ ...
d2 $ ...
So every block of code knows what its time is.
(I tend to use values under the default 135, because I don't play music the people would love to dance to 
)
Yes we should probably decrease the cps to match more sedentary lockdown conditions !
1 Like
Or maybe increase to force people stand up from the couch 
2 Likes