App name (OS X), command line options, interface

• Jan 20, 2015 - 20:59

Amazing work on MuseScore 2. Super impressed.

Some questions:

When the app is released do you plan to make the app name (on OS X) "MuseScore 2.app" or just "MuseScore.app" -- I'd like to make music21 use it by default as an application for showing MusicXML but I'm trying to figure out what would be the better name to encode for longer term use.

From the command line, it would be good if no dialog windows popped up in case of a missing file or unparsable .xml file and the errors were printed to the command line. Right now it seg faults. I know that command line usage is not your highest priority, but WOW does musescore work amazingly as a Musicxml to PNG converter!

When closing MuseScore with unsaved changes the dialog window that appears does not respond to the standard Mac hotkeys of Cmd-D for don't save and Cmd-S for save. That'd be a helpful thing to add. Esc for cancel does work though.

Thanks all!
Myke

Comments

• Jan 21, 2015 - 02:39

I'm a huge fan of music21 and would love to do what I can to make sure MuseScore plays as nicely as it can with music21. I don't really know anything about the installation process, but regarding the dialogs - if you can provide some test files and specific command lines that produce dialogs or crashes now, I'll look into them.

Reply

• Jan 21, 2015 - 17:18

The easiest one to produce on Beta 2 Mac is just to run "./mscore -o ~/Desktop/o.png asdf" (assuming you don't have a file named "asdf") -- it'll produce:

Kassia-4:MacOS cuthbert$ ./mscore -o ~/Desktop/o.png asdf
2015-01-21 12:12:50.450 mscore[27843:8114439] ApplePersistence=YES
unknown file suffix <> name <asdf>
Cannot read file asdf:
unknown type
Segmentation fault: 11

and then the next time the program is run it'll raise a prompt that the program failed last time.

Incorrect XML also raises a dialog box (I was allowing css color names, such as "red" or hex color names with lowercase numbers "#ff0000" and this violates the XML spec), but that seems more acceptable, though it would be better to return the message to the command line.

We've replaced almost all of our prior auto-lilypond generated docs with MuseScore generated documentation, and it's incredibly impressive! See for instance Chapter 0. Thanks!

Best,
Myke

Reply

• Jan 21, 2015 - 17:54

OK, thanks. I thought maybe there was a specific MusicXML that was crashing MuseScore; we have (or more particularly, our resident MusicXML guy, Leon Vinken, has) been fixing those diligently. A crash because a file doesn't exist is something I am sure I can fix myself.

I believe we do generally try to avoid dialogs or other GUI-isms in "converter mode", so I'll make a pass thru and fix this.

Documentation looks good. BTW, are you using the built-in screenshot mode to generate the examples? Very useful for this sort of thing. See especially the option in right-click menu to auto-resize to page size.

Reply

• Jan 23, 2015 - 01:46

As of the current builds, command line use should be improved in the ways described - no dialog on invalid XML, no crash on non-existent file. In the case of invalid XML, we go ahead and try to import anyhow - the equivalent of your answering "yes" to the question about proceeding in the dialog. If need be, we could change this behavior or add another option to abort if a syntax error is seen. But so far in my experience, many of of the files I've seen that technically don't validate are still perfectly importable.

Reply

• Jan 23, 2015 - 05:39

Works like a charm! Assuming that all the new messages on the command line are debugging information that is enabled because it's a nightly.

You guys are amazing.

Last "nice-to-have" at least for now -- the non-gui version still loses focus from the terminal and opens up an application in the foreground which (in some invocation contexts such as from an IPython notebook) can lose the active focus. Is this an easy fix or one that would need a lot of patching.

So incredibly impressed with this user community! - Myke

Reply

• Jan 23, 2015 - 05:55

Yeah, it's a great community, much as music21's is :-)

If you were previously using one of the beta builds of MuseScore 2.0, then it would have been compiled without the debug flags. So yeah, if you see more output from a nightly build that must be why - I didn't change anything in that respect.

As for losing focus, can you be more specific? A series of steps I can follow to reproduce what you are seeing (preferably on Ubuntu?)

Reply

• Jan 23, 2015 - 19:24

I'm getting a lot of:

tick 1944/16 (233280) staff 1 voice '1' previnst[243/2]='' instrument '' insert 0

one line for each Note, I imagine.

There is also debugging information for things like:

credit-words defx=632 defy=1458 just=center hal= val=top words='Cacciando per gustar- Ai cenci, ai toppi'

but that appeared in the Musescore 2 version as well.

Here's the complete Musescore 2 output; the Nightly output is too long to include. I don't think that any of this information should be printed unless a -d or similar flag is triggered. But I'm so happy with the concept that I can't but be thrilled!

