From Ron's initial sketches and the reciprocal exchange of software environments arose the idea to understand SuperCollider's pattern system, and what the corresponding structure in SoundProcesses/Mellite could look like. (What does it mean to translate an abstraction from one system into another?)

[hh via e-mail 05-sep-2017]

by the way -- thanks for the .scd file; I looked through it yesterday; it's interesting, because I think it's a very different starting point for defining the piece than how we could do this in soundprocesses; it will be interesting to understand in what way it can be translated; obviously, the easiest would be if there was something like a pattern layer in my system (which doesn't exist right now). The involved synthdefs are straight forward to translate. I will look into the pattern objects required -- Pspawner,  and Pbind -- to understand how they operate in the e-wind piece. I tried to run it, but not sure I set it up correctly. It seems to refer at some point to an inexistent synthdef named 'gated sine'. Also, do I need to feed a test signal to the microphone, or does it operate without live input? MIDI is another big story, but I understood the piece would also run without the nano control?

[hh in conversation 12-Jan-2018]

Yeah, exactly. If I can just drop in there, for me the point is: why is the pattern interesting for me and what could I do with it? In trying out things, the pattern model is an abstraction you use a lot. I could see that from the little sketches you sent me, where I could understand your way of working and formalizing your work. It’s interesting for us to observe how you work with that, because it becomes something that’s not just the pattern system in SuperCollider but I think, as far as I conceive it now, it is also a particular use model, that is how you approach the thing. And it’s also not something that was given, in a way, but it has also a lot to do with your input at some stage in the development of that system.

[rk via e-mail 05-sep-2017]

It is really quite simple. Pspawner is really just syntactic sugar to provide a sequential means of controlling the more functionally flavored patterns. In that context patterns are akin to snippets of musical notation that are spliced together by the function in the Pspawner.

[hh in conversation 12-Jan-2018]

I’m kind of approaching it from two sides. One side has to do with the second reason why I found patterns interesting at this point. And this was that I have worked with SuperCollider since 2006, that means I used it a lot, but somehow I’ve never really touch that subsystem, which is a large subsystem of SuperCollider. And I’m trying to understand my kind of reservations against the model of patterns, where that comes from and how it changes when I see how you work with that. For me it’s interesting why I picked a specific way of working with that system and not others. One of the things I’m trying to do also in the project is to take existing works and try to see how they could be reformulated in my current system, what does that mean and do. It’s interesting to understand what they could all do and what I could change, because now the task for me is not just to say: I want to translate this pattern system to my system for the sake of it, but on the way to that, I want to see what it opens up in terms of possibilities.

Patterns

repo for pattern impl for scala and sound processes: https://git.iem.at/sciss/Patterns (check test sources)

also check notes: https://git.iem.at/sciss/Patterns/tree/master/notes


The dual of value and event patterns have been incorporated into Mellite v2.29.1.

[rk in conversation 12-Jan-2018]

In the context of SuperCollider the patterns library represents a kind of full functional model. In many ways it is a functional model: a pattern is an abstraction that is like a little entity of algorithmic score. It can be a particular score or not and it can be freely reused. Well ok, to talk about this I have to drill down a little bit and kind of get technical. So what a pattern is: it is such an object that you say: “Ok, be a stream!”. And it creates a stream for you. So a pattern is a little bit like a class that creates instances. But there’s this very specific, special doubling or duality which is: as a stream it might act one way, but contributing to the definition of a stream it can act differently. So, in particular a number as a stream just returns itself infinitely. But embedded in the definition of another stream it returns itself once. And so this is completely the trick, the fundamental trick, that makes you have an easy framework where I can replace a single value with a subsequence of values. So that’s a kind of interesting thing. What I found with it is: it ends up much easier if you can also kind of go into an imperative mode in creating sequences of patterns over long time, particularly for the installation. And in a way there’s  kind of a deep connection, you can think of it as the difference between writing a score and conducting it or interpreting it. So, writing a score is totally non-causal you know, you can do all these things. But when it comes to actually perform it in time it’s one thing after another, and the rule of time enters in. So, the functional style is fantastic, because it’s very very expressive. But when it comes to the gig, you want to say: “Now!”. And that’s much harder to do. So that’s kind of a deep issue. And so what’s really interesting about Scala is that’s designed to kind of work in this cross-relations and Hanns and I have been talking about that and how the patterns library, or a version of it, could be added to Mellite. And in the context of SuperCollider I had a strong bias, which is like: “Ah. I want processes!”. Because there are lots of things that are easy to write that way. And then the interesting thing is in Scala processes are really an issue, but it has a much more robust kind of functional library. Well ok, so how far can we go without that?

[rk in conversation 12-Jan-2018]

Fundamentally patterns give a really compact way of describing a fairly complex set of relationships. There are number of different kind of limitations, but it’s much more concise in doing that with routines, let’s say. And in general, for installations in particular: for the installation where I want it to be free changed, but I want to have a pretty clear handle on global characteristics, it’s really nice to essentially generate a pattern definition and then play it. That's like an extremely nice way to deal with issues. But what the pattern is doing is not necessarily note generation, which is what all examples do.

[rk in conversation 12-Jan-2018]

Well, in fact there was kind of a design debate that went on in sort of two levels. One was that one fundamental limitation of the original pattern library is that it was purely sequential. And I wanted to be able to have a time-based abstraction. So think at a chord progression, ok? There was no way to express that in the original patterns library, because the original patterns library is purely sequential in form. So it could be really great for being generative of materials, but not great for being descriptive of familiar structures. And it turned out that to get that into the patterns library the problem is: the pattern needs an awareness of time, and furthermore it has to be able to concatenate with other completely separated patterns it might be in sequence. So to do that in the context of SuperCollider, the routine context becomes the place where you can stash the information you need to glue these things together - if you can rely on routines being present. And that was absolutely my design intervention in the evolution of patterns, which I was able to sell to James because it turned out to be much more efficient in terms of memory allocation, because you’re not creating and deleting process context blocks all over the place which kind of exercises the garbage collection. Now, what that means in the context of Scala I totally don’t know. And I think you’re still trying to figure that out in a way.