Re: Hushing up Sibelius news?

[Olivier Biot]

On Fri, Feb 22, 2013 at 1:33 AM, David Kastrup <address@hidden> wrote:

Hilary Snaden <address@hidden> writes:

> On 2013-02-21 23:10, David Kastrup wrote:
>

>> However, LilyPond indeed has a weakness in as far as it does not
>> really have a "file format".  It is an evolving input language.
>
> If that's a "weakness", it's one I'm happy to see maintained
> indefinitely.

Well, it is not going away since the primary generator of LilyPond files
are humans rather than programs.

If you have a hammer, a weakness of screws is that they are hard to bang into furniture. The same holds with screwdrivers and nails. It all depends on the goals we want to achieve.

What scorewriters as Sibelius offer, is a tool that allows to input notes and see the (near) end result immediately on screen. For many musicians, remaining in the familiar music notation domain is the key reason why they want such functionality.

What music engraving software does, is extensively prettifying music expressions. Knowledge of music typography is very relevant in this realm. You get a lot "for free" from the tool (default formatting without tweaking), and you can still tweak a lot of the output to make it look the way you want it to.

 

As opposed to a "file format",
however, the only reliable reader (not just interpreter) of LilyPond
files is LilyPond itself.  That's a disadvantage for interfacing with
other programs.

To my knowledge there is no universally accepted standard yet for writing out music expressions in a machine readable format, I suspect for reasons of sheer complexity of the subject matter. Even the LilyPond notation language is in constant evolution (which by the way is a great thing).

In addition, writing a music _expression_ is one activity, while rendering the output is another one and tweaking the final output yet a third one. Most if not all score writing software and score engraving software existing today are still researching better ways to support easy music writing and editing, and they struggle finding their way in combining these workflow activities in a tool (or tool chain).

From what I understand, MusicXML is a reasonably well accepted format for exchanging rendered music expressions across electronic software tools. I was told that some editors want a MusicXML rendering of your score before they want to print it. This way they can still apply their own style to a digital score.

Personally I think that we first need to understand (and agree on) how a generic "ideal" music notation and engraving workflow should / could look like, and then start mapping existing (and missing) bits on this big picture. This may require starting with collecting "user stories". It would not surprise me if another intermediate language would emerge, and it would look surprisingly similar to MusicXML, in between the very compact and expressive LilyPond input language and the printed copy. And what if we could use a small USB keyboard to input notes and have a simplified graphical interface displaying what you just entered for a quick visual first inspection of the music just entered. Eventually this "input tool" will generate some machine readable code, e.g. as in "bare LilyPond input" (no dynamics, no slurring, no articulations / fingerings etc). In a next step we could start enriching the bare note input, then prepare it for printing.

Another workflow could be a composer maintaining his scores in such a way that they can make new arrangements, transpose the music etc for specific purposes. The sort of transformations on existing music expressions and the way to search in a music score repository may require yet another set of tools and who knows machine readable formats.

Just my musings.

Olivier