Chapter Four: Synthesis

Parameter fields or p-fields

Most text-based synthesis languages depend on a specifically structured syntax where order and placement matter. For ugens or opcodes, the ordered values are usually called arguments and are defined in the program's manual or reference. For scores, the positions are called parameter fields, or p-fields, discussed below.

If one were invoking an oscillator in a hypothetical orchestra instrument design, the syntax might be the user-named variable location to write the oscillator’s output to (something like avar below), followed by the unit generator name (something like OSC), followed by the amplitude (in dB), then the frequency (in Hz), and finally the number of a function table that gives the oscillator its waveform (see below).

The entire statement might look like:

avar OSC 45, 440, 2 ;

Sadly, the oscillator in this instrument will always play a signal that is 45 dB, 440 Hz and will always use function table 2 for its waveform (which we have not yet defined here) whenever it is sounding. An entire instrument definition in this imaginary language syntax might look like this, with inline comments after //:

//orchestra
instr 1 //definition for instrument 1
avar OSC 45, 440, 2 ; //generates an periodic sequence of samples
OUT avar ; //sends the result of whatever sample value is in avar to the instrument output
endin //ends the instrument definition

A scorefile to play the instrument above will have “note” statements that also have a specific syntax and placement. The ordered places of each note record are called fields, specifically parameter fields or p-fields, which are usually separated by spaces or tabs. In a shorthand that will become useful in a moment, these p-fields or places are often abbreviated as p1, p2, p3 and so forth. Here in our imaginary language, the first field (p1) would be what instrument number the note record should play if the line starts with an ‘i’ (‘i’ followed by the instrument number to be played). The second field (p2) would be the start time of the note in seconds, the third field (p3) would be the duration of the note in seconds. In many languages, these first few fields for notes or other types of score statements are fixed and not user-programmable. Using our orchestra above, these first three fields are the only parameters available to us. So perhaps this piece might be a bit monotonous with the same pitch, amplitude and timbre for each note, or it could become a brilliant study in rhythm.

//score
i1 0 0.5
i1 1 0.2

However, if we modify our instrument definition to use data from additional score p-fields, then each note could have its own unique amplitude, frequency and choice of waveform. The free, undefined ‘p’ variables (p4 and up) are substituted in the fixed places of the opcode’s arguments for amplitude, frequency, wavetable, etc.. By substituting ‘p4,’ we are telling the instrument to use the 4th field of the note statement for the amplitude argument. So below we substituted p-field variables for the fixed values in our new instrument 2 definition simply by placing them where the ugen's arguments for each parameter goes:

//orchestra
instr 2
avar OSC p4, p5, p6 ; //p4=amplitude (in dB), p5=frequency (in Hz), p6=wavetable #
OUT avar ;// sends the result of whatever sample value is in avar to the instrument output
endin //ends the instrument definition

Each note could then specify those varying values in the 4th-6th fields, so:

//score
i2 0 0.5 45 440 1 //at time 0 sec, a 0.5 second note at 45 db, 440 Hz, and using wavetable 1
i2 1 0.2 65 880 2 //at time 1 sec, a 0.2 second note at 65 dB, 880 Hz, and using wavetable 2

Note we could have used p4 for frequency and p5 for amplitude instead...it was up to us to define which p-field is used for a specific argument in the orchestra.