Update of /cvsroot/pure-data/externals/frankenstein/doc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2493/doc

Added Files: LINKS.txt README.txt chords_graph.doc chords_graph.sxw genomes-notes.txt maxlibnotes.txt model.doc model.sxw Log Message: initial checkin

--- NEW FILE: model.doc --- (This appears to be a binary file; contents omitted.)

--- NEW FILE: LINKS.txt ---

open source libs ready to be used...

AthenaCL: is a python software for algorithmic composition we could use some code through pyext http://www.flexatone.net/athena.html this is specific for post tonal theory http://www.flexatone.net/athenaDocs/www/ch-analysis.htm

AIMA Python code, working agents, etc. http://aima.cs.berkeley.edu/python/readme.html

BEAGLE, implements co-evolution, open source, C++ beagle.gel.ulaval.ca

open source c++ genetic algorithm: http://lancet.mit.edu/ga/

plain ansi C (multi platform?): http://sourceforge.net/projects/ga-lib

another in c++: http://sourceforge.net/projects/ga2

--- NEW FILE: model.sxw --- (This appears to be a binary file; contents omitted.)

--- NEW FILE: genomes-notes.txt ---

***read README.txt before this file***

this ideas are related to shostakovich prelude n.2 in a minor

how do we map notes <--> genome ?

--------------- 1st idea: whole MIDI, absolute values

keep all the chromatic values, all midi notes

the fitness functions and crossover functions will manage the thing (no notes outside current chord, etc..)

each gene is a byte, - first 7 bits for midi note (unsigned char, 0-127) - last bit for rest (1=play, 0=rest)

why yes: -not restricted to prelude n.2 musical space -not restricted to tonal music space

why not: -huge transition table, intervals table -we don't want values we don't need -difficult to write fitness functions that check for tonality, chords, etc..

---------------- 2nd idea: chromatic scale, chord relative

notes are relative to current chord but still in a chromatic space. the critics must choose the diatonic ones and discard atonal ones

each gene is a byte, - first 7 bits for midi note (unsigned char, 0-127) - last bit for rest (1=play, 0=rest)

why yes: -we can use the same melody to different chords -not restricted to prelude n.2 musical space -not restricted to tonal music space

why not: -still huge tables -difficult to write fitness functions that check for tonality, chords, etc..

---------------- 3rd idea: diatonic scale, chord relative

the musical space is diatonic, no more chromatic. critics need to work much less, they only have to know if a note is in the chord or not.

problem: how to use chromatic passing notes this way?

possibile notes are 7*4=28 (7 notes per octave) + passing notes we could use : 1 byte for each gene - 5 bits for note (0-32) - 2 bit for cromatic passing note (0=no, 1=descending, 2=ascending, 4=not used) - 1 bit for rests

why yes: -we can use the same melody to different chords -quick fitness functions -we don't have notes we don't want

why not: -restricted to tonal music space

---------------- 4th idea: chord notes

the musical space are the chord notes, not even the diatonic scale. critics don't have to check anything!

problem: how to use (chromatic or diatonic) passing notes?

possibile notes are 3*4=12 (3 notes per octave) + passing notes we should use a struct for the gene: { - note (from 0 to 16) - rest (0/1) - passing_note (from -4 to +4) }

possible passing notes are 9: no passing, from -4 semitones to +4 semitones

the fitness functions and crossover functions will have to care sbout rules for passing notes: +3 and +4 are allowed only for the 3rd note of the chord -4 and -3 are allowed only for the 1st note of the chord every passing note can exist only if the note before was next to it and proceeding in the same direction each passing note must resolve on the nearer chord note in the right direction

why yes: -we can use the same melody to different chords -quickest fitness functions -we don't have notes we don't want

why not: -restricted to tonal music space -restricted to 3-notes-chords-based harmonies (jazz is 4 notes based)

common problems:

i can think a way to rule passing notes (a passing note must come from a consonant note and go to a consonant note) but what can we do if a passing not is at the very end of the melody? (i don't know what will the next note be) ...we should have to know what will be the next chord...

Davide Morelli 17.09.05

--- NEW FILE: maxlibnotes.txt --- 081005

-the most universally useful maxlib object has to be [borax], since it not only gives us velocity, pitch, duration, but also can detect the number of voices currently playing, various delta values, can count note-ons (incrementally), amongst other things. It's like a swiss army knife of music analysis, and I suspect this is where our live input (in davide's diagram) needs to make use of maxlib in order to derive what we will feed the chord extractor, then graph.

-[gestalt] is for monophonic melodies only, but with [tilt], will detect the onset of melodies

-[chord] is based on Robert Rowe's Machine Musicianship algorithms for chord detection, and will successfully detect most chords, but most importantly will give us the MIDI note number of the bass note, and its -class-.

-[history] is interesting, because while it calculates the average value fed into its first inlet over N millisecond periods, it can also tell us the general tendency (up = 1, down = -1), which may be useful somewhere in the agent, to build more musical output. Also, [edge] is interesting because it detects falling and rising 'edges' in a sequence.

-[iso] is interesting, because it can store and play sequences of MIDI notes -and- onsets in milliseconds, but of course we're once again talking about monophonic melodies, unless we run several in parallel somehow, but they'd have to 'know' about each other.

-interestingly, [subst] performs what I see as the bit-shifting part of our current GA construction, and may actually help in understanding how we'd build a solderer agent.

-[match] could be useful, because it matches incoming data against up to 16 creation arguments, and outputs a list; this might help in determining how closely the live player is playing against generated output or suggestions? just a thought.

--- NEW FILE: chords_graph.doc --- (This appears to be a binary file; contents omitted.)

--- NEW FILE: chords_graph.sxw --- (This appears to be a binary file; contents omitted.)

--- NEW FILE: README.txt --- ***README***

Vatic, davide, please add notes and thoughts here for now...

****Ruby/Gridflow instructions***

In order to use some of the objects in the test patches, for now just [random_choice] within [manager] in the chord_melo_test patches, you will need GridFlow and Ruby installed.

Please find instructions here:

http://gridflow.ca/latest/doc/install.html

Once you have Ruby 1.8.0 or above installed, and GridFlow is happily starting in Puredata, you should see the following at PD startup:

setting up Ruby-for-PureData... we are using Ruby version 1.8.1 [gf] This is GridFlow 0.8.1 within Ruby version 1.8.1

Or, something similar.

Now, you will need to copy ruby/.gridflow_startup to your home directory. If it is somewhere else than /home/you/ or /Users/you, you can always load it from pd by using the Ruby console input (see pd's console window, and under IN - OUT), by doing:

load "/path/to/.gridflow_startup

You're now able to write puredata objects in Ruby!