Best Practices

Separate notes with dissimilar behavior into their own PolyObjects

Let's say you're making a PolyObject with lots of regular notes whose p4 field represents the pitch. At some point you also want to insert a note that affects something a bit more irregular, like the phase of the other notes, and its p4 field represents, say, the amount of variance in the phase. It would be prudent to separate that irregular note away from the notes in this PolyObject in order to keep your expectations about the p-field of the PolyObject as a whole consistent. Without the irregular note, you can safely say that p4 of PolyObject X (or whatever its called) represents the pitch of all of the notes it contains. However, with that extra note in it, p4 has no consistent meaning in PolyObject X, and you can't safely apply NoteProcessors to it that affect that p-field.

Group co-reliant notes together into PolyObjects

Co-reliant notes, in this case, would be notes that rely on each other to make their sound. For instance, if you had a group of notes that fed their output to a zak channel, then another note to process and play that channel's sound, those notes would be co-reliant. The reason to do this is to try to make each SoundObject in the main score independent so that one can move, remove, and edit each of them without worrying about affecting other notes. The PolyObjects, effectively, begin to represent one atomic sound in your score, making it easier to experiment with.

Doing this also allows one to reliably freeze PolyObjects. If one tried to freeze a PolyObject that did nothing but write its output to a zak channel, the resulting sound file would be dead silence, and the score would never work (since a frozen sound does nothing but read and play a sound file).

Wait, what about separating dissimilar notes?

That's still possible with co-reliant but dissimilar notes. What one would do, to use the example in the previous section, is make a PolyObject that contained the instrument processing the zak channel output and another embedded PolyObject. The embedded PolyObject would then contain all of the actual notes writing to the zak channel. Now what you can do is apply all kinds of NoteProcessors to the embedded PolyObject, then freeze or do whatever to the parent PolyObject in a reliable fashion.

Try to group logical phrases in your music into PolyObjects

It's much easier on the user as a composer to arrange the notes this way. This enables one to see opportunites for reuse of certain musical phrases, and implement that repetition easily by adding said PolyObjects to the SoundObject Library and copying instances wherever they're needed.

Try to keep the length of the PolyObject representational of its actual length

This only really applies if the Time Behavior being used is None, otherwise a PolyObject's length is always going to represent accurately its length in the composition. Remember to use "Set Subjective Time to Objective Time" as needed.