MUSPY library

[PRamoneda]

Muspy is a library for music generation presented on ISMIR 2020.
https://github.com/salu133445/muspy

Muspy first stage loads the datasets as mirdata. However, It is a wider library that covers many music generation stages. As can be seen in this poster:

link to poster

---

loader example

here an example of dataset loader (MAESTRO):

https://github.com/salu133445/muspy/blob/2f24836796180cefba1867b31d2a4ea1f9cadfbb/muspy/datasets/maestro.py

---

Muspy loaders issues:

• It is very MIDI focused
• It has a strong dependency:

---

My questions:

Should we add symbolic support to mirdata?

Could we speak with them to search for synergies?

[rabitt]

@PRamoneda I'm glad you brought this up! @magdalenafuentes and I were discussing this offline as well. I definitley think we should find a way to find synergies between the libraries.

One option is to not support symbolic datasets in mirdata, and point people to muspy if they're interested in symbolic datasets. In this case, we'd be deciding saying that mirdata is only for audio/audio feature + annotation datasets.

Another option as you suggest is to see if there's a way that the two libraries can work together to be compatible, maybe having muspy as a dependency, or agreeing on some high-level api choices to make one easily usable with the other.

Either way, we should definitely avoid duplicating efforts! I have to say, so far, I lean towards not putting symbolic (non-audio) datasets in mirdata. The two formats have different needs and tooling, and it could help us limit the scope of mirdata while not duplicating the effort. That said, I'm very happy to talk with the muspy people and see how they could work together.