Kassia-4:MacOS cuthbert$ /Applications/MuseScore\ 2.app/Contents/MacOS/mscore -o ~/Desktop/cacciando.pdf ~/Desktop/cacciando.xml
2015-01-23 13:36:51.673 mscore[39500:11704796] ApplePersistence=YES
importMusicXml(0x7ffd72024e00, /Users/cuthbert/Desktop/cacciando.xml)
Validation time elapsed: 7764 ms
importMusicXml() file '/Users/cuthbert/Desktop/cacciando.xml' is a valid MusicXML file
MxmlReaderFirstPass::MxmlReaderFirstPass()
MxmlReaderFirstPass::parseFile() begin
part list
part 1 id 'P1'
part 2 id 'P2'
part 3 id 'P3'
part 4 id 'P49fdbe17065e27a4fe89ebef3f524d49'
Parsing time elapsed: 70 ms
MxmlReaderFirstPass::parseFile() end
system distance 12.100000
word font family '' size '' lyric font family '' size ''
MusicXml::xmlScorePart: instruments part P1
MusicXml::xmlScorePart: instrument id I4348b7e1f8ced4e5886c2c25fe1d5ce2 name Tenor 1
MusicXml::xmlScorePart: instruments part P2
MusicXml::xmlScorePart: instrument id Ic15f1470e93ac02c824e3951eaec6abc name Tenor 2
MusicXml::xmlScorePart: instruments part P3
MusicXml::xmlScorePart: instrument id I9d58777041f950b8a90450a4060de3ce name Tenor 3
MusicXml::xmlScorePart: instruments part P49fdbe17065e27a4fe89ebef3f524d49
MusicXml::doCredits()
page format set (inch) w=8.49891 h=10.9973 tm=0.626385 spatium=5.12497 DPMM=2.83465 DPI=72
page format set (tenths) w=1194 h=1545 tm=88 tov=1457
page format (xml, tenths) w=1194 h=1545
page format pw1=398 pw2=796 ph2=772
credit-words defx=632 defy=1458 just=center hal= val=top words='Cacciando per gustar- Ai cenci, ai toppi'
credit-words defx=1124 defy=1387 just=right hal= val=top words='Magister Zacherias (Chantor)'
header 2 footer 0 useHeader 1 useFooter 0
miny=1387 maxy=1458
vbox height 9.6 sp
creditMap 1458 credit-words defx=632 defy=1458 just=center hal= val=top words=Cacciando per gustar- Ai cenci, ai toppi
title='Cacciando per gustar- Ai cenci, ai toppi'
ImportXml: warning: break on first measure
ImportXml: warning: break on first measure
Parsing time elapsed: 291 ms
importMusicXml() return 0

The first line ( 2015-01-23 13:36:51.673 mscore[39500:11704796] ApplePersistence=YES ) is hard to remove since it's OS specific and generated by the OS, but I think that the rest except perhaps the ImportXml: warning are probably just a "if (debug)" flag away from removing.

As far as the Qt GUI App goes, I agree, but I believe that there's a way to have it run in the background w/o interface appearing (at least on Mac). I have Python code to do it somewhere, but not sure if my C++ skills are up to the task of making a patch.

Reply

• Jan 23, 2015 - 20:01

The console messages are all displayed via qDebug(), which I guess would normally go to stderr. Apparently we can suppress it by defining QT_NO_DEBUG_OUTPUT and perhaps that is planned for the final release or could be if it isn't. But you could also simply redirect stderr to /dev/null or whatever.

Anyhow, again, I didn't change anything about this, but I guess maybe some qDebug statements might have been added for other reasons of you are seeing a difference between the beta and a current nlghtly.

I'm still not understanding about the background / interface aspect of what you are talking about. When I run mscore from the command line on Ubuntu, I don't see any evidence of anything unusual going on - seems to run like any other purely command line program as far as I can tell. Again, can you post a specific sequence of steps I can test to reproduce whatever it is you are seeing? Or is it Mac-specific?

Reply

• Jan 23, 2015 - 22:16

I run MuseScore from a terminal window all the time. Like I said, I've never seen a problem. Which is why I still would like to see an exact sequence of steps to follow.

For example, if I open a terminal windows in Ubuntu, and then at the command prompt type:

/opt/MuseScore2/bin/mscore -o example.png -r 166 example.mscz

then after a few seconds, the output file example-1.png is created, the command prompt returns, and at no time do I see any evidence this is not an ordinary command line program. No window appears, nothing unusual of any kind happens. So I really have no idea what is being discussed here. I don't know if you are talking about *doing* something different from me or *seeing* something different from me.

EDIT: Ah, but indeed, if I unset DISPLAY, I get an error. Ive never had reason to try that before. I guess it is always set in the environments I have run from - terminal windows, shell scriptions, LibreOffice macros, etc. So is that what we are talking about specifically here? Running in an environment where DISPLAY is not set?

Reply

• Jan 23, 2015 - 22:22

'window' it the keyword here, so you are using a GUI, starting a terminal on that and musescore in that, right?
Try that in a plain text console, Ctrl-Alt-F1
Or make sure $DISPLAY is not set

Edit: yes, an env where $DISPLAY isn't set, mainly because there is no X-Server providing that...
A pure and plain server, possible even headless (i.e. no graphics board/monitor/keyboard) and a telnet/ssh session for example

The problem is that MuseScore wants to talk to $DISPLAY even in plain command line mode and regardless that it doesn't actually need that display to..., hmm, display, something.
As far as I understood this is a side effect of being a Qt application and as such pretty much unavoidable.

Reply

• Jan 23, 2015 - 22:39

Ctrl+Alt+F1 is a new one on me. I don't know what that does, I guess it's a Mac-ism? It does something on my Linux machine too, but I am guessing that's because it's really a Chromebook and not running native Ubuntu.

Anyhow, I wasn't thinking about this type of environment, and yes, what you say about it makes sense.

Reply

Do you still have an unanswered question? Please log in first to post your question.