2013/3/13 Bob Tennent <[email protected]>: > Dirk say: > >> We need something which can read PMX, M-Tx or ABC; convert it to >> a central structure; from that central structure write PMX, M-Tx, >> ABC, MusiXTeX, Lilypond, MIDI, etc. > > Do we? Yes, there are several "text-based" formats for describing > music (MusiXTeX, PMX, M-Tx, ABC, PMW, LY, ... ). But why would > anyone need to *inter-convert* these unless they were abandoning a > format and needed to convert "legacy" files to another format? > > Pandoc is needed because there are often imposed requirements for > "intermediate" formats; for example, documentation sources must > be in a specific format or a pointy-headed boss insists on .doc > format. But for us, there are rarely such requirements; we are just > producing music scores (and parts) and midis; once we've learned > a suitable input language, there's no reason routinely to convert > descriptions to another.
>From the man who gave us Lua-based musixflx, no less? Ouch, this hurts. It seems obvious to me that the input->native->output model of development is more productive than the input->output model. You add the number of supported inputs to the number of supported outputs to get the amount of work, but you multiply them to get the pay-off. It also seems obvious to me that relying on tools written in Fortran and Pascal by one-man programmer teams is not ideal in the longer term. But let me demonstrate that even if I have mastered the perfect input language, the Panmus model would still help me. In this whole tex-music game, we are all wearing several hats. - composers/arrangers/transcribers: we've got some scrawled music in front of us, maybe in our heads, maybe at a piano, we just want to get it into computer-readable form as fast as possible. - editors/typesetters: we've got a preliminary score into TeX, it looks less than perfect, we start tweaking it this way and that by going back to the source code, going through the whole cycle (thanks for automating this part so nicely) until it is immaculate. - programmers/developers: we continue sharpening our tools and adding features. The way it is now, I type in originally in musician mode, using only a very basic subset of PMX which I know by heart. (This "I" may well be a singer who can't even sight-read, basic PMX is that easy.) When I get to the adjustment stage, I switch to editor mode, but since I am not a full-time typesetter, I have to open the PMX Quick Reference card to remind myself of whether left offset is `l` or `e`, etc. All the time the developer in me is saying that a GUI which displays the score and lets me do adjustments via the mouse would be very nice at this point, instead of guessing X so many notehead widths. If I had the luxury of Master's students needing projects (hint-hint), I would be in heaven. Such a GUI would be easier to write if each note is already an object in a Lua table, when the GUI author would not need to know what the source representation was. That Lua table should be exportable not only to MIDI or TeX, but also back to the original source language. I am guaranteed to get nice, clean, correct PMX. If I used M-Tx, the exporter would beautifully align things vertically and insert all the optional bar lines. So even if I continue in my preference to keep music source as M-Tx, the availability of Panmus would improve my productivity, the legibility of my music text and the quality of my printed scores. That's why I hope my dream can turn out to be a proposal. Dirk ------------------------------- [email protected] mailing list If you want to unsubscribe or look at the archives, go to http://tug.org/mailman/listinfo/tex-music
