CLASSES


 

A Class is a very common concept in OO languages. You can think of it as small factory that knows how to build objects. Classes inherit one from the other so you can easily define graphically a new class that adds specifical data and behaviour to an existing class. So you'll be able to create new, personalized, musical objects, just by subclassing the standard ones provided with OpenMusic.

Class behaviour in a patch window

A class is a prototype for a certain type of object. For example the class chord is the prototype for al l chord actual objects. Classes are stored in packages. When you drag a class icon from its package to a patch, OM creates a factory icon and displays it in the patch. A factory is a function that knows how to create instances of the class it is associated to. It has inputs that are linked with the slots of the class.

Create a new class

Here we create a user class named Pnote, a note that triggers a program change every time it is played. We'll tell OM that PNote is just a Note plus some added information, by defining PNote as a subclass of Note.

Here is the order of operation:

Now, we add a slot PChange to the class PNote. We'll use this slot to store the value of the program change.

The package user has now a new class PNote.

Drag it to a patch window in order to get a PNote factory.

Notice that all the standard slots for note (i.e. pitch, vel, dur etc) belong naturally to the class PNote, and that a new slot PChange has appeared, with its default value. Note also that the new class (PNote) inherits a graphical editor from its parent (Note). So you may have a miniview ('m' key), or you may dbl-click on the factory icon to open the editor.

 

Change the initialization method for your new class

If you option-dbl-click on the PNote factory icon, OM opens an instance initialization window where you can establish a mapping between the inputs of the factory and the inner slots of the instance to be created at initialization time. You may insert visual programming code between the input icons (i.e. midic, vel, etc.) and the inputs of the 'init-instance' box. For example, you might add the channel input to the PChange one and input the result in the rightmost input of init-instance. It would mean that the actual value for the PChange slot inside the instance to be created will be the sum of the channel and the PChange value you give by external connections to the factory (who might want to do that?). This kind of operation is called pre-processing of the inputs.

The newly created instance is available at the single output of the init-instance icon. There, you may add some post-processing, by looking into the object and changing again its slots. In order to do that, you need to use the get-set-slot construction. More about this later.

 

 

The get-set-slot construction.

When you drag a class icon from a package to a patch window, you create a Factory. If you shift-drag the same class icon (or if you shift-drag the factory icon) in the patch window, you get a get-set-slot icon specialized for that class. It is a function that takes an instance of the considered class (for example an instance created by evaluating the factory) in its left modt input. If you evaluate the leftmost output of the get-set-slot, you get the object connected to its leftmost input unchanged. If you evaluate the other outputs, you get its slots values. If you connect something to its inputs (e.g. 64 connected to the PChange slot input), you change the value for that slot when evaluating the get-set-slot icon.

So this is basically exactly what you can do on the factory icon itself. You will need the get-set-slot when you have an object, say of type PNote, coming through a connection into the input of a subpatch, And you don't have access anymore to the inlets and outlets of the factory that created it, in order to read or change its slots. It might also be the case for the object coming out of a init-instance icon in an initialization method (see previous), or for a variable (see previous).