aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorDavide Morelli <morellid@users.sourceforge.net>2005-10-18 23:10:53 +0000
committerDavide Morelli <morellid@users.sourceforge.net>2005-10-18 23:10:53 +0000
commiteb9ef05774af20edb43118182834c18a4ac70707 (patch)
treec7ae7be5449dc270e37f3f62ada9840d4efdf0cd /doc
initial checkinsvn2git-root
svn path=/trunk/externals/frankenstein/; revision=3734
Diffstat (limited to 'doc')
-rwxr-xr-xdoc/LINKS.txt26
-rwxr-xr-xdoc/README.txt27
-rwxr-xr-xdoc/chords_graph.docbin0 -> 75264 bytes
-rwxr-xr-xdoc/chords_graph.sxwbin0 -> 16853 bytes
-rwxr-xr-xdoc/genomes-notes.txt125
-rwxr-xr-xdoc/maxlibnotes.txt16
-rwxr-xr-xdoc/model.docbin0 -> 17920 bytes
-rwxr-xr-xdoc/model.sxwbin0 -> 6944 bytes
8 files changed, 194 insertions, 0 deletions
diff --git a/doc/LINKS.txt b/doc/LINKS.txt
new file mode 100755
index 0000000..d8685c5
--- /dev/null
+++ b/doc/LINKS.txt
@@ -0,0 +1,26 @@
+
+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
+
+
diff --git a/doc/README.txt b/doc/README.txt
new file mode 100755
index 0000000..524dfc1
--- /dev/null
+++ b/doc/README.txt
@@ -0,0 +1,27 @@
+***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!
+
+
diff --git a/doc/chords_graph.doc b/doc/chords_graph.doc
new file mode 100755
index 0000000..e8390c2
--- /dev/null
+++ b/doc/chords_graph.doc
Binary files differ
diff --git a/doc/chords_graph.sxw b/doc/chords_graph.sxw
new file mode 100755
index 0000000..9f901ec
--- /dev/null
+++ b/doc/chords_graph.sxw
Binary files differ
diff --git a/doc/genomes-notes.txt b/doc/genomes-notes.txt
new file mode 100755
index 0000000..e39e524
--- /dev/null
+++ b/doc/genomes-notes.txt
@@ -0,0 +1,125 @@
+
+***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
diff --git a/doc/maxlibnotes.txt b/doc/maxlibnotes.txt
new file mode 100755
index 0000000..532ddf9
--- /dev/null
+++ b/doc/maxlibnotes.txt
@@ -0,0 +1,16 @@
+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.
+
diff --git a/doc/model.doc b/doc/model.doc
new file mode 100755
index 0000000..af2fcc2
--- /dev/null
+++ b/doc/model.doc
Binary files differ
diff --git a/doc/model.sxw b/doc/model.sxw
new file mode 100755
index 0000000..b3b446f
--- /dev/null
+++ b/doc/model.sxw
Binary files differ