Hi all,
FYI, assuming W3C MNX will replace MusicXML in the future and MuseScore will
need native support for MNX, I am looking into this and doing some
preliminary prototyping on MNX import.
I do realize MNX is still in early draft and many incompatible changes are
to be expected. Nevertheless, b
All,
to solve issue https://musescore.org/en/node/175226 [MusicXML import] add
instrument-sound to MIDI mapping, I intended to add a (new) mapping table to
deduce MIDI program number from MusicXML instrument-sound. This is required
to get correct instruments for MusicXML files without MIDI informa
Just tested the latest and greatest (commit aeb0d5b): all MusicXML regression
test are indeed OK, will close #141601.
I assume the actual fix is part of commit 63f5d73, which looks similar to my
intended changes.
Thanks, Leon.
--
View this message in context:
http://dev-list.musescore.org/Mus
Werner, Nicolas,
in the master, MusicXML clef export is broken. I suspect this may be caused
by the introduction of Segment::Type::HeaderClef in commit f7d9650.
Would you like me to investigate and fix ?
Regards, Leon.
--
View this message in context:
http://dev-list.musescore.org/MusicXML-c
Hi all,
just tested the current trunk and noticed the MusicXML regression test is
broken, mostly due to the barline related changes in the recent big layout
merge. I am wondering what would be the right time to start fixing these
issues. Is the trunk currently sufficiently stable (especially in th
A valid question. When I started I had no intention to re-invent the wheel,
but first spent considerable time investigating the existing solutions. I
could not find one that met my criteria: easy to understand and use, fast
and easily able to provide feedback while validating.
While building a pro
Yes, I wrote it myself from scratch. Currently about 4500 lines of code. It
understands just enough of the W3C XML schema language to correctly validate
MusicXML.
--
View this message in context:
http://dev-list.musescore.org/Replacing-Qt-XML-validator-by-custom-validator-tp7579577p7579579.html
In the past we have had several complaints about loading large MusicXML files
taking too long and not providing any any feedback. This is caused by the Qt
XML validator used: it is not very quick and it does not enable any
feedback.
To get a feel for possible improvements I have built a prototype
Indeed, my preference would be to switch over to the pull parser by default
a.s.a.p., to get broader test coverage. I have done all the testing I could
think of, now I need additional testers to find the corner cases I forgot.
Regards, Leon.
--
View this message in context:
http://dev-list.mus
Just checking, "bug fixes only in 2.0.x" seems to imply we will keep using
the MusicXML DOM parser in 2.0.x and switch to the pull parser in 2.1.
Correct ?
Note that I am not too happy about that, as it implies double work
(especially for me) on fixing MusicMXL import issues for quite some time. O
FYI, after installing freetype 2.5.5 using MacPorts, I could successfully
build MuseScore (OS X 10.7.5, Xcode 4.6.3). Opening a few sample files so
far showed no issues. Will keep you posted if I find anything unusual.
--
View this message in context:
http://dev-list.musescore.org/freetype-for-
A few remarks:
- the return is intended and correct: if ml is empty, the remainder of the
function cannot (and should not) be executed.
- the test is obviously a typo, thanks for catching that, it was meant to be
"if (!(ms.size() > 0))" (note extra pair of parentheses)
- due to a few lucky coincid
A kind reminder to @lasconic: please do not forget to cherry-pick this fix
and sync it to 2.0.1.
If this does not get included, 2.0.1 will crash on importing any MusicXML
file with a percussion part generated by Sibelius using direct export.
--
View this message in context:
http://dev-list.mus
Pull request #1956
--
View this message in context:
http://dev-list.musescore.org/How-to-import-file-with-missing-drum-set-tp7579160p7579188.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
--
My collection of MusicXML files generated by Sibelius is rather small, but it
would seem at least all Sibelius 7.x files with percussion parts suffer from
this and thus crash 2.0 when imported.
--
View this message in context:
http://dev-list.musescore.org/How-to-import-file-with-missing-drum-s
After thinking about this for about a week, I still cannot imagine any
structural solution for this issue. As it leads to the crash described in
issue 55501, I very would like to have it fixed (or at least worked around)
in 2.0.1. The reason it is difficult to fix is that the MusicXML file simply
d
This question concerns a pert of MuseScore that I am not familiar with. Issue
55436 contains two files where drum parts are present but no drum set
definition is available. Currently the MusicXML importer handles this
situation by setting the staff type to percussion but it does not create a
drum s
@lasconic,
if there is anything I need to do to get the pull parser merged, please let
me know what it is.
Any idea when you want to merge it ?
Regards, Leon.
--
View this message in context:
http://dev-list.musescore.org/Migrating-MusicXML-import-to-pull-parser-tp7579106p7579156.html
Sent f
Pull request 1911.
Regards, Leon.
--
View this message in context:
http://dev-list.musescore.org/Migrating-MusicXML-import-to-pull-parser-tp7579106p7579141.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
---
Will there be any change in way of working with pull requests post 2.0 ? I am
asking because 2.0 will be the first release based on the Github archive and
I have no idea how that will be handled.
For the MusicXML pull parser, can I simply submit a normal pull request
against the musescore/MuseScor
Quick status update:
I am making reasonable progress and think the main / most difficult parts
are done. The new pull parser now contains about 6400 lines of code compared
to the DOM parsers 7200 lines. About half the auto testers test cases pass
(46 out of 95).
Given the amount of work remaining
Will try to evaluate the pull request during the weekend.
Leon.
--
View this message in context:
http://dev-list.musescore.org/Migrating-MusicXML-import-to-pull-parser-tp7579106p7579115.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
-
For your information, I am currently working on migrating the MusicXML parser
from the current DOM parser to the (new) pull parser, which is also used for
reading MuseScores .mscx files.
As this is a significant effort (the MusicXML importer is about 8500 lines
of code), it is most efficient to do
Hi Jim,
I switched from Linux to Mac about two years ago. Currently using Xcode
4.6.3 on OS X 10.7.5.
Having skipped the "try something small with Xcode" step, I cannot help you
with that. I jumped straight into MuseScore, which I knew very well after
developing the MusicXML import/export code si
Upgraded to Qt 5.3.1 (on OS X 10.7.5). Works OK so far after a clean build.
Will report issues if I encounter any.
--
View this message in context:
http://dev-list.musescore.org/Qt-dependency-changed-from-5-1-to-5-2-without-announcement-tp7578916p7578927.html
Sent from the MuseScore Developer m
Due to the Aug 18 commit of mscore/scoreaccessibility.h, MuseScore does not
build anymore against Qt 5.1. Reason is that QAccessibleWidget is not
present in Qt 5.1 (and 5.0). It is present in 5.2.
Using Qt 5.1, the build now fails with a "'QAccessibleWidget' file not
found" error. If the Qt 5.2 de
The recent change from "enum AccidentalVal" to C++11 style "enum class
AccidentalVal : signed char" broke my self-built version (OS X 10.7.5, Xcode
4.6.3, Apple LLVM version 4.2). The reason is that enum class comparisons
(at least for AccidentalVal, possibly for more enum classes) do not work.
Thi
More work todo before 2.0 … :-(
--
View this message in context:
http://dev-list.musescore.org/ottava-tick2-weirdness-tp7578621p7578657.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
--
Subv
Just checked, ottava now behaves as expected, assume commit cff4e87b8f fixed
this. It also solves a number of MusicMXL import/export issue.
Thanks, Leon.
--
View this message in context:
http://dev-list.musescore.org/ottava-tick2-weirdness-tp7578621p7578652.html
Sent from the MuseScore Develop
In MuseScore 1.x, the tick2 value for an ottava was the end tick of the last
affected note. Some time ago in the trunk this was changed to the start tick
in of the last note. This leads to various forms of weird behavior. E.g.,
when replacing the last note in an octave by two smaller notes, only th
Probably a font handling issue in the bagpipe embellishment palette drawing
code. Will have a look at it.
Leon.
--
View this message in context:
http://dev-list.musescore.org/Re-Bagpipe-embellishment-menu-broken-due-to-SMuFL-integration-tp7578552p7578554.html
Sent from the MuseScore Developer
Thanks Werner,
if there is anything I can do to help, just let me know.
Leon.
--
View this message in context:
http://dev-list.musescore.org/Bagpipe-embellishment-menu-broken-due-to-SMuFL-integration-tp7578547p7578551.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.
As remarked in recent comments in issue #13108, the bagpipe embellishment
menu does not function anymore in the current trunk. According to Git, in
commit 733c1934 (2013-11-06 smufl integration, part I) this was explicitly
disabled by Werner.
Question to Werner (or to anyone else who can explain):
Thanks again, that did it. MuseScore now works on my Mac. Note that it still
does occasionally crash. Will debug and keep you posted. I intend to develop
using the Mac, which means I automatically find the bugs.
Regards, Leon.
--
View this message in context:
http://dev-list.musescore.org/Buil
Upgrading cmake (cmake-2.8.11-Darwin64-universal.pkg from www.cmake.org)
fixed the build.
Now it builds, but crashes immediately. Will try to debug ...
Thanks for your help, Leon.
--
View this message in context:
http://dev-list.musescore.org/Build-error-Mac-OS-X-include-file-not-found-tp7578
Yes, qmake is in the path. No, I did not run "make -f Makefile.osx clean"
(assuming it would not be necessary in a clean source tree).
A new build after running "make -f Makefile.osx clean" still fails on the
precompiled header generation, but with a slightly different error:
=== BUILD AGGREGATE
Building MuseScore (todays trunk) using "make -f Makefile.osx release" on Mac
OS X fails for me when building the precompiled all.h. Relevant part of the
output:
=== BUILD AGGREGATE TARGET mops2 OF PROJECT mscore WITH CONFIGURATION
Release ===
Check dependencies
PhaseScriptExecution "CMake Rules
Hi Mark,
"anyone who has worked on MusicXML & chord symbols" would probably be
lasconic, Werner and me. As far as I am concerned, if you need help, just
let me know. I you feel like modifying the MusicXML importer/exporter
yourself, I am willing to help or to review. If you'd like me to integrate
Hi Lasconic,
I am sorry, but as my time available for MuseScore tends to be very limited
during the summer, I seriously doubt it would be workable for me to provide
meaningful mentoring. Time allowing I am, of course, always willing to help
out wherever I can.
Regards, Leon.
--
View this messa
Hi all,
as I am looking at implementing issue #20581 ("To implement import of CapXML
files"), I have a few questions:
- who owns the Capella importer ?
- does anyone mind if I do some rework (in mscore/capella.*) ?
Regards, Leon.
--
View this message in context:
http://dev-list.musescore.org
Hi all,
it seems a consensus has emerged that Andrews design is the one we want, so
I will refrain from implementing my much simpler proposal.
Andrew,
could you perhaps own issue #20512 ?
As soon as Andrews implementation is merged into the trunk, I will add
MusicXML support (issue #20513).
Re
41 matches
Mail list logo
