pmask is a set of Python (www.python.org) modules for numeric score generation. Its first releases had basically the same set of algorithm present in Cmask by Andre Bartezky.
The main difference between Cmask and pmask is that Cmask is a dedicated language while pmask is extension to a generic programming language.
A dedicated language like Cmask is quite simple to learn but not very flexyble. You can't much more than the Andre programmed it for.
Switching to a generic programming language is a big step that has both pros and cons. The main con is that you have to learn Python in order to use OMDE/pmask.
I think that writing in Python (using pmask) the equivalent of a Cmask program is not more complicated that the original, it is only that you have to type more.
Flexibility means that:
you can add more basic components (generators)
you can mix Cmask-like generation algorithms with other totally different score generation or processing algorithms
you can apply the same tool to similar kind of problems (3d graphics and probably 3d graphic animations)
In successive releases pmask in fact added more generators (not present in Cmask) and a additional step, very simple (like everything in OMDE/pmask) but very important: events were no more stored as strings but in dedicated Python objects.
Of course you can print one of such object and get the standard numeric score notation for event, but you can also operate easily on that object in order to post-process them, aggregate it with other objects and operate on such groups of objects.
At this point I wanted to make a distinction between the way you produce the score events (pmask) and the way you represent and process them (OMDE). This is way I refer to the current development version of "pmask" as OMDE/pmask.
For example: the Event and Aggregate classes are in omde.score, the cloud() or sequence() algorithm are in pmask.algorithm (or in pmask) and generator and modifiers (the difference in pmask is less important) are in places like pmask.rng (pseudo random number generators), pmask.chaos (non linear generators), pmask.miscellaneous (List, Mask, Quantizer, Attractor, Choice etc). Someone else could use something completely different to produce OMDE objects than pmask and the continue the processing using OMDE or other OMDE-enabled tools. OMDE has also modules for pitch (omde.pitch, integrating the SCALA database of scales) and rhthm (omde.rhythm), both of which have room for being greatly extended and improved.
The CVS version OMDE/pmask includes contributions by prof. Zipfel in the omde.pitch and omde.rythm and a new omde.plot module to plot PDF sketchs out of your composition. Additional work is required in order to really integrate these features.
This OMDE representation of events as objects relies on the Python language object model. Going a step further, it opens the door to more abstract kind of musical objects, always espressed as Python objects. These objects are not directly mapped into score events but into whole groups of events and their properties are not the list of properties of the single events but properties of the set as a whole. This is a different kind of thing from the "aggregate" above and is not implemented at the moment in OMDE/pmask even if I'm already using a less formalized (and less functional) implementation of this idiom.
Since many people potentially interested in OMDE/pmask come from other algorithm or computer assisted composition experiences (Cmask, SCORE11 for example), I'm starting to think that it could be useful to add "native languages" parsers and converters inside OMDE. Such languages are very simple in general so it is feasible. I already studied SCORE11 and implemented the parser and part of the convertion of SCORE11 in pmask objects.