{RK, 20-Jan-2018}
In most cases conceptually it’s really nice to describe materials in a functional way, and then assemble them together in an imperative way. Think of it: it’s what a conductor does. It’s what you do as an interpreter, as you’re working through a piece of music. The score is immutable and then you’re making these different sequential interventions into it.
You can describe things beautifully as a function, but if you want to perform, which means you want to make a decision in real-time, that’s the moment where you’ve stressed the functional model. So, when you do things exclusively in patterns, you end up getting to a point where it gets unworthily complex.
It’s easier for me to think about a pattern as a routine. And this is again a part of the interesting conversation with Hanns, because in the Scala world you really don’t want to use routines. In fact the whole Scala language group has banished routines! So it’s very interesting for me, because this is the way I think about this stuff in SuperCollider, and it would be really cool to discover an entirely different approach within Scala.
{RK, 20-Jan-2018}
We know what a function is, right? A function is just something that per braces you put a series of messages, separated by semicolons, and it does something. It’s like a little packet of logical score. You define a sequence of commands and execute it from beginning to end. A routine is a kind of expansion of the capabilities of functions. So, in the case of a routine, yield means “Done! I stop execution. The function is over”. But then when I call the function again, it goes on from where it left off. This is unbelievably cool for music, because now the function is a little bit like a performance for a musical score, it’s like “I’m going to do this. Wait. Now I’m gonna do this”. I don’t wanna do it all at once, I wanna do it in sequence. The fundamental cool thing about routines is that they allow this sequentially. In the history of live computer music, the first thing people did was having time procedure call. So you could have a function that would run and would schedule software activations. [In a way, it could be said that in the Scala world that time procedure call turns out to be kind of an implementation, a way to do things.] It’s just a way to quickly have some kind of time. The problem was that the whole world of computer programming had no interest in time. Time was an annoyance, I just want it to be faster!
{author: RK, event: sc meeting, date: 20-Jan-2018}
A function is evaluated with a value message, and then it returns itself. Routine is kind of like that, but now I can have a more complicated function that actually changes what it does, each time it is called. Stream is just an object that returns sequence of values. You say ‘next’ and you get the next value. It could be like that’s my score, so that’s the next event to play. The class object defines next and reset. Most thing in the language are streams, in the nerd sense.
Streams become a terminological tool for thinking about sequences of values, and routines have this convenient way of defining streams. In sc it’s actually a little deeper than that, which is: routines also allow you to define one stream out of other streams. In particular, I can define a stream and embed it in the stream of another routine. I have this little piece of stream, I want it to run in my stand and then I want the control back once it is done. I could have [1,2,3,4] as my little score, but sometimes I want [1] to be [1,0,1,0]. And that’s what .embedInStream does for you. And here’s the thing. The class object defines embedInStream to simply yield the object and this is the profound connection between defining streams in sc and routines. Every object that isn’t a stream object can be streamed, because it knows that when it’s being streamed inside a routine it can just yield itself. The fundamental design trick is: I want most objects to have this funny double behavior. When they’re viewed as stream on their own, they don't have an ending. When they’re viewed as stream within a definition of another stream, they only happen once. And that is the fundamental structural trick in sc.
