Patch inputs:
Guides (extension) | Libraries > crucial > Instr

Patch inputs

How Patch automagically creates inputs

Each argument of the Instr function has a Spec. See Instr for how these specs are determined.

An argument may be nil. For a nil argument, Patch will ask the spec to create a suitable defaultControl.

The instrument may specify default values in the arg names of its function:

If you wanted to build your patch with a KrNumberEditor (a slider) defaulted to 0.01 for the speed:

Args may also be supplied using a dictionary/event expressing args by name as: (argName: value, ... )

This is useful for Instr with long arg lists and helps to avoid errors.

For any nil arguments, a default control will be created.

This gives the impression that Patch is "an automatic gui for an Instr / SynthDef".

If you do not supply arguments, it will make default ones, simple ones, but the real power of Patch is to supply functions with complex and varied inputs. Sitting there with 5 sliders on a 1 dimensional Instrument isn't really the height of synthesis.

Fixed Arguments

Floats and other scalar values including Envelopes, are transparently dealt with by Patch. These items are passed to the Instr function, but not to the SynthDef or the Synth. They are not modulateable.

Talking to the Patch's input objects

As an extra facility, each arg name automagically becomes an attribute of the patch object itself.

Scaling inputs and outputs

First of all, quite apart from Patch, you can use a spec to map a signal from a 0..1 range to the range of the spec :

you can also do that with a Patch input, supplying the resulting function as an input to the patch:

A Patch is subclass of AbstractPlayer which is a subclass of AbstractFunction.

Because a Player IS A FUNCTION, a Spec may also be used to map another player's output and then use that as an input to a patch : is taking the player and creating a BinaryOpFunction out of it.

if you do math on functions you get another function.

the simplest example is:

where the output of the Patch is multiplied by 0.1, reducing the amplitude. Internal optimization in this case results in using a PlayerAmp

Meta-patches : factory methods and creating Patches with Patches

Patch's auto-input creation is simple and convienient, but to really get interesting results I recommend experimenting with factory methods to create your patches, supplying them with inputs useful for what you are working on.

eg. If you often use a certain physical controller then make a factory method:

You could even interrogate the instr to see which inputs might make good candidates for your JoyAxis.

Remember, Instr are not just for audio functions, so you can even keep your factories themselves in Instrument libraries:

You have just used an Instr function to create and return a Patch. This Instr is not used for audio, its just used to build and return a Patch.

Note that the output type is PlayerSpec

You could choose different controllers for different common inputs, you can query the argument name and the spec. Keep files in databases, load other Patches or soundfiles from disk. You could flip coins and choose from soundfiles, audio in, other saved patches or randomly chosen net radio feeds.