Feature Request: jams.convert(a, 'namespace'): from 'note_midi' to 'pitch_contour'

[tomxi]

I feel like this can be a unlossy mapping that doesn't need any arguments. Further more, I think it's legal right now to convert from 'pitch_midi' to 'pitch_contour' and 'pitch_midi' and 'note_midi' is basically two versions of the same. It would help my work flow in evaluating these annotations...

[bmcfee]

I think we don't have this already because pitch contour namespace semantics assume a dense (instantaneous) sampling, which assumes a frame rate. The midi namespaces are intervalic, so we would have to assume a sampling rate to make this work, and I want all automatic conversions to be parameter-free.

[tomxi]

I was able to convert 'pitch_midi' annotations to 'pitch_contour' though, and the conversion 'pitch_contour' is not 'dense'. See picture:

Right now I'm saving all my note annotations in 'pitch_midi' namespace even though it's deprecated, only because 'pitch_midi' can be converted to 'pitch_contour' and 'note_midi' can't

[bmcfee]

Hrm. This seems like a bug then -- maybe held over from when we revamped the pitch namespaces. Maybe this conversion should be removed.

@rabitt @justinsalamon what do yall think?

[tomxi]

If it counts for anything at all: personally I'm for these conversions, because they facilitate eval between note_midi type annotations and dense annotations like pitch_contour.

Right now all my reference annotations are namespace = 'pitch_midi' and I have pitch_contour estimation... It would be really nice if jams.eval can work on these sort of evaluations without too much work on my part.

[bmcfee]

@tomxi one of the fun things about the jams library is that you can extend it / monkey-patch it to do that sort of thing at run-time. If you have a non-standard conversion that you want to automate syntactically, you can just write it and register it using the decortator in nsconvert, and it doesn't need to live in the jams library. (See for example) I've done this sort of thing before for custom tag namespaces, and it's not too hard to do.

That might be a reasonable compromise if we can't work out a lossless or assumption-free converter that would make sense to include in the main library.

[tomxi]

That sounds like a pretty good solution going forward for my use-case. Thanks for the tip @bmcfee :)

[bmcfee]

I think we can call this one resolved.