GeoGraphy: Structure


The actual implementation tries to be as modular as possibile by making a large use of the dependency mechanism typical of Model-View-Controller architecture (see http://en.wikipedia.org/wiki/Publish/subscribe).


What follows is a general introduction to structure. See the reference files for other infos. It is assumed that you evaluate the code as proposed in the text.


I. Sequencing 


The two main component classes are Graph and Runner.


Graph

It is devoted to handling all the data representing a graph. 


A graph is an IdentityDictionary following this format:


{vID: [x, y, vDur, vLabel, vOpts, [end, eDur, eID, eOpts], ...etc], etc:...}


where:

vID: ID of a vertex; 

x, y: its position

vDur: a duration associated to the vertex

vLabel: a label associated to the vertex

vOpts: usable to store optional infos related to the vertex

[...]: each following array represents an edge starting from the vertex 

this means: n arrays --> n edges from vID


The format of an edge array is:

end: the end vertex 

eDur: the duration of the edge

eID: an ID associated to the edge

eOpts: usable to store optional infos related to the edge


A new, empty Graph is generated by:


a = Graph.new ;


See Graph.


Runner

Runner is the class which allows to control all the graph actants on a graph. As a consequence, the constructor requires a graph instance. The Runner is used to set a general tempo for all the actants (default = 60 bpm).

Actants are always instantianted through the Runner, so that it is possible to trace them.


Consider this:


b = Runner.new(a, name: \Kobayashi).gui ;


The .gui message creates a GUI interface to the Runner b, which has the symbolic name "Kobayashi", just as an arbitraryy identifier. This interface will allows a graphical control of all the actants related to b.   You see a general control associate to the runner ("Kobayashi") and other slider labelled as free, as no actants have been instantiated through the Runner.

The interface is named "The Parallax View", as it deals with total control.


See Runner.

 

II. (GUI) Control


In order to control the process interactively two GUI elements are provided by the classes Painter and GraphParser.


Painter


A Painter object is a GUI object providing a screen where the graph is painted and some related functionalities. Due to its nice semi transparent black fumé color it has gained the name "Grand Verre". When a vertex is created, you can drag it on the screen: its x and y properties will be updated consequently. This allows the user to clean a bit the topology of a graph 


o = Painter.new(a, b); // paint a on a window 


Painter requires a Graph, but also a Runner, because while sequencing in real time it paints in red each activated vertex. More, a primitive algorithm maps the frequency of passages on a vertex  to its color (--> from blue it gets yellow): this can help in tracing paths on th graph. The colFact factor is a multiplier for the number of passages. Default value is 0.01, i.e. after 100 passages a vertex is  10*0.01 = 1, the lightest possibile. 

 

Note: there is also a  Grapher class that uses Graphviz' automatic layout capabilities to plot the graph on a png. Useful in case of topological investigations. To be documented.


GraphParser


The GraphParser defines some scripting commands in a micro language named iXno. Basically, this means writing strings representing simplified commands for manipulating Graph and Runner objects. These commands are parsed and translated into the opportune messages to Graph and Runner objects. It allows not to depend on pressing button but at the same time not to write SC code in order to control what's going on. Let's call it "live scripting".   In itself GraphParser is not related to GUI but you can pass the iXno commands from a GUI window.

 

p = GraphParser(a, b).gui ; // the parser and the gui


GraphParser requires a Graph, a Runner and, in case it is needed, a Painter (which is not the cleanest thing).

It replies to the .gui message creating a gui panel.

The upper row contains a server control and a clock. Under the clock there is a tempo bar.

The bottom text field is a generic parser field, in the sense that  you can type SC code (to be evaluated by pressing ctrl + return) and also iXno code (to be evaluated by pressing ctrl + P, like "parsing").


Each iXno command is in the form letter+ options.

E.g. you  can type sequence like this (or copy and paste, indeed):


e+ s90 1 s92 1 s94 1 s95 1 s90 a+ s95


and press ctrl + P.

 

The sequence is made of two iXno commands, e+ and a+. More commands can be on the same line as the parser will separate them (hopefully...).

e+ says: create an edge between a series of vertices. If the vertices do not exist, they are created.

The form is vLabel eDur vLabel. The vID is automatically generated. It is better to work with labels, as they are much more meaningful, and they can be used to store sensible audio/music information.

a+ says: create a graph actant on a  vertex. The vertex can be specified by vID or vLabel (as here). As a consequence the Runner view is updated with a gui field providing some controls and infos related to the actant.

By pressing the buttons on the Parallax View the process starts. 

With Kobayashi (i.e. the Runner button) you start all the actants, but you can choose to start each of them seprately. In thic case, ther is no difference.

You can set the weight of the actant by moving the slider.

On the Parser View (named "God bless Nim Chimpsky") you can change the tempo by moving the slider.


Or by typing e.g : 


t+ 480 


See 04. GeoGraphyGrammar.


II. Audio


Note that GeoGraphy is simply interested in sequencing aka composition. 

So, it is pretty well finished here, from this point of view.

But evidently in order to make some noise it is necessary to connect some synth device to GeoGraphy.

The idea is to instantiate a class representing an audio device and to make it communicate with GeoGraphy. So, very simply, different classes can be used to represent audio processing. All these classes inherits from an abstract Class, GeoAudio, which provides opportunes dependency facilities, so that you do not have to get bored with them. But surely some better, faster and cleaner approach can be proposed.



s = Server.local.boot ; // or use the panel in NimChimpsky, or evaluate in the GraphParse win

// An available synth

h = Sinusoider.new(b).initAudio ;


(Now you can tweak with sliders)


But see 03. GeoGraphyAudio.