view workingNotes.rtf @ 11:df9c838d0b8f

fixed bug where the full midi file was sometimes not drawn (since minNoteIndexToPrint) was at the max and did not decrease properly in draw routine

{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf350
{\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fnil\fcharset0 Menlo-Regular;}
{\colortbl;\red255\green255\blue255;\red0\green116\blue0;}
\paperw11900\paperh16840\margl1440\margr1440\vieww20940\viewh15820\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\ql\qnatural\pardirnatural

\f0\fs24 \cf0 USE ftmplayMidiFile in MaxMSP to send the MIDI notes in via OSC\
\
_ _ ______ __\
\
BUGS:\
When prior and posterior etc are split off the screen, it doesn't find the right indices for them. Are we writing the correct prior vector? constrained limits?\
\
\
using best estimate continually - good in the new note on function?\
\
+ + + + + + + + + \
\
best estimate locked to map so need to free\
\
need to do relative tempo estimates\
\
\
\
works\
bartok.mid counterexample:\
problem is that the tempo needs to estimate the likelihood confidence that the match is valid\
at the moment all are equally weighted.\
but if we know that the match is (n, k) then prob(loc_n) the phase at note n - gives us probability that the note is correctly identified.\
\
\
//new note\
in comes note\
\
decay speed distribution - so we have uncertainty about tempo\
\
cross update - so we have new prior for position\
\
\
//\
working well - 18/8/11\
\
need to look at :\
could weight the speed updates on the basis of how successful the location id was for the two notes. That way when we are on a roll we increase our ability to stay there.\
\
matches stored like this:
\f1\fs28 \CocoaLigature0 \
\pard\tx640\pardeftab640\ql\qnatural\pardirnatural
\cf0 	\cf2 //size, index of match0, index of match1, ....
\f0\fs24 \cf0 \CocoaLigature1 \
}