I saw this one but some guys say it is too limited... may be!

The best solution as you mentionned, would be to export as MusicXML (as you suggested). Then the one can finalize the editing on a dedicated tool?

I might be wrong but I thought Alda would stay more as a quick tool in order to compose freely. Then the one finalizes the piece and give the final touch on his favorite editor.

Not really maintained but could be nice to fork it and may be improve it:

https://cruncher.ch/blog/scribe/

The best solution as you mentionned, would be to export as MusicXML (as you suggested). Then the one can finalize the editing on a dedicated tool?

Right, this is possible, provided that we have a solid HTML5 rendering tool for MusicXML.

I might be wrong but I thought Alda would stay more as a quick tool in order to compose freely. Then the one finalizes the piece and give the final touch on his favorite editor.

Yes. This repository does not actually enhance the Alda language/interpreter; it demoes what Alda can do. Rendering the score shows interoperability: user can input the score in Alda format, we parse it, convert to {MusicXML, VoxTab, LilyPond, ABC} and render with all the bells and whistles 😄

Chiming in here to lend my support to the idea of converting Alda to MusicXML -- this is a feature that would be super useful for Alda itself, as it would open the door to importing scores into countless score editing programs, rendering them using LilyPond, exporting to a MIDI file, etc. etc.

If you find a way to do it using JavaScript, I can probably port it to Clojure and add it as an Alda feature. Or, we could implement it in Clojure (as part of Alda) and then include it in alda-cljs to port it to JavaScript.

@daveyarwood my aim here is to implement export to MusicXML (preferrably during the Web Audio Hackday, 26.9.). I am not that familiar with MusicXML yet, but the parsed arrays look like a suitable data format to get me started.

The only problem I see with musical notation engravers is the omission of bar information. I suppose these can be inserted automatically (with respect to some tempo/beat definition), but I am afraid that the underlying algo (that splits notes to make space for bars) might get rather complex.

Using the intermediate AST is a good idea, since the parsed score object will have less of the high-level information that we need. For example, the intermediate AST will have notes spelled out the way the composer intended, e.g. F# (vs. Gb), whereas the parsed score object will just have the MIDI note number and the pitch in Hz, which is not so useful for rendering sheet music.

Alda (having been designed as an audio language) is definitely missing some things that we'll be needing for score-rendering, like bar information as you mentioned, and also key information. Key information is something that's currently in the works -- there is a Pull Request in progress, which will at least make it possible to see in the parse tree when the key is set -- that should be sufficient, I think, to translate to a key signature in MusicXML.

As for bar information, I have an idea that I could hack into the Alda parser for you before your hack day on 9/26 -- instead of treating pipe characters as whitespace, I could have the parser capture them and include them in the parse tree, so you might get something like:

["note",["pitch","c"],["duration",["note-length",["number","4"]]]],
["note",["pitch","d"],["duration",["note-length",["number","4"]]]],
["note",["pitch","e"],["duration",["note-length",["number","4"]]]],
["note",["pitch","f"],["duration",["note-length",["number","4"]]]],
["bar-line"],
["note",["pitch","g"],["duration",["note-length",["number","4"]]]],
["note",["pitch","a"],["duration",["note-length",["number","4"]]]],
["note",["pitch","b"],["duration",["note-length",["number","4"]]]],
["octave-up"],
["note",["pitch","c"],["duration",["note-length",["number","4"]]]]

You could then infer the time signature of each measure by calculating the number of beats between bar-lines.

This should be super easy to hack in, I could do it today even :)

@ondras I read quickly the MusicXML during my lunch time.... I might be tired but... my first feeling was: holy sh**!!

It will take some time to implement it and test it. Let's do it! Coffee is cheap nowadays.

☕ 👍

MusicXML is incredibly complex, for sure! To keep ourselves sane, we can work iteratively, and just build something that makes very simple XML scores first, then refine it a little at a time.

A found a pretty good intro to the basics of MusicXML: http://www.slideshare.net/dparsonsnz/an-introduction-to-music-xml

In our case (web demo) it would be possible to create and have the xml file "downloadable" on client side, by using blob. So that we can host the website on a S3 or anywhere else.

Second option is to generate it server side (python, php). As I highly prefer working with node.js, it would implies to setup a micro EC2 instance, host the website there, nginx as a proxy for the node app doing the XML generation. Doing the job server side allow us to use XML libraries in order to reduce the implementation time and focus on the business need.

what would you choose?

@AdrienFromToulouse: I don't really have a preference -- both options seem equally good. I'll leave it up to you, @ondras and @kylestetz

Never used MusicXML so I have no opinion on the matter. General question to the room: how excited are y'all about visualizing the notation vs. all of the other aspects of the site that need to be built out? Not insinuating anything, just genuinely curious since this is something that "native" alda doesn't have.

