Event patterns and Functions:
Filter:
Tutorials (extension) | Libraries > miSCellaneous > General Tutorials | Streams-Patterns-Events

Event patterns and Functions
ExtensionExtension

using event patterns with functional elements

Description

This is a tutorial file about event patterns with functional code. Features concerning scope are regarded along a line from Functions to Streams, Streams of Events and EventStreamPlayers. These general characteristics allow to generate a parametrized family of EventStreamPlayers from a single event pattern definition and are used as a base for controlling EventStreamPlayers with VarGui . For a convenience way to generate Patterns with environment-dependent reference see PLx suite .

Functions in Environments

Environments are a standard way to separate namespaces in SuperCollider. Functions may include environmental variables and then dynamic scope comes into play: variables get the value from the context in which the Function is evaluated. Anyway a specific environment can be linked with the Function, the latter will hold for Streams polled from Patterns with certain functional code - it's just the environment in which the stream has been generated from the pattern.

Take a simple Function with one argument and assign it to the interpreter variable f:

So either by evaluating the original Function in different Environments or, equivalently, by deriving new Functions from the original attached to different Environments we create a parametrized family of Functions. The Function's basic behaviour is pretty simple (x*2), in dependance of the context it is just varied (a linear offset is added). With more environmental variables a much greater complexity could be introduced, though possibly obscuring the basic behaviour.

This priciple can now easily be extended to Streams, Streams of Events and EventStreamPlayers. We define the basic behaviour of an event stream with an event pattern (Pbind), then enrich the event pattern with functional code and can have a huge variety of EventStreamPlayers in different Environments with different parameter sets - all playable and modifiable in realtime (in parallel or independentely) and all polled from one single event pattern definition! Step by step:

Streams in Environments

What happens in the case of a Stream that will repeatedly evaluate a Function?

Indeed, Streams derived from the simple Pfunc don't do much here, they just reflect values in the Environment in which they are defined. As with Functions in the first example Pfuncs can be combined with other Patterns to modify their behaviour. So a family of related Streams (common attributes) can be polled from a single pattern.

An even more generalized operation is the use of Pcollect, which defines the following Stream behaviour: Output of the source stream will be taken as input by the collecting stream, as with Pfunc the Function defined in Pcollect will live in the Environment in which the Stream has been polled from the Pattern. The above could also be written like this:

There is another Pattern engaging Functions, thus allowing to benefit from environment-dependance: Plazy. it evaluates a Function that returns a Pattern to be embedded in a stream. For repeated embedding the Plazy can be wrapped into a Pn. If a generated Pattern repeats infinitely, there will not be any further evaluation. So when using Plazy have a close look at the inner Pattern's repeat arg.

This example was still similar to the ones before, basically a loop modified by a factor. But imagine that a Plazy could give out arbitrary new Patterns, the choice itself could depend on an environment-dependant parameter.

Event streams in Environments

One step closer to the sound: let's define an event pattern with single patterns that contain functional code. Again the pattern itself is neutral concerning the relation to Environments ...

EventStreamPlayers in Environments

Not much will change by the last transition, EventStreamPlayers are also attached to environments.

The VarGui interface can be used to control running EventStreamPlayers in that way. They may be passed directly, then their attached Environments will be taken for variable setting:

But also the event pattern can be passed directly (recommended). Then new separate Environments will be generated automatically, changing envir variables by accident is very unlikely.