[Question] Package structure

[aerhard]

A while ago, we've had a discussion about the general structure of mei2vf and related scripts; @zolaemil did argue for a modular concept, where one part (mei2vf) would convert MEI encoded music to VexFlow, other parts would pre-process XML data, process word text, etc. This looks like a good approach to me, but what do you think would be the best way to organize these components in a clear way and make them accessible? Keep MEI2VF as it is and provide all additional functionality in individual projects like MeiView (this would have the disadvantage that common functionality would have be to repeated in each project)? Have one big GitHub repository containing commonly-used code in sub-modules (common pre-processing methods, MeiLib, MEI2VF, text rendering methods, etc.), but store applications like MeiView separately? Or add other GitHub projects in addition to MEI2VF, containing other rendering and conversion utilities?

[zolaemil]

Yes, applications in separate repo for sure, more important the question what is generic enough to be included in the commonly used repo.

Forr example, meilib.js was born while developing meiView; the code I thought to be generic enough went to meilib.js and the code that I deemed project specific were kept under meiView. But this was just my judgment then, should we ever wish to reuse something else from meiView (especially stuff that are independent from the UI) it would be great to add the code to the common repo. Similarly if you crete code that is generic enough, the common repo would be the best place for it. I admit this is somewhat an ad-hoc structuring process, but if we keep the modules separated, hopfully it will not become too big a mess :)

Re organising repos: I think having a single repo for all commonly-used cod (both rendering and other processing) has the advantage of simpler dependency structure. (Yes, bower and alike can handle dependencies well, but only as long as releases are well defined. If the development is at a high peace, it may not be very practical to release each time you need to depend on a particular commit.) On the long run I can see vexflow-related code and other stuff diverging into different repositories, but I think we don't have to make this split just yet. On the other hand if we keep everything together, the MEItoVexFlow repository may overgrow its name at some point.

[aerhard]

Sounds great! I don't consider it too big of a problem that the repo name is MEItoVexFlow while MEItoVexflow would be one amongst other modules; it would remain the most important part of the repo. I think it would be very help- and useful to provide shared code this way.
I have always considered MeiLib as a self-contained module, but just to ask, do you think it should contain things like MEItoVexFlow-specific pre-processing methods (for example, code to transform MEI code not specifically written for MEItoVexFlow to MEItoVexFlow MEI)? Seems to me like that could be part of an extra module. I'll look through my code, too, to see if there are things that could be useful

[zolaemil]

I think code that transforms the MEI into an MEItoVexFlow compliant form is more related to the mei2vf module. I think it could even live in the mei2vf module. Having said that, if it has project specific logic, then it may better be separated from the mei2vf code base.

(just for reference, in meiView I implemented a filterMei() function which did this job)

[aerhard]

I think things like your filterMei() would very useful to mei2vf users. I was also thinking about adding functions which resolve code in abbreviated notation (like elements with the copyof attribute).

I just uploaded some scripts building on meiv2f, some of which I use at my project, some of which are more experimental. You can have a look at them there: https://github.com/aerhard/meisnippetviewer - One thing which could be useful as a general utility is a function which adds xml:ids to all elements without an xml:id (I've been wondering if adding them might even make sense in general in mei2vf).

I've also been experimenting a little bit with highlighting of individual notes etc. and with mouse event handling. I wouldn't make this an integral part of mei2vf (= the converter) so the mei2vf module can be used as a plain music renderer but it might be worth a thought whether things like that could form a part of a general "mei-web-tools" repo, parts of which users can choose to include or not.

[zolaemil]

I've also been experimenting a little bit with highlighting of individual notes etc. and with mouse event handling. I wouldn't make this an integral part of mei2vf (= the converter) so the mei2vf module can be used as a plain music renderer but it might be worth a thought whether things like that could form a part of a general "mei-web-tools" repo, parts of which users can choose to include or not.

Absolutely! Especially functions like calculating the highlighted area, and maybe even the events could be reused if defined in a reusable form. I wonder if we could keep in mind some MVC pattern here. Could be tricky, and not sure if it is a good idea to enforce the application of a specific design pattern, but definitely would be beneficial to keep things decoupled.

Re adding xml:ids, there's a lazy approach in m2v to assign xml:ids, if you use MeiLib.XMLID(elem) it returns the id or creates one if not defined. Do you think of any reason that would make it beneficial to assign them another way?