MusicXML is incredibly complex, for sure! To keep ourselves sane, we can work iteratively, and just build something that makes very simple XML scores first, then refine it a little at a time.

Also, generating MusicXML will be easier than reading it, since Alda will be using only a fraction of what is possible with the complete language. MusicXML seems intimidating at first (it is an XML dialect after all), but I believe that a basic alda->musicxml conversion shall be pretty straightforward and easy.

In our case (web demo) it would be possible to create and have the xml file "downloadable" on client side, by using blob. So that we can host the website on a S3 or anywhere else.

Possibly, even without a blob (data-uri and the new "download" attribute for HTML5 links). For me, visualizing the score is the most ass-kicking aspect of conversion to MusicXML, but downloading sounds good as well.

General question to the room: how excited are y'all about visualizing the notation vs. all of the other aspects of the site that need to be built out? Not insinuating anything, just genuinely curious since this is something that "native" alda doesn't have.

Honestly, I have no other aspects to the demo site on mind. I suck at design so I just wanted to get things up and running, waiting for someone more skilled to do polishing, project managing, designing etc.

Also I believe that the work spent on generating MusicXML will not be void if we decide to move this functionality to the core Alda; porting an already-working code is often easier than starting from scratch. Someone has to pioneer this MusicXML stuff :)

@kylestetz, if you have other features you would like to see on this demopage, feel free to create individual issues for them! I would be happy to improve the repo in other ways as well; playing stuff and visualizing was simply the first that came across my mind.

As for bar information, I have an idea that I could hack into the Alda parser for you before your hack day on 9/26 -- instead of treating pipe characters as whitespace, I could have the parser capture them and include them in the parse tree

@daveyarwood, this is a cool idea. But the first MusicXML iteration could work without bars at all (I hope that MusicXML parsers won't choke on bar absence); we can have note/rest visuals and bars added later.

I gave this some thought and perhaps the automagical bar generator can be a neat (Alda) feature after all, what do you think?

@ondras I don't think having bars captured in the parser output will be all that useful for the audio-generating part of Alda -- essentially, it doesn't care what time signature a score is in, or where the barlines fall, it's just generating notes one after the other, so the alda.lisp part of Alda (the part that creates the score object) could just ignore the bar-line parse tree nodes.

But I still think bar lines would be a useful thing for Alda's parser to know about and include in the parse tree, so that we can use that use that information in MusicXML. At any rate, feel free to experiment with or without bar-lines in the parse tree! Whenever I get a minute (hopefully tonight/tomorrow), I'll make the change to the parser that will add the bar-lines in. I think it will be easy to add in.

@kylestetz If you're interested, it sounds like maybe you could start working on other features related to the demo site, i.e. design elements, implementing a REPL interface, etc.

I'd like to get involved too, but more on the alda-cljs side, porting functionality from Alda into ClojureScript so that we can use the resulting alda.js library for this web demo.

@ondras thanks for explaining! It's always nice to hear where the excitement is coming from.

I would love to take a design pass and build out the frontend. I am on vacation at the moment but next week I can spend some time thinking about it (I'll make an issue for it). In the meantime do whatever works for the frontend, I have no problem refactoring it later.

@ondras I've added ["barline"] nodes to the parser output. If you pull the master branch of the alda-cljs repo and run boot build, the newly generated JS file (target/main.js) will have the updated parser.

@ondras I've updated alda-cljs again to fix a bug where barlines were not allowed in between tied notes, e.g. you could no longer do things like this:

c1~|1~|1~|1

This is fixed in alda 0.6.3, and I've copied the grammar over to alda-cljs -- would you mind re-building alda.js again? I hope it's not too much trouble... perhaps this raises the question of whether there is an easier way to manage "alda.js" versions?

EDIT: Would it be easier if I re-build alda.js myself for each update and submit a Pull Request to this repo to update it?

This is fixed in alda 0.6.3, and I've copied the grammar over to alda-cljs -- would you mind re-building alda.js again? I hope it's not too much trouble... perhaps this raises the question of whether there is an easier way to manage "alda.js" versions?

Rebuilding is really no trouble at all for me.

EDIT: Would it be easier if I re-build alda.js myself for each update and submit a Pull Request to this repo to update it?

The easiest way is to directly commit the new alda.js into the web-demo repository :-)

How about publishing an alda package on npm?

@crisptrutski that would make sense, yeah. I am not sure if the current state of alda-cljs is considered complete...

Can push version 0.0.0-dont-use 😄

I think we should probably hold off on publishing anything to npm until we're a bit more stable 🚧

From here on, I'll probably just commit new versions of alda.js straight into this repo, unless there are some major (breaking) changes, in which case I'll submit a PR and explain the changes.

I pushed some very basic musicxml-related work. The demopage now generates a downloadable .xml file, but only a very small subset of both languages is supported. Also, no HTML5-based rendering so far.