[WIP] namespace conversion

[bmcfee]

Implements #28

• beat_position -> beat
• tag_* -> tag_open
• segment_* -> segment_label_open
• pitch_hz <-> pitch_midi
• chord_harte -> chord
• ~~~pitch_class -> pitch_midi, pitch_hz~~~
• ~~~chord_roman -> chord_harte (?)~~~

[bmcfee]

@justinsalamon give it a look. I'll whip up some tests shortly, but all you have to do now is say

>>> jams.convert(annotation, 'pitch_hz')

if such a conversion is possible, it will be done. If not, you get an exception.

It's designed to make adding new converters pretty easy (see the nsconvert.py module).

[justinsalamon]

@bmcfee just had a look (hence ninja star), looks good to me.

[bmcfee]

Okay, cool. I'll get on with testing then.

I'll also rework eval a bit to use the converters where appropriate.

[justinsalamon]

Sounds good, ping me if you'd like me to have a second look, and hopefully we can merge this pretty soon.

[bmcfee]

Ok, I think this one's ready to go.

Give it a last CR pass and I'll merge.

[justinsalamon]

@bmcfee am I right in understanding that you're validating the jams by converting it to the desired namespace and then checking if it validates against this namespace?

If so, doesn't this mean you're not only doing validation, but also conversion, under the hood?

[bmcfee]

The test was previously

"Is this annotation of namespace X?"

and is now

"can this annotation be interpreted as a valid instance of namespace X".

I think for evaluation (and sonification) the latter is what we really want.

[justinsalamon]

Right. So let's say I have a pitch_midi annotation, and I validate it against the pitch_hz namespace, which would validate fine in this new scenario. So I then try to use this annotation with the transcription eval wrapper, which expects pitch_hz annotations, and it breaks.

Now of course in practice I'll be adding a conversion step to the transcription eval wrapper such that any annotation provided is converted into pitch_hz, so this wouldn't actually happen. But could this type of scenario, where you validate against a namespace different to the one your annotation actually is (but convertible to) and consequently get errors further down the line somewhere?

[bmcfee]

So I then try to use this annotation with the transcription eval wrapper, which expects pitch_hz annotations, and it breaks.

Ah, I see what you're saying. I forgot to change the return type.

Perhaps this should be renamed to coerce_annotation.

[bmcfee]

Ok, I've updated the validation logic.

Instead of returning true (which was never actually checked) it now returns the coerced annotation, which is what gets piped into mir_eval.

[justinsalamon]

Yes I just had a look. Already added a couple of line comments for your attention.

[bmcfee]

for example here, does this mean you would validate a chord_harte annotation by trying to convert it to the chord namespace and check if it validates there? Is this safe?

This is safe because chord_harte is a (proper) subset of chord. Going the other direction would not be safe in general. (Similarly for conversion between closed tag or segment vocabularies.)

It wouldn't be hard to do a best-effort reverse conversion (chord -> chord_harte) by clobbering the namespace and calling validate. If it passes, we're good. If it fails, reraise the exception saying that you have an uncastable input (eg, a sus chord).

I'd prefer to not go down that rabbit hole though, since it opens up a lot of possibilities for attempted conversion. Better to stick with a set of well-defined converters that can keep guarantees about the output.

[justinsalamon]

This look safer, yes

[bmcfee]

!resolved