view workingNotes.rtf @ 1:1a32ce016bb9

Changed bestEstimate timing to work via time sent from Max not the elapsed time. This had caused some problems, but this version now working surprisingly well on MIDI files with variable timing.
author Andrew N Robertson <andrew.robertson@eecs.qmul.ac.uk>
date Thu, 18 Aug 2011 23:27:42 +0100
parents b299a65a3ad0
children 2ab6f4670cf5
line wrap: on
line source
{\rtf1\ansi\ansicpg1252\cocoartf1038\cocoasubrtf350
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\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 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}