search

leonawicz / tabr

R package: tabr. Notation-based and tidy music data analysis and transcription.
https://leonawicz.github.io/tabr/
Other
128 stars 10 forks source link

MIDI input to tabr output #3

Closed leonawicz closed 6 years ago

leonawicz commented 6 years ago

Read midi file (see tuneR package), create mapping function to tabr phrase syntax for sending to LilyPond.

Aside/low hanging fruit: Does LilyPond already have its own feature for converting midi straight to sheet music?

If so, that's a worthwhile wrapper function in tabr. Even if so, it's still worth having the tabr mapping function in order to offer full control over the intermediary content where the midi data has been converted to the tabr R syntax and can be available for interactive user edits.

areeves87 commented 6 years ago

http://lilypond.org/doc/v2.18/Documentation/usage/invoking-midi2ly

It appears midi2ly is a command line tool that can translate type1 midi files into ly files.

leonawicz commented 6 years ago

Interesting. It looks like this tool ships with LilyPond, which means no additional external library requirement. Awesome. This looks like the low hanging fruit. Trade off control for convenience.

When I have time I'm still planning to look into tuneR for the midi -> tabr functionality that could give users some degree of access to editing the arrangement and its presentation before rendering with tab.

theGreatWhiteShark commented 6 years ago

Maybe I missed it, but there is no function in tabr for importing LilyPond files, or am I wrong? So the conversion of .midi to .ly files would solve only half of the issue.

leonawicz commented 6 years ago

No function for that. tabr is primarily for authoring new tabs using R syntax. Any other import/export features are extras. But there's really no need to import .ly files. LilyPond does all the legwork of making the sheet music. tabr is either sending it your R code that it converts to .ly markup for you, or it is simply passing along an existing midi file or existing .ly file. It doesn't need to read or parse these files to do this; simply passes them to lilypond (.ly) or midi2ly (.mid).

I think you probably mean reading .ly for its own sake, analogous to the thing I'd ideally like to do with parsing midi files based on tuneR package code. But set aside the idea of having to write .ly markup that led me to make tabr, I cannot imagine trying to parse it and warp it into R syntax. If anyone wants to take a stab at it that's awesome.

I'd urge caution though. The .ly ugliness aside, a key problem is there are many different ways to specify the same things in LilyPond. I'm keeping the R -> LilyPond a nicely restrictive 1:1 mapping in terms of what kind of LilyPond markup tabr generates. This consistency comes at the cost of creating LilyPond files that are not going to be the most efficient text-wise (but that doesn't matter for the R user). But the reverse is far from the reality. There seem to be a crazy amount of ways to specify the same things in LilyPond, shortcuts, different markup styles and code chunk structures that still behave the same way, etc. The reverse mapping would be an n:1 nightmare by comparison unfortunately. At least that's my limited perspective on it at the moment.

leonawicz commented 6 years ago

A heads up in case anyone is thinking about midi2ly. I already have a working developmental implementation. I won't be able to push it until I'm off work and have time to clean it up. But it works, was super easy, definitely the low hanging fruit. I mainly need to add additional function arguments to give users control over passing arguments to the midi2ly tool.

There will be two functions soon, midily and miditab, analogous to the primary package functions lilypond and tab. The first sends a midi file to the tool for you to make the LilyPond file. The latter is a wrapper around the former that calls it to make the LilyPond file and then calls LilyPond to make the sheet music from it.

leonawicz commented 6 years ago

This is ready for testing if reinstall the package. See the docs for midily and miditab. These functions trade control for convenience, by relying on the LilyPond command line tool. But that was the intent. I did some testing and it all worked, but can use testing by more people on more systems.

I took a look at the level of information extracted from the function in tuneR for reading MIDI files, to see if there is enough there to work with for a more powerful approach that converts the MIDI data to tabr syntax. Short version: it's not going to happen. For this, someone else who is vested in this particular feature will have to take it on, possible rewriting in R and improving upon the midi2ly.py python script itself. What is brought in by tuneR is not even close to that level.

Let me know if the two functions are working though! Keep in mind, the accuracy of the output will be limited to what LilyPond can do in terms of parsing arbitrary MIDI files. Keep expectations low. LilyPond was similarly not designed with this MIDI parsing process in mind.

leonawicz commented 6 years ago

Closing this issue since the convenience functions appear to work as intended and I don't plan to develop a special tabr version that maps from MIDI data read by tuneR to tabr notes and note info.