riugabachi/necrophagy

A type-level, statically-verified Haskell embedded domain specific language (EDSL) for writing guitar tablature.

necrophagy's Issues

Terminal-based graphical playback interface

For some songs, the ability to view track tabs the traditional ASCII way is still a nice to have.

• As the track is playing, the current note should be highlighted in a color (green maybe?) like in most modern graphical tab players.
• There should also be reload functionality upon source file save; if the new source doesn't compile, keep displaying the previous successfully compiled tab.
• 1-line info bar at the top
  • Current track name
  • Current playback speed
  • Current transpose amount
  • Relevant tab metadata if space allows
• 1-line command input at the bottom
  • Vim-style / search for bar number or marker name
  • Track-switching command
  • Playback speed command
  • Transposing command
• To minimize feature creep, the end user will be expected to maintain additional terminal panes as needed to use the REPL at the same time. All commands added to this TUI should be strictly relevant for session-by-session playback utility.

Implement Euterpea backend

A Euterpea backend will pave the way for MIDI generation and delimited-section playback, which are must-haves for any serious transcription workflow. This will require a great number of type classes and instances, and the internal representation of parsed graphs is still somewhat under-documented as of now.

Add test suite

Static verification is only as good as whether or not said static verification is correct to begin with, unfortunately. Fortunately, type-level tests are easy to implement, and there are plenty of tabs out there for reference re-implementation, though we will definitely want originals for edge cases.

Implement sound effects for various dynamics

Most dynamics currently do not produce the correct sound effect during playback and export. Implementing this to a high quality will require referencing TuxGuitar source to study the audio processing techniques used for each dynamic.

Download/upload integration for major tab websites

Investigate how feasible it is to automate downloading/uploading from/to UltimateGuitar and Songsterr. Will most likely require the user auth to each respective service. In so far as whatever is feasible, proceed to implement them.

Alternate syntax for Programs / Tunings

The current notation of Instrument `Tuned` Tuning is not ideal, as we have 6/7/8/9 string guitars for which the same tuning names apply to, however the current design necessitates n*m tuning data structures suffixed with the string number, such as BStandard6.

I propose the alternate syntax:

Program @(7 `String` DistortionGuitar `Tuned` BStandard)

And subsequently, a Tuning type family indexed by string count and tuning name.

Implement GP5 backend

GuitarPro 5 is currently the de facto binary file format for guitar tablature distribution. It is the only format guaranteed to work across all major tablature hosting websites. That said, the company behind it has never released an official spec, however there are plenty of GP5 parser implementations in other languages one could easily base this off of.

Ideally I would like to use a bidrectional binary parser for this, however I have not decided on which library I'd like to hedge my bets on. I could possibly update my old library describe for this, but nothing's guaranteed yet.

Additionally, we should discuss whether it would be worthwhile to add a GP5 -> Haskell source converter. It would most definitely not be trivial going in this reverse direction, however it is essential for editing tabs made by other users in order to submit revisions.