Talk:Comparison of scorewriters

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Software / Computing  (Rated List-class)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 List  This article has been rated as List-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.
WikiProject Lists (Rated List-class)
WikiProject icon This article is within the scope of WikiProject Lists, an attempt to structure and organize all list pages on Wikipedia. If you wish to help, please visit the project page, where you can join the project and/or contribute to the discussion.
 List  This article has been rated as List-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.

Why is Denemo listed as "WYSIWYM" instead of "Yes"?[edit]

In the "WYSIWYG Editor" column, most systems are listed as either "Yes" or "No", but Denemo has a special entry of "WYSIWYM with real notes". The same could be said for MuseScore, no?

Any objections to simply changing Denemo's "WYSIWYG Editor" to "Yes"?

PeterWhittaker (talk) 17:16, 28 November 2011 (UTC)

I imagine that was done because Denemo is a GUI for Lilypond, rather than a fully featured standalone scorewriter. Also on the Denemo web page that is how its authors describe it. Strictly many of these programs are WYSIWYM rather than precisely WYSIWYG, as the screen and printed output are necessarily a bit different. Maybe WYSIWYH? Unlikely with midi! Anyway I've left it for now. (talk) 19:18, 17 March 2012 (UTC)

The real problem here is that "WYSIWYG" is typically used in a text enviroment. With notation there is one abstraction layer more, you can't save it as native chars, like text. And there are always little bits of non-printing material in any editor, be it notation or not. Only the most hardcore editors lack rulers, boxes, invisible commentes and other guides to help you edit. Just having boxes around items, like musescore has, should not disqualify as WYSIWYG editor. But there are other distinctions. The real categories should be instead: 1)Has a paper view with page-breaks 2)Has no paper-view but uses real notes and notation glyphs (aka. studio-view, track-view or DAW-view) 3)No notation glyphs but something different which must be converted, like utf8 or ascii text.

  • Musescore and Sibelius(traditional view) are category 1.
  • Denemo, the NoteWorthy Composers and other fall into category 2
  • Lilypond and ABC are 3

-- (talk) 21:25, 18 March 2012 (UTC)

WYSIWYG equals good? Please remove the colors![edit]

Why is "WYSIWYG" green and "not" is red? Is it superior to be WYSIWYG? I doubt it. Whoever created this huge table must have been thankful for working close with the data and not in some excel spreadsheet editor. TeX should than be inferior to MS Word etc. etc. I don't think the colors should be reversed but it should be neutral. Why not remove the coloring for WYSIWYG at all? There is not even an distinction between "GPL" and "Proprietary". It is just for the sake of information here. — Preceding unsigned comment added by (talk) 21:07, 18 March 2012 (UTC)

The colouring does not express a value statement; it is a function of the template {{Yes}}. -- Michael Bednarek (talk) 08:19, 19 March 2012 (UTC)
Red and green are not value free. They are culturally coded to mean "go" and "stop", or whatever you want. The price column colors are value free (if you are not into esoteric color meanings :) ) -- (talk) 16:12, 19 March 2012 (UTC)
Feel free to change the column "WYSIWYG Editor" from {{Yes}}/{{No}} to "Yes"/"No". Be aware that editing the wikicode for the table is a bit complicated and editing it is prone to mistakes – it's not a WYSIWYG editor. Other editors might disagree and revert your edits. -- Michael Bednarek (talk) 01:38, 20 March 2012 (UTC)

All except two of the listed programs are WYSIWYG or perhaps more pecisely in some cases, WYSIWYM. The remaining two, Lilypond and MusiXTeX, are not scorewriter programs as such, but programs for music engraving, and depend on another program to provide a front end as a GUI for their extensive capabilities in music typesetting. I don't doubt that Lilypond and MusiXTeX are superb at what they they are intended to do, but they depend on being provided with an input file in ly or TeX format respectively.

Thus they are in a different class to the other programs listed. It is therefore justified to indicate this clearly to anyone using this list to identify a program for their needs. If someone is seeking a WYSIWYG interface (which is what the column is headed), then red is an apt colour to warn them that they really aren't going to get going, and they will be stopped until they have installed another program that is WYSIWYG (if you wish unilaterally to attribute specific meanings to the colours according to your own particular cultural assumptions, then these colours are appropriate).

On the other hand, I don't see how you can infer the connection: green=good, red=bad; or any superior/inferior judgement from these colours.

This is not a judgement on the superiority or relative utility of WYSIWYG versus text-based interfaces. However I would say that this 'huge table' would be much easier to edit with an Excel-like WYSIWYG spreadsheet interface. Moving columns is extremely tedious and error-prone, whereas a good GUI would allow this to be done in seconds (and probably such things exist). WYSIWYG is not only used in a text environment, but also in many graphical and numerical applications, indeed including music notation. There are good reasons why its use has become widespread.

Whether this column could be used in a better way to indicate attributes of the different programs, perhaps such as the Categories 1, 2 and 3 suggested above, is a different question to consider. (talk) 11:56, 20 March 2012 (UTC)

This is not quite correct. You do not need a GUI to use either Lilypond or MusiXTeX, so the idea that the user is stopped until they install another program is simply wrong. The appropriateness of the colours then does become questionable. Also, given that, at least in Western cultures, the use of red very often implies some sort of warning or reason for caution, the objection above seems reasonable. (talk) 03:35, 6 April 2012 (UTC)
The connotations of color are more diverse than you suggest. (talk) 13:39, 16 March 2013 (UTC)

