Music is inherently abstract. Even trying to point to some thing, or some phenomena as music's most concrete expression can be perplexing. Further, virtually every bit of music theory is expressed in terms of abstractions. And implicit in Zylaphon's system control Blackboard architecture is an assumption that the problems Zylaphon will solve are effectively expressible as levels of abstraction.
In the following paragraphs it must be understood that the phrases, abstract score and performance score may be applied to more channel types than just ChBarDiatonic. That is, score, either abstract or performance need not contain anything even remotely related to sheet music, i.e. staves, notes, rests -- that stuff. Other kinds of abstractions will do just as well -- assuming someone has written the code to extend Zylaphon in those other directions.
Score/sheet-music is a codified abstraction of music. And and a very lossy one at that. In order to become music, a musician must "transform" the score by applying to it a wealth of domain knowledge and domain sensibility to say nothing of motor skills. Zylaphon provides two ordered levels of abstraction that approximate score, abstract score and performance score. Abstract score is more abstract than sheet music and roughly corresponds to a reduction or a composer's condensed draft. Abstract score models only those elements that are directly relevant to harmony and counterpoint (how ever those might be defined for a particular "style"), it has no octave doublings, no instrumentation info and little performance data beyond phrasing. Performance score, on the other hand, is more concrete than sheet music as it has embedded in it performance data that would otherwise be provided by a performer. One can, of course, manually enter data into a notation view, refrain from adding both non-standard performance data and meta-data. and end up with the equivalent of sheet music. But the purpose of score entry is to collect and/or manipulate data for at least some processing. However, the more serious processing one wants done with the score the more meta-data is required.
Zylaphon treats performance score as the surface of a composition, and is Zylaphon's most concrete representation of music outside of a MIDI file or midi stream. The abstractions from which it is generated or which are derived from it are placed beneath the surface, the more general abstractions (the less concrete models) are placed below those that are more specific. This hierarchy forms the score's deep structure (Chomskian or not) which lies below that surface. This terminology can be confusing because the root, the deepest abstraction could also be called the highest -- i.e. consistent with the concept of "a high level of abstraction" which places the most abstract representations "up there" with Plato. Just keep saying, deep abstract, shallow concrete.
Finally, by convention, the set of all abstract channels must map to a complete performance score, and optionally, MIDI file and playback stream. The performance set is required to map to MIDI file and playback stream, for that is its purpose.
Zylaphon's vocabulary of abstraction:
Zylaphon must be able to model a wide range of relationships among temporally coincident abstractions at various levels. Ignoring the carrier, the figure below is a schematic of a hierarchy of abstractions that conform to the structural requirements of Schenker style generative harmonic analysis. Note that the horizontal axis is taken as time, advancing from left to right. Also, the visual breaks between the resolved elements do not indicate silence, they are just visual aids.
Performance Score Abstract Score Carrier (infrastructure)
Formally speaking the lower three levels constitute a tree graph, though in a non-standard representation that shows how the nodes of the trees map to time. Such Hierarchical trees come in an infinite variety, some categories of which have structural forms that are of importance to Zylaphon.
.
In theory abstractions that model both elisions and transitions have nodes whose time domains overlap, this in no way changes the topology of the graph and they remain trees.
In practice regions of elision or transition are treated as a distinct class of spans. Keep in mind that, as implemented, this part of the API infrastructure is defined in terms of virtual objects; meaning you are free to chose virtually anything in the way of specifics when you, as a developer, create a sub-class from it ;)
As deep abstractions resolve upward and become more concrete, there is a point when some of those that apply to multiple channels resolve into abstractions that affect individual channels or subsets of those initially covered.
z
Not all hierarchical resolution abstractions are ordered in time -- the graph below might be used to model transformations of a motif, for example. Here, below the third level, the blue infrastructure bar is a "band" of pinkish colored bars which are representations of time domains over which the presence of a motif is to be felt. They differ from the abstractions considered above not only by the fact that the resolution abstractions are unordered, they also overlap and so their domains are non-exclusive with their siblings.
These are best approached by example. Say you are creating a longish peace that has a couple of movements or tracks. You have some motifs and an idea about what RhythmicEnergy means in context of your piece. Your first task is to assemble a functional definition for RhythmicEnergy, which process will be covered elsewhere. Once done, you may draw a continuous parameter describing how that parameter changes over time. If you have embedded the parameter in a division (measure, track, etc.) as a Hierarchical-Continuous-Parameter and have defined sections as Branches of the division, a piece of the parameter will be inherited by the section when the movement/track abstraction resolves into its higher level components. Further the parameter's value may diverge from the section inherited, so long as the divergence meets certain constraints, the first of which requires that the area under the section not change.
