Understanding Streams, Patterns and Events - Part 7:
Filter:

Understanding Streams, Patterns and Events - Part 7

Practical Considerations

Practical Considerations

Using your own ~instrument

Pattern: -play creates an EventStreamPlayer for you and also supplies a default protoEvent. If you were using your own event model you would just pass in your own protoEvent to the play method.

Defining your own message bindings

The default event prototype uses a msgFunc to determine which bindings to pass to the server. Synthdefs that have been stored in a SynthDescLib ("synth description library") construct the msgFunc automatically. The default event looks up the instrument name in a SynthDescLib of your choosing (using the \synthLib key). Normally only the global SynthDescLib is used; if \synthLib is empty, the global library is the default.

You should not send or load synthdefs that you plan to use with patterns. Instead, store them in a SynthDescLib.

If you don't do this, nondefault bindings will be ignored. In that case, you can provide a custom msgFunc manually. Here's an example:

As you can see I have added dorkarg to the arglist of the SynthDef from earlier.

dorkarg is ignored because the SynthDef was not properly .add'd and consequently, the event prototype doesn't know that dorkarg is important.

You could also supply a \msgFunc that includes dorkarg :

But this is quite clumsy. It is strongly recommended to get into the habit of using .add for all SynthDefs intended for use with Patterns.

The other option you have if you will be using unspecified bindings, is of course to define an event with the appropriate msgFunc as default. Have a look at Event's source, it's easy, and it's cleaner than passing in the msgFunc every time.

Manipulating an EventStreamPlayer in Realtime

The following methods are possible because an EventStreamPlayer is a PauseStream :