[Feature] alda-clj API enhancement for parsing and de-parsing between the two alda syntaxes

[abhi18av]

Hi @daveyarwood ,

This issues builds on the idea regarding "commands for comparing notation" mentioned in #2 (comment)

What I meant is that for someone who is transitioning from one notation to another there could be helper functions which helps one see how to code actually converts to-and-fro.

In the previous issue here #1 , there was a discussion on how the two syntaxes relate to each other and then I started looking at this problem from the point of view of a layman from either side which is, as a pure programmer and as a pure musician.

To some extent this requirement was fulfilled in my use case by using spacemacs and cider based repl environment for Alda and Clojure which prints out the generated alda-syntax using Clojure constructs.

However, if we take an example of a musician who worked one's way with the music-theory based syntax and now would like to dig deeper into the lisp-syntax there could be helper function like (alda-syntax (... some clojure code ...) ) and similarly `(alda-lisp-syntax "piano: a b c") which could convert them from one form and back.

I think eventually this could help lay some foundation towards MusicXML processing as we could create some functionality to deal with the internal representation of music in Alda.

This is a rough sketch of an idea towards facilitating both kind of end users of Alda, please add your thoughts here as well :)

[daveyarwood]

I'm tracking now. This is a great idea! I think it would be especially helpful, for folks who know Alda and Clojure, but aren't familiar yet with "how to do X thing in Alda" using the alda-clj DSL, to have a way to explore the API by feeding a string of Alda code into a function and getting back the Clojure DSL version.

I'll do some thinking about this... I think I might be able to transform the output of the alda parse command (in --output events mode) into the corresponding Clojure code.

That "events" output might actually be close to what you have in mind re: the "internal representation" of a score in Alda. It is a list of events that looks like this:

$ alda parse -o events -c 'piano: o3 c/e/g' | jq .
[
  {
    "event-type": "part",
    "instrument-call": {
      "names": [
        "piano"
      ]
    },
    "events": null
  },
  {
    "event-type": "attribute-change",
    "attr": "octave",
    "val": 3
  },
  {
    "event-type": "chord",
    "events": [
      {
        "event-type": "note",
        "letter": "c",
        "accidentals": [],
        "beats": null,
        "ms": null,
        "slur?": null
      },
      ...
    ]
  }
]

---

There is actually already a way to go the opposite direction. alda.core/play! uses a function called alda.core/->str to turn events into a string of Alda code. If you ever want to see what Alda code will be generated, without also playing it, you can use ->str instead of play!:

(require '[alda.core :refer :all])

(->str
  (cram (note-length 2)
    (note (pitch :e))
    (note (pitch :f))
    (note (pitch :e))
    (note (pitch :f))
    (note (pitch :e))))
;;=> "{ e f e f e }2"