search

ELVIS-Project / vis-framework

Thoroughly modern symbolic musical data analysis suite.
http://elvisproject.ca/
31 stars 6 forks source link

Unexpected Behaviour from Offset/Repeat Filters #334

Closed crantila closed 9 years ago

crantila commented 9 years ago

TL;DR: this is the bug caused by some voices with activity and others without.

After running the repeat and offset indexers, then sticking everything into a DataFrame, you end up with a situation where some voices will have lots of NaNs where they had repeated identical events that were removed. While the FilterByRepeat removes those NaNs, some of them can return when there are events in other voices during the one part's sustained events.

Personally I like this, because it means a composer made the conscious decision to have repeated counterpoint even when another voice was changing. But I have an idea that the profs don't like it, and @alexandermorgan definitely doesn't like it. So we could have a setting.

alexandermorgan commented 9 years ago

I'm not sure if I follow this scenario entirely, but it doesn't seem like you're talking about repeated counterpoint here but rather just sustained notes against a faster-moving line. Let's talk about this later this week.

crantila commented 9 years ago

vis_334

I think you do understand the issue. In the VIS 1.x series, if the FilterByRepeat indexer runs, the lower two voices in this image won't produce an n-gram (i.e., this measure is interpreted as though the lower two voices had a dotted half note). In VIS 2 so far, the lower voices here will be interpreted as "3 1 3 1 3." It's caused by forward-filling the "holes" left because of the upper voice.

At first I didn't think this was a big enough deal to bother fixing before VIS 2.0.0, but it significantly changes the results, so I've changed my mind.

alexandermorgan commented 9 years ago

I think having a setting that toggles between the various options is a good idea. The default should be that no events in voices other than the two being examined should have any effect on the analysis of the pair in question since we are supposed to have a contrapuntally-based model rather than a chordal one.

crantila commented 9 years ago

There was a time when "a setting" seemed like a reasonable solution. I think it's time to admit defeat: this problem is much larger than I previously thought, for the reason illustrated with this score example:

asdf

Who in their right mind would expect that this represents a Soprano-and-Alto 2-gram? Only if you ran the FilterByOffsetIndexer, right? Wrong. I don't yet fully understand what's going on here, but it's lucky I decided to count by hand for the integration tests in #327 because that's how I found this.

crantila commented 9 years ago

Good thing I discovered that, actually, because I started looking in a different place and found the bug quickly. Closed in commit 637d5bcb29a2d69f3cb06d16c66f94db6c54b8fa.