NewsWorksSoftwareTextBioContact
background image

[STSM] Designing models

April 30, 2009

The STSM is drawing to a close and I am heading back to Bergen tomorrow. A major part of the last few days have been spent thinking about how to organize data in FTM, and sketch various possibilities.

States_and_sequences

There are two basic classes of raw data that I want to be able to capture, representing vertical and horisontal reading and control of the data flow:

  • Instant snapshots of current state.
  • Sequences of timed events.

There are several approaches to how to capture and work on both of these.

Storing states

Instant snapshots could be read into a dict (dictionary) or a mat (a matrix containing any kind of data). Often only the single-value parameters will be of interest. These could be collected into a fvec (vector) or a column or a row of a fmat (float matrix) , provided that another dictionary could be used for mapping between matrix rows or columns and OSC addresses. It is more efficient to append rows than columns to a fmat, so rows would probably be the preferred format.

Storing sequences

There are no less options concerning sequences. FTM provides two time-tagging data structures that could be used, track and sequence. The conclusion from discussions over the past week is that sequence will be preferable to track.

My approach so far has been to use one sequence per parameter. An alternative solution would be to record all parameters into the same sequence as tuples by combining the OSC address and the argument(s)/value(s). This sequece could then be post-prosessed and each parameter distilled from it.

For a while it has been considered to implement support for a multitrack sequencer in FTM. That would be an attractive solution, ensuring that all data is bundled in one object, while still providing direct access to the individuall OSC parameters.

Resampling and interpretation of data

Sequences are recorded using variable sample rate. Some of the processing I want to be able to do require sequences to be resampled with fixed sample rate. Deppending on the application I can imagine needing different sampling rates; I might want to align sequences by resampling them with a shared sample rate, or with a constant total number of samples, in spite the fact that durations might vary.

Segmentation of events would be a more advanced analytic approach.

Aggregated data

When resampling sequences it would be useful to be able to store them as vectors with additional meta information attached, e.g. OSC address, sampling rate or duration, in a similar fashion to aggregated data in RubyOnRails web applications:

“Database columns have a limited set of types: integers, strings, dates, and so on. Typically, our applications are richer — we define classes to represent the abstractions of our code. It would be nice if we could somehow map some of the column information in the database into our higher-level abstractions in just the same way that we encapsulate the row data itself in model objects.”1

We have discussed extending FTM classes to support meta information. Under the hood fmats already supports certain specific meta information required by some of the Gabor processing algorithms, in particular PSOLA.

For the time being the best solution will probably be to use a dictionary representing the aggregated data, and ensure that it contains a reference to the sequence or vector itself.

Data and Model-View-Controller (MVC) design

A series of time tagged values can be represented in at least three different ways in FTM; as a sequence, a bpf (break-point function), or as a fmat with two columns. Regardless of the representation, each record is a point in the two-dimensional time-value coordinate system.

Model-View-Controller (MVC) design have been a source of inspiration for structural design of Jamoma. Jamoma do not yet apply true MVC separation, but we are moving in that direction. For Jamoma development MVC have been used to separate the algorithm of the module (the subpatch doing whatever the module is supposed to do), the view (GUI and OSC communication are two views for interacting with the patch) and the controller, made up by the core Jamoma externals handling parameter state and internal and virtual communication within and between patches as well as the OSC communication taking place internally between these externals and the algorithm.

Maybe MVC principles could also be applied to the data structures themselves. The sequence, break-point function and fmat could be considered different views of the same underlying model. The Jamoma dataspace library could be though of in simialr terms. The dataspace library enable dynamic mapping between different units. For instance gain levels can be described as linear, MIDI or dB values. These could all be considered different views of the same underlying data. In many ways the C++ code of the dataspace library work this way already.

How would data be structured in a database application?

Classes_as_models

Recently I developed a new web site for BEK using RubyOnRails, getting additional assistance from Espen Sommer Eide. Rails use a database for storing the dynamic content of the site, and a major design issue was how to construct the database models. Rails suggest certain patterns for linking tables that I find productive when studying relationships of data in other contexts as well.

  • One-to-one: A one-to-one association (…) is implemented using a foreign key in one row in one table to reference at most a single row in another table. A one-to-one relationship might exist between orders and invoices: for each order there’s at most one invoice. 2
  • One-to-many: A one-to-many association allows you to represent a collection of objects. For example, an order might have any number of associated line items. 3
  • Many-to-many: Finally, we might categorize our products. A product can belong to many categories, and each category may contai nmultiple products. This is an example of a many-to-many relationship. It’s as if each side of the relationship contains a collection of items on the other side. 4

One-to-many relationships seems meaningful for a number of applications. There might be several recorded sequences of one parameter, several resamplings of a sequence, or several recordings of states for the same parameter(s). The diagram above tries to envisage how such relationships could be designed in FTM. In FTM I would probably need to use dictionaries as joints between models.

How to proceed? Do I try to design a system from top downwards, or rather from bottom up, starting out with the more primitive structures? I guess I will do a bit of both. The emhasis will be on prototyping, a modular exploration of possibilities and solutions through development that is not aiming at immediate fixed solutions of general use, rather a method for further research of problems and possibilities.

References

1 Ruby, Thomson & Hansons: Agile Web Development with Rails. 3rd Edition. The Pragramtic Bookshelf, 2009, p. 348

2 ibid. p. 338

3 ibid. p. 338

4 ibid. p. 339