Csound Csound-dev Csound-tekno Search About

Re: why not database as score generator?

Date1999-05-02 06:28
FromMichael Gogins
SubjectRe: why not database as score generator?
This could be interesting, but I urge you to test the speed of note access
in your database with a test program using realistic numbers of notes.

You probably will get better results than I did, when years ago I used
Microsoft Access to do something like this on a 486 PC. In a word, it was
too slow for me in the context of generating 10 K notes every few minutes
for interactive algorithmic composition.

Probably speed is much better now, but you should check it out just to be
sure.

-----Original Message-----
From: Tobiah 
To: Csound List 
Date: Saturday, May 01, 1999 11:50 PM
Subject: why not database as score generator?


>My company has been using Linux, the PHP CGI, and the Mysql SQL
>database server as a key propellant for it's business.  I love
>this environment so much, that it got me to thinking.
>
>When I make a large piece of music with Csound, I end up
>littering a large directory tree on my hard drive with
>endless lists of 'notes' portrayed in ASCII.  This fact
>is actually quite soothing to me in itself!
>
>What has happened to me, is that after having been inundated
>with various techniques of database creation and management
>at my workplace, I have actually begun to see that the methods
>that I have been using at work could actually reinforce and expand
>those that I have been using at home to manage my music data.
>As yet, I am focusing on 'score' data.
>
>I want to be able to structure score data so that different aspects
>of my piece (different score generator programs) could have a notion
>as to what another part of the piece is doing, or using as pitch or
>timing information.
>
>My idea is rather undeveloped as yet, but I have a preliminary notion
>as to the structure of the data that would be used.  I am going to
>list it here as an SQL database structure:
>
>
>CREATE TABLE note (
>  note_rsn       bigint(20) unsigned DEFAULT '0' NOT NULL auto_increment,
>  opcode        float(4),
>  start         float(4),
>  end           float(4),
>  PRIMARY KEY (note_rsn)
>);
>
>CREATE TABLE pfield (
>  pfield_rsn    bigint(20)      unsigned DEFAULT '0' NOT NULL
auto_increment,
>  p_note_rsn    int(10)         unsigned,
>  value         float(4),
>  PRIMARY KEY (pfield_rsn)
>);
>
>CREATE TABLE notelist (
>  notelist_rsn  bigint(20)      unsigned DEFAULT '0' NOT NULL
auto_increment,
>  p_note_rsn    int(10)         unsigned,
>  name          varchar(20),
>  PRIMARY KEY (notelist_rsn)
>);
>
>
>
>So, the 'note' is the center of attraction.  If there are pfields beyond
>the third, then they are linked to the note by way of the 'p_note_rsn',
>or, 'pointer to note record sequence number'.  A similar relationship is
>held between the 'note' and 'notelist', so that an actual score can be
>pulled from 'notelist' through the 'name' field.
>
>I was walking along the coast of southern California today, mingling
>my toes with the surf, when a very striking thought blessed me as I
>was mulling this data-structure over and over through my mind:
>
>Supposing there were specific data types for things like
>'sets of notes'.   By this I am referring to a vague concept that
>was brought up to me by a teacher that I admired.  He showed me
>a book (the title of which escapes me now) that had been compiled
>by a composer that was enthralled with the idea of analysing and
>composing music from the standpoint that there is a very basic unit
>of music, called a 'set', which is really just an array of pitches.
>
>The above data structure allows for the functionality of the present
>(past?) 'cscore' lib.  I know however, that there is a larger canvas
>of relationships between score elements to be covered.  I like the
>idea of the SQL server as the core of score data, because it can span
>pieces, users, computers, and continents!  I would like to consider
>'hosting' score data, for use, and particularly *dynamic* use by the
>entire globe of csounders.
>
>I am going to use perl to tie things together.  I will try to make the
>interface to the database generic, as with the DBI:: package.
>
>I solicit any help in the design of the tables of this database, and
>in the surrounding software.  I want it to be done correctly.
>
>Thanks,
>
>Toby
>
>        - There otta be a law -