[trunk] r4994, Score.load() and Score.save() fail

• Nov 17, 2011 - 11:27
S4 - Minor

In the plugin batch export the Score.save() operation fails, i.e. it returns false (currently not checked for in the plugin, but will be in the next version) and doesn't save the file. Same plugin in 1.1 works just fine.

Tested with trunk r4994 on WinXP SP3


In the command window created by the nightly.bat I see:

-tick2measure 0 not found

first 0x0

   no segment for tick 0

Text(Text): setSubtype: unknown type 
unknown audio file type 

Would we possibly need a new API, Score.export() for this, now that there also is a separate menu entry for this?

Title [trunk] r4994, Score.save() fails [trunk] r4994, Score.open() fails

Actually the Score.open() fails already (went unnoticed as not being checked for, will now). I guess the Score.save() failure is just a logical follow-up error

Edit: even stranger: the Score.open() succedes, I can see it being opened, but the function returns false anyway???

Title [trunk] r4994, Score.open() and Score.save() fail [trunk] r4994, Score.load() and Score.save() fail

save() is fixed. Thanks for the patch.
Note that bool save(string path, string type, string soundfontPath) is no more available. Use the one with 2 arguments instead.

Open is not yet fixed..

Oh, yes, it is Score.load(), not Score.open(), no idea what made me think otherwise...

But why can't that soundfontPath arg not be used anymore with Score.save()?
(Even if I connetly have no need for this)

Score.save() has been fixed in r5011, if I read the SVN repository correctly... (just so I know which nightly to test against)

Status (old) patch (code needs review) fixed

Score.load() seems to work since the batchexport plugin is working.

The soundfont method is no more provided by MuseScore core since you can now load more than one soundfont. The whole audio export with one soundfont needs to be coded again.

Well, Score.load() sort of worked: it loaded the Score. But it returned 'false' regardless (and the current batch export plugin doesn't test for this, so it goes unnoticed). Does it return 'true' now? Should we not be testing it in the first place?

Outch, that was a strange mistake. How long has it gone unnoticed, i.e. when had it been introduced?
Just to know how usefull it is to check success of Score.load()...
I think it worked fine in 1.1, does it still in 1.2?

And a furter question: is it possible, to determine (and display) why a load() or save() failed?

It was in the trunk so 2.x serie and not 1.X.
There is currently no way to display the error message from the plugin framework. Musescore core provides "readScoreError" but it's not exposed in the plugin framework.