[jmsl] questions about JMSL Score's Transcriber

[jmsl at music.columbia.edu]

Hi Larry,

Some answers inline...

Larry Polansky wrote:
1) Often, when I work with pure real number data, and then dump the data 
in a MusicShape and transcribe, I get chords where I don't think I'm 
going to get chords. I often put a "minimum" duration in my code, 
flooring the computations (this is often something like .15). I still, 
however get lots of chords, where i think I shouldn't, as if durations 
are being set to 0 in some way i don't understand. Is there something 
I'm not understanding? It seems irrespective of how I set up my 
BeatDivisionScheme List

ND: A minimum non-zero duration gap between notes won't therefore 
guarantee that you don't get chords.  The durations are mapped to 
absolute time and then various rhythmic representations compete with 
each other to notate the data. The winning scheme acts as a kind of 
sequence of "slots" into which the nearest notes fall. The winner is 
chosen because the act of dropping the unaltered durations into these 
slots generates the least error of all other representations.  So even 
though two notes are 0.15 seconds apart, one might be a little before a 
"slot" and the other a little after it, and they both drop into the same 
location, forming a chord.

A duration of 0.15 is 6+2/3rd notes per quarter note, somewhere between 
a sextuplet and septuplet. If neither tuplet happens to be satisfied due 
to the way the notes are distributed, you'll get bunches of chords, 
probably binary 16th notes. It really depends on the data and your 
expectations.  I'd like to see a dump of a MusicShape that you are 
transcribing, some words about why you don't think there should be 
chords, and then see what comes out.  You might want to enable binary 
32nds in your BeatDivisionSchemeList. 

Larry Polansky wrote:
2) In the same sort of situation, there seems to be a radical difference 
in compilation time between different time signatures, but the same 
data. In other words, the same MusicShape transcribed with a 4/4 meter 
goes rather quickly, a 6/4 meter takes MUCH longer, and larger meters 
don't seem to get transcribe at all.

ND: Yes!  The search strategy has to deal with a rapidly expanding field 
of choices. For beat # 1, each BeatDivisionScheme gets an error score. 
Let's say there's 10 schemes in your list. The brute force method would 
be to calculate 10^beats paths (10 for the first beat, each oof those 
expanded to 10 more for the second beat, that's 100 so far, each of 
those gets 10 more for the third beat, that's 1000 now...) you can see 
that blows up real fast. Instead I use a heuristic search scheme which 
only expands the most promising scheme at every beat, with backtracking. 
So beat one generates 10 schemes with one winner. This single 
least-error-scheme is then expanded to beat #2. So now we have 10 new 
2-beat schemes (instead of 100). The winner is again expanded to beat 3, 
giving us 10 more. Backtracking kicks in when one of the earlier schemes 
shows least error, and so, holds a more promising representation (ie the 
winner in beat 2 may have led us down a bum path so we need to backtrack 
and follow a different one). And so it goes. So even though the 
heuristic search strategy dramatically reduces the exponential search 
space, it can still blow up for very large time signatures.  All this is 
very sensitive to the beat division scheme list and the time signatures 
and the data, so there are no hard fast rules.  So again I'd welcome 
some sample MusicData (just dump it to a file and email it to me!)

To dump source for a MusicShape do this:

try {
    PrintWriter pout = new PrintWriter(new 
FileWriter("larryisatroublemaker.java"));
    melody2.dumpSource(pout);
    pout.close();
} catch (IOException e1) {               
    e1.printStackTrace();
}

For example, looking at jmsltestsuite.TranscribeScore10, I just changed 
the line that reads TimeSignature ts = new TimeSignature(4, 4); to 
TimeSignature ts = new TimeSignature(13, 4); with no noticeable 
sluggishness.

Thanks,
Nick