search

frmatthew / exsurge

A JavaScript library for rendering Gregorian Chant in square note notation
MIT License
54 stars 13 forks source link

Feature/incremental recompile #40

Closed bbloomf closed 8 years ago

bbloomf commented 8 years ago

I don't think this is quite ready for prime time yet, but I thought I would submit a pull request to see whether it's even something you'd be interested in putting in exsurge, since it's not really much use from a server side perspective. Also, more work would need to be done to handle clefs properly, but I thought I'd see what you think of this.

frmatthew commented 8 years ago

Working on the lyrics recently, I have made some significant changes to the gabc interpreter process, and I've been keeping this pull request in mind. First of all, some changes I've made to the gabc code include the ability to parse single words (e.g., "CHris(ffg)tus(f.)") at a time. This would allow the score to keep keep track of how a substring of the gabc code is mapped to an array of notations. I think, as you're doing here, it probably makes sense to track the code at the word level, and recompile whole words as they change.

For the implementation of it, I'm thinking of having two paths of compilation/layout. One would be a synchronous call (performLayout?) for use on the server which would brute force layout everything in one go, without timeouts or anything. The other (performLayoutAsync?) would be the client side version which would yield to the browser, and also allow partial recompilation.

In the process maybe the language could be clarified...I've never liked the "compile" language I started using, because it's not very clear what it means...

In any event, I think maybe I can get this updated lyric stuff into the repo, then maybe you can start a fresh pull request based on the updated master branch. I'm afraid I really cluttered up the repo when I was trying out a number of continuous integration services and I'm trying to rectify that.

bbloomf commented 8 years ago

Sure. I like the idea of having a synchronous version and an asynchronous version. I will take a look at your new code, and maybe make a new pull request.

bbloomf commented 8 years ago

OK, I've updated this branch to reflect the latest changes on the master branch. Take a look, and let me know what you think.

frmatthew commented 8 years ago

The point of using a function to update the clef is to decouple as much as possible the gabc interpreter from the score. The gabc interpreter shouldn't need a score in order to parse a word or parse notations, it just needs a clef and the ability to update that clef. This will be important in the future so that notations can be parsed independent of a score object. Furthermore, if the score has a changeClef function on it, then it gives the impression that the score is somehow managing state, but it isn't and it shouldn't because that's what the ChantContext is for.

bbloomf commented 8 years ago

Oh, sure. I should have thought about that more before changing where that function was defined. The problem with defining it inside of parseChantNotation() was that I didn't want to define the exact same function inside of updateChantScore(). I will think of another solution.

bbloomf commented 8 years ago

I just made a new commit to revert this change and implement, I think, a more viable solution.

frmatthew commented 8 years ago

For now I'll merge this and see how far it gets. I'm uneasy about the intertwining between gabc and the score class that I started when creating the gabc code but that's getting tighter. I think I would prefer to eventually separate them entirely, but I'll need to think on that.

The reason is that I'm thinking of prototyping a different language to describe chant notations that would work better for a wysiwyg chant editor.