Finale import capabilities[edit]

Finale CANNOT import music from pdf and certainly not jpeg. I don't think it can import from anything other than xml and tiff. I have the software, I've looked through the help pages and I've read their page and I don't see a single claim that Finale is capable of importing music from all those types of formats. It can SAVE to pdf and I think that's about it. — Preceding unsigned comment added by (talk) 02:38, 21 September 2012 (UTC)

I think Finale includes SmartScore which has limied capabilities to scan scores. -- Michael Bednarek (talk) 09:31, 21 September 2012 (UTC)

I've been wondering about this myself. I think all those image formats (gif?) can be "imported" in the sense that, yes, you can add an image file into a score. The question is, should they be listed in that section for that reason? If the answer is yes, then they should be added for MuseScore as well, at least. ZackTheCardshark (talk) 19:53, 29 June 2015 (UTC)

latest release?[edit]

Shouldn't this column have the date of the latest release, so it will actually be useful? — Preceding unsigned comment added by (talk) 08:16, 7 October 2012 (UTC)

Basic sort sequence of the table?[edit]

My spontaneous impulse is to reorganize the table so that it is sorted alphabetically by the program's name. But it seems that the original authors of this table have established the basic sort by cost -- first the free programs, the rest sorted by price. But this sequence is already broken by having two editions of both Capella and MuseScore directly following each other, which breaks the sort by cost.

So, how shall we proceed? I had already reshuffeled most of the table by name, but cancelled that to give others a chance to voice their opinions.
--L.Willms (talk) 10:46, 27 January 2013 (UTC)

Theoretically, it should be possible to sort the table for any column, including "Name", so the original order doesn't really matter all that much. However, the sorting on the "Cost" column is poorly implemented and doesn't work. For some columns, the sorting capability doesn't make sense and should be removed (Developers, Import formats, Export format). -- Michael Bednarek (talk) 12:07, 27 January 2013 (UTC)
All you say is true. The list is really two lists: a list of free scorewriters followed contiguously by a list of paid-for scorewriters, each list in alphabetical order. I have just moved three entries to maintain this. An option would be to sort it into one continuous alphabetical list by name as suggested, though this can already be done by anyone with a single click on the header. Another option would be to split the list into two: one for free software, one for paid-for, though this seems to serve no helpful purpose until the list becomes too long and unwieldy. As many publishers offer both free and paid-for versions of their packages, it is helpful to compare options on a single list. In any case the list can be sorted into cost order with one click, albeit idiosyncratically, segregating the free packages. If we think people visit this list seeking a package with their principal initial criteria being that it is either free or paid-for, then the present order is helpful.
Is it possible to turn off the sort option on certain columns? If so, that could be done, though it isn't worth much effort as the senseless sort results are easy enough to ignore, and might even be slightly helpful to someone. (talk) 12:56, 16 March 2013 (UTC)

Guitar Tablature[edit]

It would be nice to show minimum and maximum strings supported in tablature either as an additional column or next to the indication of yes such as Yes 4-10 or Yes (4-9).

Kneelie (talk) 22:16, 21 September 2013 (UTC)

Need for a Real-Time Play Column[edit]

There is one feature that was simply inconceivable with traditional paper/pen/print -- viz a computer-scorewriter can play music. IOW a scorewriter can double up as a musician.

So while lilypond can export to midi, musescore (and I guess sibelius/finale etc) can play in the app itself the music entered so far, highlighting the notes as they are being played.

For a beginning music student this can be quite a deal to make musicianship more accessible.

Rpm13 (talk) 13:37, 17 March 2014 (UTC)

Edit Problems[edit]

I added Doric because it should be on the list, but I had some trouble with the visual editor. Also, couldn't pull up a lot of info I don't know firsthand. Apologies in advance 2620:0:E50:1037:9024:CD80:E3:8A60 (talk) 03:34, 16 February 2017 (UTC)

Need Column for Maximum Number of Staves Allowed[edit]

One of the most critical pieces of information a buyer needs in order to decide which application to use is the maximum number of staves allowed. It is a huge limitation in terms of the types of scores a program can be used for. Programs such as Impro-Visor only allow for lead sheet notation on a single staff while more robust applications such as Finale and Sibelius allow up to 64 or more staves and can be used for some serious orchestral work. There needs to be a column added for this to help users distinguish between the capabilities of these programs and which ones best suit a particular purpose.

S. Jenkins (talk) 21:02, 13 May 2017 (UTC)

Sounds all right to me. ZackTheCardshark (talk) 02:18, 14 May 2017 (UTC)
Finding this specification on each vendor's website shouldn't be too hard to reference. Although this specification is a nice-to-know piece of information relevant to all scorewriters, some manufacturers may list it on their website while others do not. However, the only problem I can see with adding the Maximum Number of Staves is the fact the table already has twelve columns, and if one more is added, the columns will be squeezed so tight and narrow because of the limited width of the entire table. I have seen other articles where that would have been a problem, but they broke up the table into two separate ones and that resolved it somehow. I am not saying we should do that here. S. Jenkins (talk) 21:25, 23 May 2017 (UTC)