Re: [Mscore-developer] Master crashes when opening most dialogue boxes

[Maurizio M. Gavioli]

Jojo-Schmitz wrote
> Works just fine on Windows. Only that load/create mp3 dialog needs to be
> dismissed

Do you mean that you (and possibly other as well) can open an existing score
via the "File | Open..." menu command? That it may be a Linux specific issue
or perhaps specific to my system?

Last time I tried (three weeks ago) it was working, with much the same
system and set up as now.



--
View this message in context: 
http://dev-list.musescore.org/Master-crashes-when-opening-most-dialogue-boxes-tp7580224p7580226.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Master crashes when opening most dialogue boxes

[Maurizio M. Gavioli]

*Context*: self-compiled today master under Linux Mint 17.3, Qt 5.8, Qt
Creator 4.2.1

*Description*: the programme crashes with a segmentation fault when the
"exec()" method is called for many of the dialogue boxes. For instance:

*Steps*:
1) Start MuseScore
2) Select menu item "File | Open..."

*result*: segmentation fault in /mscore/file.cpp/, line 852 (method
/QStringList MuseScore::getOpenScoreNames(const QString& filter, const
QString& title)/).

*Note*: the only dialogue box I was able to open so far is the Preferences
dialogue. This happens when running from within Qt Creator and from a
command line. In any case no error message is provided beyond "Segmentation
fault".

Is this expected as for instance a consequence of some unfinished
development stage?



--
View this message in context: 
http://dev-list.musescore.org/Master-crashes-when-opening-most-dialogue-boxes-tp7580224.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Qt and OpenType

[Maurizio M. Gavioli]

Two years have passed and things do not seem to be very different. Qt code
base now does include HarfBuzz (since a few versions), but it is unclear to
me if it uses it at all and if it gives an application any (more or less)
direct access to it.

I could do a scan of recent forum topics / issues and get an idea of the
current MS status about text shaping / laying out / rendering, but if anyone
has a summary, I would appreciate.

In particular, to see if it would make any sense to add HarfBuzz to 'our'
font stack below FreeType, giving MS access to some of its features, and
steer away from Qt text processing completely, which in my opinion might be
the most logical option in the mid term (and the road to version 3 is mid
term at least).



--
View this message in context: 
http://dev-list.musescore.org/Qt-and-OpenType-tp7579162p7580222.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Error while compiling

[Maurizio M. Gavioli]

Oh well, MY FAULT! 

Cleaning more accurately before switching between versions of the MuseScore
sources DOES WORK! 

(After almost a year of working only in Java, it is surprising how one
looses familiarity with details and how much hodgy-podgy C++ dev would
seem...)


Incidentally about cleaning, I followed the Qt Creator Method 2 described 
here in the developer handbook

  
and the "make uninstalldebug" clean step results in the following error(s):

Starting: "/usr/bin/make" uninstalldebug
cd build.debug \
&& xargs rm < install_manifest.txt \
&& if [ "TRUE" = "TRUE" ]; then \
 update-mime-database ""/usr/local"/share/mime"; \
 gtk-update-icon-cache -f -t ""/usr/local"/share/icons/hicolor"; \
   fi \
&& xargs ../build/rm-empty-dirs < install_manifest.txt \
&& rm install_manifest.txt
Directory '/usr/local/share/mime/packages' does not exist!
gtk-update-icon-cache: Failed to open file
/usr/local/share/icons/hicolor/.icon-theme.cache : No such file or directory
make: *** [uninstalldebug] Error 1

I resorted to disabling this clean step and using "make clean" only.


Lastly, which is the make argument to turn off PulseAudio support?

Simply using "BUILD_PULSEAUDIO=OFF" does not go through. I tried
"-DBUILD_PULSEAUDIO=OFF" and, of course, it raises an error ("/usr/bin/make:
invalid option -- 'D'").

Short of editing CMakeLists.txt, which would be detected by git, I am
resorting to manually modifying the build-debug/CMakeCache.txt file created
after the first compilation attempt fails (and, no, no way I turn back on
that PulseAudio evil on my machine...).




--
View this message in context: 
http://dev-list.musescore.org/Error-while-compiling-tp7579819p7580154.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Error while compiling

[Maurizio M. Gavioli]

Thanks for the reply, lasconic.


lasconic wrote
> Maybe you have another Qt installed by your system?

Sure I have: the Mint 17.3 distro comes with Qt 5.3. However it should not
matter, as Qt 5.4 and 5.8 are installed in my home and, for instance, while
using Qt 5.8, it finds everything it needs from its own code base.

Dealing with master AND 2.1 practically requires to have three Qt versions:
the one which ships with the distro, 5.4 for 2.1 and 5.6+ for master. What
am I supposed to do? Keeping the sources of master on one PC and the sources
of 2.1 on another?

Anyway, where this damn QWindowSystemInterface is supposed to be found? It
is not described anywhere in the Qt docs...

> See https://forums.gentoo.org/viewtopic-p-7864110.html

I did find this post, but it seems related with Gentoo specifics; it
basically says: "Don't mix Qt versions", and we already know we shouldn't,
but in some cases we are forced to do it anyway.

I'll try with some more spells and runes...



--
View this message in context: 
http://dev-list.musescore.org/Error-while-compiling-tp7579819p7580152.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Support for numbered notation (Jianpu)

[Maurizio M. Gavioli]

byan61 wrote
> I made some changes for adding a linked Jianpu staff to a standard staff
> and converting the note pitch/tpc values to Jianpu note numbers. See the
> picture below.
> I am currently using layout of the standard staff.  I still need to to put
> all the Jianpu note numbers on the same level and add dashes underneath
> the numbers for eighth notes, sixteenth notes, etc.
> How does the the staff/note layout and drawing work in general?  Any
> pointers for further study?

If my experience as the author of most of the TAB implementation can be
useful, most elements (like note heads, stems, beams, etc) have a *layout()*
method, as lasconic said, and a *draw()* method.

I have added special treatment for the TAB case in many of them and you can
have a look at them for inspiration. For instance (but quoting from memory),
if in in a TAB staff, the *Note::layout()* method positions the note head
depending on the TAB string rather than on the note pitch; the
*Accidental::draw()* method totally skips the element (TAB have no
accidentals) and so on.

I would suggest NOT to modify values related to standard staves (like pitch
and tpc), but to use them for as a base for your own calculations, as they
will be needed if the staff is converted back to standard notation.

I would also suggest to focus initially only on implementing a 'native'
(i.e. autonomous, non-linked) /jianpu/ staff and to deal with staff linking
only once it has reached an advanced enough state (and you decide what
"advanced enough" may mean).

Good luck!

M.



--
View this message in context: 
http://dev-list.musescore.org/Support-for-numbered-notation-Jianpu-tp7580026p7580041.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Playback abstraction layer

[Maurizio M. Gavioli]

ChurchOrganist wrote
> 
> lasconic wrote
>> In any case, it should already be possible to create instruments.xml file
>> to send CC messages at any point of the score to an external or internal
>> synth, even in MuseScore 2.0.3. Anyone tried it already?
> Yes - that was how registrations changes worked in the old Aeolus version
> of Pipe Organ.
> 
> Sending single MIDI messages is no problem - but currently we can't send a
> string of messages during the duration of a note because the note is a
> single event, and as far as I can see there is no way to time them,
> although I suppose you could use invisible, silent notes in another voice
> - but then surely that would affect score layout?

Sorry to pollute the thread, but to me it is far from evident how to
replicate the old registration change feature with current 2.0.3
implementation + Jack (my use case is MuseScore + Jack + GrandOrgue). Could
you elaborate  a little bit on this?

Thanks, M.



--
View this message in context: 
http://dev-list.musescore.org/Playback-abstraction-layer-tp7579762p7579815.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Tablature question - how to determine if in a 5 staff line banjo tab or not

[Maurizio M. Gavioli]

FWIW, as the one who coded most of the tab feature, I second lasconic in his
opposition to anything tied to a specific instrument; for instance, the
piano Ped. feature is there, but it is not specifically tied to a staff
being a piano staff, for it being used or usable (the user is ultimately
responsible for using each feature when it musically makes sense!).

I am not very familiar with modern plucked string usages (my background is
more on Renaissance and early Baroque instruments), but I am not immediately
convinced that the capo concept applies to this case, even a "capo
independent for each string" concept.

If I am not mistaken, capo ultimately works in the other direction: with a
capo on the, say, 3rd fret, the fourth fret would be numbered 1.

I suspect that having an additional parameter for each string, holding a
numerical offset to the resulting fret value, might be one way to go, but I
have not given *a lot* of thinking to this. This would affect how a computed
fret value is turned into a textual representation.

I also suspect that:

1) this feature should be incompatible (non-available or automatically set
to 0) with the "open" flag

2) it should be separate from a (future) capo feature, but interact with it,
as the latter may override the former. Examples: As far as I understand the
5-string banjo case, normally there is a delta of +5 between the first
string and the other; assuming a capo on the 1st, 2nd, or 3rd fret, this
delta would be reduced to +4, +3, +2 and so on. But from the 5th fret on
(capo on the 5th, 6th, ..., fret), the progression does not continue and the
delta remains fixed at 0.
___

Another, different, view could be to introduce the concept of "minimum
available fret"; in this view, the first string of the 5-string banjo would
be tuned on 4th lower than 'G' (at least internally, the value actually
displayed to the user in the string table might be adjusted) and frets from
0 to 4 simply non-existent, not usable. This would affect which note can
actually be assigned to which string (and, in fact, in this banjo case, it
is not possible to place, say, an F# at the 4th fret of the first string:
that fret does not exist!).
___

The points IMHO most important to keep in mind while designing this feature
(and to choose between these two views above or any other one might think
of) are the usual: performance and code maintainability.

*Performance*: the validity of the cached fret value and its textual
representation are computed each time a layout takes place (as a rule of
thumb, each time something changes somewhere in the score); the fret value
itself is re-computed less frequently, only if the cached value, once
checked, turns out to be no longer valid. But please note: if the note
belongs to a chord, the invalidity of a single note triggers the recomputing
of all the fret values of the chord.

So, all these routines should be as streamlined as possible, with a little
preference for the two former steps (validity check and string).

*Maintainability*: this has to do with proper commenting, meaningful symbols
names and so on, as usual. But also with keeping as much as possible with
coding patterns and paradigms already used in the rest of the code base (the
whole of it, not only the tab feature), to reduce the numbers of "minds" and
habits required to understand the code.

Thanks,

M.



--
View this message in context: 
http://dev-list.musescore.org/Tablature-question-how-to-determine-if-in-a-5-staff-line-banjo-tab-or-not-tp7579658p7579690.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Articulations and Ornaments: better to separate them?

[Maurizio M. Gavioli]

Jim Newton wrote
> It seems to me that the only thing ornaments and articulations have in
> common is the manner which they get rendered in print.  Although, it get
> the impression when dealing with the code, that they should both be
> represented as two subclasses of some common class.

This is my impression too! I was trying to get some comments from the devs
about possible alternatives and best practices...



--
View this message in context: 
http://dev-list.musescore.org/Articulations-and-Ornaments-better-to-separate-them-tp7579521p7579533.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Some thoughts on linked staves

[Maurizio M. Gavioli]

It occurred to me that some of the complexities we are regularly facing with
linked staves may stem from the fact that the current concept of staff
linking gathers together two rather different types of links:

1) The *score part = separate part* link: the basic idea here is
that the two staves are the same representation of the same music and then
the separate part is a rather exact copy of the part as it appears in the
score and the majority of the details should be linked, with the possible
exception of the 'outermost' features having to do, for instance, with page
layout (scaling, line breaks, and so on).

2) The link between *two different staves in the same score*: the basic idea
here is that the two staves are two different representations of the same
music and then, in principle, the majority of the details -- above the
'innermost' ones, like note pitches -- should *not* (could not? might not?)
be linked. By far the most common case of this kind of link is the link
between staves of different types, and it is not possible to take for
granted that any or most aspects of one representation can be transferred to
the other.

An example occurred to me, while working on  this PR
  , having to do with
beaming in historic tablatures. Beam mode is currently a linked feature and
in case 1) above (score part & separate part) this makes perfect sense; but
in case 2) above (two different staves linked together) it does not (or not
necessarily): beaming practices might be different in the two
representations (in fact they *are* different) and the beaming setting for
one might be inappropriate for the other.

I have no ready-made answer or solution, not even a clear idea of all the
sides of the matters involved and I assume the border lines defining the
'innermost' or 'outermost' features evoked above will anyway be a matter of
compromise. But I suspect this concept of staff linking deserves some more
thought and/or re-evaluation.

Thanks,

Maurizio

Note: the idea floating around since a while of allowing linking / unlinking
of individual elements would affect this point only marginally. To expand on
the example given above about beaming, unlinking the beam mode of a single
chord (assuming this would ever be possible) would not be particularly
useful, as the point is that, by default, beaming mode should be linked for
all chords in case 1) but unlinked for all chords in case 2).



--
View this message in context: 
http://dev-list.musescore.org/Some-thoughts-on-linked-staves-tp7579522.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] note not yet ready

[Maurizio M. Gavioli]

Jim Newton wrote
 I'm working on a function which extends (adds notes to) some chords
 according to a particular algorithm.
 I'm using the function chord-score()-addNote() to insert the notes.
 Unfortunately, this function creates notes whose note-line() is 0.  I
 guess this gets rectified later.
 
 This poses a problem, because as the function proceeds, it cannot
 determine which notes are really on line=0, and which just have line=0
 because they have not been finalized yet.
 
 Does anyone know how to either force the line calculation to occur and
 note-_line to get set, OR how to determine if a given note has not yet
 been finalized?
 
 Thanks.

It would help to know why do you need the line value of a note: are you
trying to improve the graphical placement of other elements with respect to
the graphical placement of the note? For things like this knowing the line
would / could help. These are tasks which are typically done during the
layout phase(s) though.

For other tasks, like determining the pitch or the 'spelling' of a note, the
line is irrelevant; the note pitch and/or tpc's should be used instead.



--
View this message in context: 
http://dev-list.musescore.org/note-not-yet-ready-tp7579475p7579492.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Q_ASSERT(false) in else branch gives compiler warning

[Maurizio M. Gavioli]

heuchi wrote
 after Werner's change to fix compilation with Qt5.5 I'm getting warnings
 like this:
 
 /home/joern/MuseScoreQt55/libmscore/element.cpp: In member function
 ‘virtual QPointF Ms::Element::pagePos() const’:
 /home/joern/MuseScoreQt55/libmscore/element.cpp:520:34: warning: suggest
 braces around empty body in an ‘else’ statement [-Wempty-body]
Q_ASSERT(false);
   ^

I assume you get this warning while compiling in release mode; Q_ASSERT()
does something only in debug mode, in release, it is results in no code
(whence the warning for the 'empty' else). I would assume this was the
intended behaviour, when the original abort() has been replaced with
Q_ASSERT().

Whether it is the right thing to do in this specific case, I cannot say.

M.



--
View this message in context: 
http://dev-list.musescore.org/Q-ASSERT-false-in-else-branch-gives-compiler-warning-tp7579451p7579452.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] More thoughts on Figured Bass realisation

[Maurizio M. Gavioli]

During the discussion on the recent PR for Figured Bass realisation, by going
by bits and pieces, things became unncessarily complex and the global
picture harder to get.
My impression is that, once we start from the basic 'rule': sharp = major
| flat = minor, there is a quite simpler way to proceed, as I think that
there is only one piece of info needed from the context of the F.b. chord,
i.e. the current key signature; everything else can be rather easily
computed from the F.b. data themselves with a handful of code lines and a
few table lookups.
Each interval can be diminished, minor, neutral-or-just, major, augmented;
with 7 intervals from unison to 7th, there are 35 possibilities for the
pitch offset and the TPC offset of each interval type:
Pitch offset
dimin.   minorn.o.jmajoraugm.Unison-1  --   
0--   +1Second 0  +1?+2   +3Third
+2  +3?+4   +5Fourth+4  --5   
--   +6
and so on. Same for TPC offsets:
Unison-7  --0--   +7Second   -12  -5   
?+2   +9Third-10  -3?+4  +13Fourth   
-8  --   -1--   +6
and so on. Some combinations do not exist (the '--': unison, 4th anf 5th
cannot be minor or major) and can be filled with arbitrary values as they
will never be used. Some cells (the '?': neutral 2nd, 3rd, 6th and 7th)
cannot be computed without knowing the current key signature: more about
them later.
From the F.b. figures, the interval number is easy; for the interval type,
let's start from the basics: for 2b/Ø/#, 3b/Ø/#, 6b/Ø/, 7b/Ø/#:
b = minor
Ø = neutral
# = major
For 4b/Ø/# and 5b/Ø/#:
b = diminished
Ø = just
# = augmented
Once we know the interval to compute, for all combinations except the '?',
the derived note can be computed quite easily:
Note* derivedNote = new Note(score);int derivedNotePitchOffset  =
pitchOffsetTable[intervalNumber][intervalType];int  derivedNoteTPCOffset
=
tpcOffsetTable[intervalNumber][intervalType];derivedNote-setPitch(bassNote-pitch()
+ derivedNotePitchOffset,   bassNote-tpc1() + 
derivedNoteTPCOffset,
bassNote-tpc2() + derivedNoteTPCOffset);
If the TPC lookup returned '?' (the Tpc::TPC_INVALID enum value can be used
for it), we have to position the bass note in the current key signature
scale and retrieve the derived note as specified by the same scale. Note
that any degree, 'native' or altered, of a scale has a known relationship in
pitch and in TPC with the tonic:
PitchTPC   DegreeDegree 1 b-1 -7  0Degree 1  
0  0  0  *Degree 1 #+1 +7  0Degree 2 b+1 -5 
1Degree 2  +2 +2  1  *Degree 2 #+3 +9  1Degree 3 b   
+3 -3  2Degree 3  +4 +4  2  *Degree 3 #+5+13 
2
and so on (ignore the '*' for the moment). This table is shown above sorted
by degree order, but it is actually accessed by TPC, so it is better to sort
it by increasing TPC value.
Another table is handy to have, which is derived from the above table by
keeping only the lines marked with an * (the 'native' scale degrees), sorted
by degree.
The current key sig. for the bass staff can be obtained and converted into
the TPC of its tonic and the bass note TPC can be converted into a scale
degree with:
Chord bassChord = bassNote-chord();Key key =
bassChord-staff()-key(bassChord-tick());int tonicTPC = key + 
(Tpc::TPC_C
- Key::C);int bassNoteTPCOffset = bassNote-tpc1() - tonicTPC;int
bassNotePitchOffset = scaleTable[bassNoteTPCOffset][PITCH];int
bassNoteDegree  = scaleTable[bassNoteTPCOffset][DEGREE];// locate the derived
scale degreeint derivedNoteDegree   = bassNoteDegree + intervalnumber;//
locate the derived note pitch and TPC position relative to the scale
tonicint derivedNotePitchOffset = degreeTable[derivedNoteDegree][PITCH];int
derivedNoteTPCOffset= degreeTable[derivedNoteDegree][TPC];// ready to fill
the derived note valuesderivedNote-setPitch(   bassNote-pitch() -
bassNotePitchOffset + derivedNotePitchOffset,   bassNote-tpc1()  -
bassNoteTPCOffset   + derivedNoteTPCOffset, bassNote-tpc2()  -
bassNoteTPCOffset   + derivedNoteTPCOffset);
Finally, the derived note can be added to its destination chord with:
derivedNote-setParent(derivedNoteChord);score-undoAddElement(derivedNote);
An attempt of a function returning a derived note from a bass note, an
interval number and an interval type could be:
Note * createDerivedNote(Note* bassNote, int intervalnumber, int
intervaltype){  Note* derivedNote = new Note(score);int
derivedNotePitchOffset  = pitchOffsetTable[intervalNumber][intervalType];   
int
derivedNoteTPCOffset= tpcOffsetTable[intervalNumber][intervalType]; if
(derivedNoteTPCOffset != Tpc::TPC_INVALID) {
derivedNote-setPitch(bassNote-pitch() + 

Re: [Mscore-developer] Preparing MuseScore 2.0.2

[Maurizio M. Gavioli]

lasconic wrote
 Yes, the update notifier works well on Windows and Mac. I test it for
 every release.
 It's completely disabled on Linux and BSDs since it's the role of the
 package management system on each platform.

Oh, I see, this explains everything. Thanks.



--
View this message in context: 
http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579392.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] programmatic access of figured bass

[Maurizio M. Gavioli]

Jim Newton wrote
 Is there a way to store tasto solo in the figured base data structure,
 and a way for the user to enter it.  Consequently, there would be a way to
 programmatically detect the difference between missing FB and tasto solo.

As I said, the standard situation is to have no figured bass figures during
tasto solo passages, so there is no FiguredBass data structure to store
that info into. If this info is needed, something else is required.



--
View this message in context: 
http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579391.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Preparing MuseScore 2.0.2

[Maurizio M. Gavioli]

First of all, I have no suggestions on the maintenance points.

About the main topic, FWIW I also believe that bug fixes are always welcome!
With a few notices:

1) Users do not always care (or even know) about product versions (many do
not even care about which OS they use...). I assume that 'power users' or
/aficionados/ who look every week for a new release are the minority.
Multiplying the releases increases user support (obsolete bug reports, ...).

In the past, there has been too much delay between releases; but even too
short delays have consequences.

2) I would value backward *and forward* file format compatibility across all
2.0.x releases (I would value it even across all 2.x.x releases, but this
probably asking too much).

I now have a largish corpus of scores to maintain and I am still in the
process of upgrading all of them to 2.0 (which is currently taking most of
my free time). From my experience, I assume that everybody else who
routinely uses MS to circulate scores among a community (of students, of
choir singers, or whatever) would see his life made more complex by a
multitude of not 100% compatible releases, rather than simpler.

3) Jim's work on ornaments is to be praised. If possible, I would really
appreciate to see some things about Baroque ornaments 'optimized' before
releasing it to the general public. There are discussions going on on that.

Thanks,

M.



--
View this message in context: 
http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579380.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] programmatic access of figured bass

[Maurizio M. Gavioli]

Jim Newton wrote
 So I experimented with playback and it indeed sounds horrible.
 What I want to do now, is something like the Explode command.
 This I'll have musescore translate the encoded Figured Bass into notes on
 a staff which the user can then manipulate manually.

Does not sound simple... But I got the impression that you were after a
real-time Continuo realisation, which would be much more complex (and would
not allow any after-thought corrections).

 With regard to your question of how to interpret ambiguous notation.  Yes
 of course you are correct.
 I suspect the final solution will have a GUI to allow the user to control
 the meanings of certain ambiguous items.
 
 The first ambiguity I encountered is that sometimes lack of a FB under a
 note means don't play a chord, but sometimes it means play the obvious
 chord.

Ah! You got to the bottom line! The main problem is that obvious: what is
obvious for us now is not necessarily what for obvious for, say,
Telemann, which in turn was different from what was obvious for
Monteverdi. There is no shortcut out if this conundrum, I believe, except
study, study and study under the guide of a good teacher, accompanied by
practice, practice and practice...

And, beside, there is always a chord, unless *you* as the performer choose
not to have one; the written indication when the author does not want chords
is tasto solo (roughly meaning: play just one key, understood: the note
actually appearing in the bass part).

 I was thinking of using a rule of thumb:  No notation under the tonic,
 dominant, or subdominant means play the obvious chord, otherwise it
 means no chord.

See above...

EDIT: the penny dropped! By no chord you mean no *new* chord (i.e. hold
the previous one). This more or less amounts to detect which bass notes are
passing notes (if I got the right English term) and which are not. Another
point which was obvious to them and might not be to us.

As I play a bass instrument, I would like to become a continuist (life span
permitting...), but I cannot pretend to be a decent one now. The advice of a
real Continuo player is required, to arrive at guide lines which could
guess the right notes more often than not. 

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579379.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Preparing MuseScore 2.0.2

[Maurizio M. Gavioli]

lasconic wrote
 1- I agree that too short delays have consequences. However MuseScore has
 an update checker and it will nag users every week or so to upgrade to a
 more recent version. Also, I prefer having more user support to do with a
 simple answer (Please upgrade) than not having a good answer (Please wait
 for next version, release date: when it's ready).

Ok. (Incidentally, are we sure about the update notifier? I daily use 2.0
and have not been notified of 2.0.1 (yet?) ).

 2- Backward and forward format compatibility needs to be defined... [...]
 As an example, files created in 2.0.1 can be open in 2.0, and files made
 in 2.0.2 should open in 2.0.1 and 2.0.

Good!

 If we have glissando playback in 2.0.2, there is no chance 2.0 or 2.0.1
 will play them... (are we still forward compatible then? I think so.)

I think so too. For me, forward compatibility means that scores created with
a later release can be open with an earlier one, without crash and with the
common elements having the same meaning. Of course, elements not existing in
the earlier release cannot be expected to be understood and rendered by it.

 Or another example, we used to create courtesy clef before a section break
 (bug #7886), if this is fixed in 2.0.2, a score created in 2.0.1 will look
 different in 2.0.2... and a score created in 2.0.2 will look different in
 2.0.1. (are we still backward/forward compatible then? I think so.)

IIUC, a 2.0.2 score would look better in 2.0.1 than an original 2.0.1 one:
great! And yes, this is forward compatibility for me too.

 3- Discussions are good but as you highlighted several times, there is no
 optimal solution for this problem.

Yet, non-100%-optimal solutions may range from 99%-optimal to 1%-optimal;
somewhere in between there is a threshold (there is a subjective element in
this, but it can usually be averaged).

 As we only store the ornament style and not the rendition, we can always
 make the style sounds better or add more style.

Indeed. But, once something is there and turns out below the aforementioned
threshold, we cannot any longer withdraw it, we are committed to bring it
above.

 In any case, we need an option to have no rendition at all, globally,
 since there will always be purists that would prefer to have nothing
 instead of something not perfect.

Yes! ;-)

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Preparing-MuseScore-2-0-2-tp7579373p7579388.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] programmatic access of figured bass

[Maurizio M. Gavioli]

Jim Newton wrote
 BTW does the Figured Bass notation in musescore support the tasto solo
 keyword?

In which sense? By definition tasto solo passages have no figures, so
there would be nothing to store the flag into.



--
View this message in context: 
http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579387.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] programmatic access of figured bass

[Maurizio M. Gavioli]

Maurizio M. Gavioli wrote
 [...] But the under-notated (for our 'modern' feelings) B.c. in most of
 the XVIII c. music is hard to realize automatically [...]

Of course, it is a typo; I was meaning the XVII c.!

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579370.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] programmatic access of figured bass

[Maurizio M. Gavioli]

Jim Newton wrote
 Thanks.  I have not talked to Miwarre before.

You did, you did... It's me...

 Your suggestion to create a public accessor for items is more or less what
 I am doing in the mean time.

I would not encourage creating public accessors to FiguredBassItem's, unless
really necessary for other purposes, as they require specific management and
house-keeping by the parent FiguredBass element. Their privateness is a
design choice, as described in the notes on architecture at the top of
figuredbass.h.

A few considerations for script access:

*) In the FiguredBass class, the std::vectorFiguredBassItem* storing the
items needs probably to be replace with some kind fo
QQmlListPropertyMs::FiguredBassItem* container, *if* individual access to
each FiguredBassItem is required, which I would prefer to keep as read-only,
though.

*) The full content of the figured bass element is already directly
accessible through its /text/ property in a normalized format. Before
allowing to set it however, I think that the /Text::setProperty(P_ID::TEXT,
v)/ has to be sub-classed, following the flow in /FiguredBass::endEdit()/.

I don't know if you have any deadline; I'm rather busy for a week or so;
after that, I would be glad to improve figured bass support for scripting.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/programmatic-access-of-figured-bass-tp7579343p7579348.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Qt and OpenType

[Maurizio M. Gavioli]

lasconic wrote
 According to https://bugreports.qt.io/browse/QTBUG-18980 Harfbuzz-NG is
 the default *shaper* now in Qt 5.4.

Glad to know! This seems a step in the right direction.

 My understanding is that the font *layouting  rendering* is still
 different per platform[...]

Thanks for the summary of the current situation.

 Maintaining our own Qt fork would be costly...

Indeed!

 1/ MuseScore 2.0 suffers from the difference of font rendering on
 different
 platforms[...]

Of course, this is just my opinion but, having to choose between consistency
across platforms and native-look-ness on each platform, I would prefer the
former. Incidentally, the screen shot you give about using Freetype under
Windows does not look particularly alien to me or strikingly different from
the default; I agree I may not be a very neutral observer, though.

However, it is not clear if we *do have* any choice at all. The kerning
issue on Mac you quote ( https://musescore.org/en/node/33481
https://musescore.org/en/node/33481  ) is typical: as Apple and Microsoft
disagree in their vision of some OpenType details, their respective
implementations are different and relying on system routines is likely to
produce different results.

 I don't think we understand yet the root causes of these issues.

I suspect very few peoples do understand them; developers or teams with
substantial experience in dealing with text processing across multiple
platforms may have developed empirical strategies to circumvent them,
though.

 2/ MuseScore 2.0 doesn't (and cannot) use OT features.[...]

The current point with Qt, even with 5.4, is that it may *use* OT features,
but *does not expose* them (at least I could not find any place where it
does). This means that supported features are activated by default and
unsupported ones are deactivated, but there seems to be no way to turn
on/off individual features in specific spots. This is (possibly) convenient
for features which apply unconditionally, but it is not for features the
user may want to activate locally.

For instance, if a font includes the kern or the liga features (which
are supported by Qt since several versions), kerning and/or ligatures will
be activated by default, but there seems to be no way to turn them on/off on
demand. So, it would not be possible to activate a feature like ss01
(stylistic set 1, which is anyway currently not supported by Qt) on specific
glyph runs.

Assuming a way is found (or will be provided by Qt in the future) to solve
this, I would distinguish between two major areas of application:

A) Musical glyphs: for the most part, they are drawn individually, then most
of the GPOS and many of the GSUB features are useless for them; using
stylistic sets or stylistic alternates, however, could be a way to give the
user access to (part of) the variety of shapes and styles possible within
SMuFL.

B) Textual glyphs: text runs may benefit from theoretically all the features
(as they have been developed specifically for text! Some apply to only some
scripts, though); it would then be a matter of deciding how far to go from
within MS, optimizing the flexibility and the typographic appropriateness
with the usability. I personally would love to see the day when MS will
allow to use 'real' small caps and lower-case numerals.

M.



--
View this message in context: 
http://dev-list.musescore.org/Qt-and-OpenType-tp7579162p7579172.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Plugin documentation - generated manual

[Maurizio M. Gavioli]

A) Properties

Currently the plug-in documentation generated from comments in the source
code uses a C/Qt notation in properties:

*) MuseScore objects are prefixed with Ms:: (like Ms::Measure)

*) String returned values are labelled as QString

*) Returned pointers are notated as C pointers (Ms::Element*)

*) Enum types are notated with C syntax (Ms::Element::Placement) and their
values -- if at all given -- are unqualified (ABOVE, BELOW)

This might be misleading for the user working in the JavaScript plug-in
environment, where strings are simply called string, MS objects are named
with their unqualified type (Measure and not Ms::Measure or
Ms.Measure), pointers are not indicated at all and enums use a different
syntax.

What about cleaning all the class headers contributing to the plug-in doc,
removing C/Qt specific terms, aligning them with the JS syntax and notating
the enums with the syntax actually used (Element.Placement as returned
type and, as enum values, Element.ABOVE, Element.BELOW or maybe
Element.ABOVE, .BELOW for short)?

Note: JS does not distinguish between int and double as separate types (both
are Number, I think). However, as this may be an easy to understand and
useful piece of info and there is rarely (if ever) need to name those types,
I propose to leave this distinction in the doc.

B) Methods

Simply relying on the Q_INVOKABLE keyword might be not enough: there might
be methods which is not the case to document (like the  potentially obsolete
Cursor.rewind() or perhaps Element.clone()).

I propose to ignore for the plug-in documentation functions with Q_INVOKABLE
keyword, but lacking a plug-in-specific //@ comment.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Plugin-documentation-generated-manual-tp7579164.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Qt and OpenType

[Maurizio M. Gavioli]

While looking for ways to improve / extend font support via Qt, I found this
Stack Overflow post:
http://stackoverflow.com/questions/24673444/which-opentype-gsub-features-does-qt-4-8-support
(which, its title notwithstanding, also deals with GPOS features, like
kern, and also covers 5.3).

I have no idea how reliable this info is, but it may show a potential way to
go.

Notes:

1) The set of OT features supported by the custom-compiled' Qt 5.3 lacks the
feature(s) I believe to be most important for our main application field
(musical glyphs), i.e. the stylistic alternates (feature salt) and the
stylistic sets (features ss01 - ss20).

2) It also lacks features which are of great importance for a proper
typographic rendition, like small caps (feature smcp) and 'old style
numerals' (features pnum and onum).

3) The post also gives a reason for the different behaviour of Qt font
management under OSX.

I see two possible strategies:

A) By-passing Qt font management altogether, directly accessing the
underlying font stack, to free us from the recurring bugs of this Qt area,
from the apparent lack of interest in it from the Qt dev team and from the
special OSX case.

On the spot, I have no clear idea how possible / feasible this would be. It
seems very likely it will be far from simple, both on the side of OT support
itself and on the side of integrating 'our' code with Qt drawing primitives.

B) Improving Qt support by fixing bugs potentially still there and adding
more OT features to the 'experimental' Harbuzz support by Qt. This also
would not be simple, but the coding part could follow established practices
and patterns of the existing Qt code base.

This would however require some commitment and recurring work to keep up
with on-going Qt development, until 'our' improvements are not back-ported
to main Qt, if this is at all likely to happen. Also, it would probably not
address the special treatment of OSX.

In any case, it would be a rather medium-to-long term project. Comments and
suggestions are welcome.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Qt-and-OpenType-tp7579162.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Ubuntu 14.04 package

[Maurizio M. Gavioli]

Just for future reference, it might be helpful to other Linux Mint users.

I used the following procedure on an old notebook with a fresh installation
of Linux Mint 17.1 (Rebecca) without any trace of previous MuseScore or
custom Qt installation (Mint 17.1 comes with Qt 5.2.1):

1) Added the PPA via Upgrade Manager

2) Updated the package cache

3) Refreshed the Update List and applied all and only the proposed updates
(i.e. no Update check mark toggled from the default): I noticed that the
UM downloaded and installed (part of) Qt 3.5 from the MuseScore PPA

4) Closed the Update Manage and started Synaptic

5) Searched for MuseScore; two main packages are proposed: the old 1.3
from Ubuntu and the new 2.0 from the PPA (+ a number of collateral,
instrumental, packages); marked the latter for installation

6) Apply!: More Qt 5.3 modules and MuseScore 2.0 are downloaded from the
PPA and installed

7) Closed Synaptic and looked in the Main Menu: the MuseScore 2.0 icon is
smiling from the Sound  Video sub-menu!

8) Started MuseScore 2.0: everything works!!!

Thanks!!!

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Ubuntu-14-04-package-tp7579146p7579155.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

Marc Sabatella wrote
 I am using Ubutnu 14.04, and 31 the July 2012 version of FontForge.

Linux Mint 17 here, which is a derivative of pretty much the same as your OS
(I never manage to remember the correspondence between the two lines). I
used the same FontForge as you up to 3 days ago, when I upgraded to the
latest release (2014-11-27), without noticing any difference in this area.


 With your version of the fonts placed in ~/.fonts, they do show up in
 LibreOffice [...]

This seems to me to indicate that LibreOffice renders the fonts as they are
intended to be rendered!


 lasconic had pointed me to
 https://bugreports.qt-project.org/browse/QTBUG-11387 which sure sounds
 like the same thing - and as I have mentioned, I do see the same results
 on Windows 7.  But that was reported against 4.6.2.  Seems odd that it
 would have been fixed for 5.2 then broken again for 5.3  5.4, but you
 never know.

That bug is probably related, but it is not precisely the same: according to
the report, it affects .OTF fonts with Type1 (PostScript) glyphs, not .TTF
(with TT glyphs) which happen to include GPOS tables. It may indicate that
font managing code is not that stable in Qt...


 Regarding the loss of info  - are you saying that turning off OpenType
 necessarily means losing data, or are you just observing that the versions
 of the TTF files in my PR were missing data?  Remember, it turns out those
 were built from much older sources.  Do we know we'd lose the same data
 building with OpenType off from the current sources?

By generating TTF fonts with the OpenType option turned OFF, FontForge
generates fonts without GSUB and GPOS tables (which is correct) and whatever
data was in these tables is not exported into the font (with the exception
of kerning, for which a TT-specific table exists and is generated by FF).

So, all data in GSUB and GPOS are lost (except kerning); this is perhaps
less sever for Latin script (the average user can probably survive without
the fi, ffi, fl, ffl ligatures) but is a limitation anyway (and --
as I said -- a step back to the 80's in font management), and it might be
much more problematic for non-Latin scripts (for instance for Indic
scripts).

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579056.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

Ok, let's use the big guns...

I run ttx on the current MuseScore FreeXxxx.ttf fonts and on your Mac and
non-Mac variants (downloaded from your github PR). Leaving aside for the
moment being the bold variants, these are the results.

*1) Common tables*: All fonts contains the following tables (which are more
or less mandatory):

'GlyphOrder'
'head'
'hhea'
'maxp'
'OS/2'
'hmtx'
'cmap'
'cvt '
'loca'
'glyf'
'name'
'post'
'gasp'
'FFTM'

*2) The current MuseScore fonts* in addition contain:

*) FreeSans.ttf Tables:
'fpgm'
'prep'
'kern'  for Cyrillic only
'GDEF'
'GPOS'  kern for Cyrillic, Latin and 'bn'(?), but only Cyrillic 
is linked
to main lookup table
'GSUB'

*) FreeSerif.ttf Tables:
'fpgm'
'prep'
'kern'  for Cyrillic and Latin (and several others)
'GDEF'
'GPOS'  kern for Arabic, Cyrillic, Devanagari, Latin, Thai all 
properly
linked
'GSUB'

Note that:
2.1) *both* 'kern' *and* 'GPOS'/'kern' are present
2.2) 'GPOS'/'kern' for FreeSans.ttf is bogus; in fact FreeSans.ttf lacks any
usable kerning data for Latin.

2.1) is in general not good, as the presence of both tables may confuse some
font stack and/or make unpredictable which table a given font stack will
use. The cure for this is to have *only one* of the 'OpenType' and
'Old-style kern' check boxes checked at a time.

2.2) is also obviously not good! There is a cure for this which I gave in my
previous post and will repeat below.

*3) Your font variants* in addition to the common tables also contain:

*) FreeSans.ttf Tables:
'kern'  for Latin only

*) FreeSans-Mac tables:
'GDEF'
'GPOS'  kern for Latin only
'GSUB'

*) FreeSerif.ttf Tables:
'kern'  for Latin only

*) FreeSerif-Mac.ttf Tables:
'GDEF'
'GPOS'  kern for Latin only
'GSUB'

Note that:

3.1) non-Mac versions have the 'kern' table and lack the OpenType tables (as
you turned off the OpenType check box) and that Mac versions have the
OpenType tables and lack the 'kern' table (as you turned on the OpenTypeType
check box and possibly kept off the Old-style kern check box). Having only
one of the two tables is generally positive, as I said above.

3.2) Having different sets of tables for different fonts is sub-optimal, as
it complicates maintenance and development and might be a source of problems
difficult to track. My opinion is that there should a very good reason for
this.

3.3) All fonts lost the non-Latin kern data. This may be secondary right
now, but has to be kept in mind, given the international coverage of
MuseScore. It would be nice to know from which editing / choice of settings
this happened.

3.4) All fonts lack the 'fpgm' and 'prep' tables. They are not related with
kern (at least, they should not be), but with font instructing: loosing
these tables is generally not good, as very few (and usually rather simple)
fonts can have instructing without them. We probably do not want to loose
them.
__

*4) Some conclusions?*

4.1) Of the two possibilities surfaced above:

'kern' table only without 'GPOS'/'kern'
vs.
'GPOS'/'kern' (and in general OpenType) tables only without the 'kern'
table,

I believe the latter is generally preferable, because the former is a rather
outdated setup and because other OpenType tables may contain useful data;
for instance the FreeType-based font stack in (most) Linux automatically
recognizes the 'GSUB'/'liga' sub-table for ligature substitution.

4.2) Of course, this implies that data in OpenType tables are correct. In
current MuseScore FreeSans.sfd font, 'GPOS'/'kern' data are inconsistent,
this is why it does not behave correctly.

4.3) Fixing FreeSans.sfd is easy: it is enough to add the missing 'kern'
feature in the 'GPOS'/'kern' sub-table. With this change, the rebellious
VA pair -- among others -- kerns correctly!

4.4) IMHO, until something solid surfaces against, the way to go is to
generate all fonts from FontForge with:
*) Correct table data!
*) OpenType turned ON
*) Old-style kern turned OFF
*) TrueType hints turned ON

in order to have 'GPOS'/'kern' sub-table (and other potentially useful
OpenType tables) without the 'kern' table messing in.

If helpful, I can submit a PR along 4.3) and 4.4) guidelines. If this would
be more messy than helpful, I'll happily leave it to someone else.

4.5) For Mac/OSX, the impact of the Apple generation option possibly
requires some investigation. I cannot do that; if someone is willing, is
welcome! I would start with the options listed above, though.

Hoping it helps...

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579045.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business 

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

OK, one .ttf is worth a thousand words... ;)

you (as well as everybody else) can download my attempts so far from:

http://vistamaremusica.com/extras/FreeSans.ttf

and

http://vistamaremusica.com/extras/FreeSerif.ttf

Both kerns correctly in my MuseScore and contain all the original data. I
didn't try *all* the kerning pairs, of course, as many are not easy to spot
visually, but the most obvious ones (AV, VA, and on Serif, rj) do
kern.

I downloaded the latest FreeFont sources and they have perhaps more glyphs
but still have the same problems 'our' older sources have. The fonts linked
above come from 'our' older sources.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579047.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

Marc Sabatella wrote
 No dice.  Neither of those fonts kern correctly for me on any of my three
 systems.  Again, both Linux systems are running Qt 5.4; there, neither
 font kerns at all.  My Windows machine has Qt 5.3.  On that machine, your
 FreeSerif will kern the rj but not the Te or the VA.

Results for rj and Te are correct: FreeSerif does contain a kerning pair
for rj but it DOES NOT contain a kerning pair for Te: obviously the
latter will not kern under any circumstance!

About VA / AV: are you sure it does not kern? For this pair the overlap
is very tiny: in practice the tip of the serif of the 'A' just overlaps the
tip of the serif of the 'V'.  This is a screen shot of the result to be
expected:

http://dev-list.musescore.org/file/n7579049/test_kern_VArj_FreeSerif.png 


 Your FreeSans will kern the VA but not either of the other pairs.  I
 assume the difference has to do with different types of tables, but you
 know more about that than I.

This also is correct: FreeSans has a kern pair for VA (stronger than
Serif's) but NOT for rj or Te.


 Again, only by *unchecking* the OpenType box can I get these fonts to kern
 correctly on my Linux machine running Qt 5.4 or my Windows machine running
 5.3.

Well, I do not understand this: as far as your description goes, the fonts
DO kern correctly (with the possible exception of Serif VA); if by
unchecking the box, the fonts kern more than their data or for pairs which
have no kern data, I don't think this to be correct. Am I missing
something?

  And I found the same for Linux with 5.3 back in August; that's why I
 went to two different MuseJazz fonts back then.  But I have no idea why
 MuseJazz will kern for me on Qt 5.4 even with OpenType checked but the
 other fonts won't.

Is it possible that MuseJazz simply has more aggressive kerning data and
then it is easier to spot by eye?

Just for completeness, which Linux do you have?


 BTW, I checked other system fonts.  On my Windows / Qt 5.3 machine,
 Arial and Times New Roman kern just fine, others are more hit and miss,
 but overall I'd say kerning works in MuseScore on Windows.  On my Linux
 / Qt 5.4 machines, very few fonts kern well.  Many work like your
 FreeSerif does on Windows - some pairs you expect to see kern do, but
 others don't. Others don't kern at all.

Have you tried these fonts with other aplications, perhaps non-Qt-based?


 It's looking like there is probably a Qt issue with OpenType on Linux and
 Windows, but I still don't know how to quantfiy it.

A difference in font support among the various Qt versions is definitely
possible, but I would expect it to go toward a better support for OpenType
tables not away from it... As soon as Linux Mint 17.1 will be released I'll
upgrade another machine of mines to it and install the latest Qt (I'm not
eager to upgrade Qt on my main machine: I have other Qt projects on it and
if it ain't broken, don't fix it).

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579049.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

A small detail: I discovered that the 'standard' FreeSans.ttf coming with my
distro has a different structure than FreeSerif: if open with FontForge, it
lacks kerning data for Latin (as 'our' FreeSans does); possibly they are in
the old-style 'kern' table rather than in the GPOS table / 'kern' sub-table.

This 'standard' FreeSans also DOES NOT kern with MuseScore, as 'our'
FreeSans.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579043.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Kerning

[Maurizio M. Gavioli]

I start by limiting my observations to Linux, where I can analyse things more
thoroughly. My system: Linux Mint 17 64bit, with self compiled sources with
Qt Creator 3.1.2 and Qt lib 5.2.1. MuseScore built-in .ttf fonts are used as
they come in the current master.

I had the additional problem that Free Sans/Serif font is installed by
default on my distro and hides the font which comes with MuseScore. For
cleaner results, I removed the system font, but this might not be what the
average user wants to do (or *knows* how to do!): possibly another detail to
keep in mind.

A) By adding a staff text element and setting a specific font, I can notice
the following:

- Free Sans is NOT kerned;
- Free Serif IS kerned;
- MuseJazz IS kerned;
- all the 'standard' textual fonts I tried are kerned (by 'standard', I mean
textual fonts which either comes with my distro or I got from well-known
foundries, for instance Liberation, DejaVu, Droid, Gentium, Linux Libertine
and others. I ignored non-textual fonts, like dingbats or symbols).


B) *Notice*: care should be used in the string used for showing the kerning.

For instance, for the Terj string used by Marc as a test bed: in the Free
Serif/Sans, the digraph Te is kerned very little (-30 FU in Serif and -25
FU in Sans) and the offset is in many cases not easily noticeable. The
digraph VA is kerned significantly more: -70 FU in Serif and -60 FU in
Sans and should give more visible results.

Even more: rj is not kerned at all in Free Sans, but heavily kerned in
Serif (-70 FU).

In practice, a string like VA or AV should show rather evident kerning
for any font which has kerning data.


C) *Kerning tables* in .ttf fonts. If I open the current FreeSerif.ttf and
FreeSans.ttf fonts with FontForge, I notice that for both it raises a
warning:

This font contains both a 'kern' table and a 'GPOS' table. The 'kern' table
will only be read if there is no 'kern' feature in 'GPOS'.

It looks like the fonts have been generated from the .sfd with the Old
style kern box checked.

Actually, after loading into FontForge the .ttf's, FreeSerif has kerning
data in GPOS for Latin, but FreeSans lacks such data (only has kerning for
Cyrillic).

By examining the lookup tables of the source FreeSans.sfd, it appears that
the GSUB kern table for Latin has no feature at all. By adding a 'kern'
feature for latn{dflt} to the kern lookup for Latin, re-generating the font
and re-compiling MuseScore, also the Free Sans is kerned.

For the font generation, I used the following options:

Apple: OFF
OpenType: ON
Old style 'kern': OFF
_

D) About discrepancies between Windows and Mac (two systems I cannot work
with, as I no longer have machines running either), I simply want to remind
that Microsoft and Apple succeeded in making TTF and OTF specs a mess by
disagreeing in several details (kerning being one of them) and issuing
conflicting specs. Then I am not surprised that the same font may work
differently under Windows and under OSX but, as I said, I am not an expert
of these areas.

Anyway, we may have to accept the idea that different versions of the fonts
should be used under the two OSes.


E) About the advice in fonts/README.md to uncheck Old style kern, I
originally put it in, because somebody (possibly Marc himself?) noticed
kerning issues under Windows with this box checked (this is also connected
with D) above).

I still believe that turning the Old style 'kern' on, may confuse some
font stack in some OS, but I will welcome reports of successful font
generation with this box turned ON.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Kerning-tp7579040p7579042.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] On ping-pong-ing layout

[Maurizio M. Gavioli]

I'll take the issue http://musescore.org/en/node/30941 as an example (but
other examples exist and more or less anybody met this anomaly once) and
specifically the sample score posted in the thread last comment (
http://musescore.org/en/node/30941#comment-129056 ):

I think (part of?) the problem resides in the *Score::layoutSystem()*
function (file libmscore/layout.cpp); it uses *Measure::minWidth1()* and
*Measure::minWidth2()* to compute the measure width, accumulate them into a
total width and stop when the system width is exceeded.

A measure might require courtesy elements after itself (clef, key sig., time
sig.), if system-final, but obviously does not if not system-final.
Occasionally, the bare width of the measure does fit in the system, but the
width of the measure + court. elements does not. This happens with measure 7
of the sample score quoted above.

*Measure::minWidth1()* and *Measure::minWidth2()* do not take any cautionary
/ courtesy element at the end of the system into account to compute the
measure width; nor should they, as these functions are agnostic about the
context the measure is in.

Also *Score::layoutSystem()* does not look for courtesy elements: it only
accumulates measure bare widths against the total system width. Courtesy
elements are added afterwards by *Score::layoutSystemRow()*, once
*Score::layoutSystem()* returns. At this point, the measures belonging to
the systems are defined and *Score::layoutSystemRow()* 'squeezes' courtesy
elements in, without noticing this exceeds the system width.

At next layout, the system final courtesy elements will be there and will be
accounted for, resulting in the last system measure being moved to the next
system (which in turns removes the courtesy elements, no longer needed)...
and so on...

I see two possible strategies:

1) *Score::layoutSystem()* checks for potential courtesy elements before
adding another measure to the system.

2) *Score::layoutSystemRow()* checks for available room before adding the
courtesy elements it sees needed and removes the last system measure if they
do not fit.

Any suggestion? Anyone volunteering to pick up the task?

Thanks,

M.



--
View this message in context: 
http://dev-list.musescore.org/On-ping-pong-ing-layout-tp7578972.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] On ping-pong-ing layout

[Maurizio M. Gavioli]

Marc Sabatella wrote
 Thanks for looking into this further! [...]
 
 I see two possible strategies:

 1) *Score::layoutSystem()* checks for potential courtesy elements before
 adding another measure to the system.

 2) *Score::layoutSystemRow()* checks for available room before adding the
 courtesy elements it sees needed and removes the last system measure if
 they
 do not fit.
 
 [...] My gut feel is that #1 makes more sense, because if
 layoutSystemRow(0 decides it needs to remove a measure from a system, it
 is going to need to call layoutSystem() again on every system from then
 on, and this process could potentially go on and on.  I think I'd rather
 layoutSystem get the calculation right the first time - even if that
 means being a bit conservative.  Not sure it would, but I'd be willing to
 live with it. [...]

Precisely along these lines, further investigation unearthed a function
*Score::cautionaryWidth()* in layout.cpp, which is apparently supposed to do
exactly that: detect and compute the width of cautionary/courtesy elements
after a measure. A TODO note in *Score::layoutSystem()* hints it should be
used there, but in fact it is not (it is actually not used at all).

Anybody knows why? Is *Score::cautionaryWidth()* still unfinished or wrong?
Is an old lead now abandoned?

Thanks,

M.



--
View this message in context: 
http://dev-list.musescore.org/On-ping-pong-ing-layout-tp7578972p7578979.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Bar lines: issues and inconsistencies

[Maurizio M. Gavioli]

Sorry for the double post; afterwards posting to the forum, I realized the
dev-list is probably a much better place.

Having spent several days trying to 'clean up' the situation for bar lines
with little result, I'll note here the most important issues and
inconsistencies I noticed, trying to stick to general notation cases,
without involving (at least not too much) niche or highly specialized use
cases.

*1) 'Generated' status*
ulliBar lines initially created by the New Score Wizard are marked as
*non-generated*/li
liBar lines of measure manually /added at the end/ of the score are marked
as *non-generated*/li
liBar lines of measure manually /inserted in the middle/ of the score are
marked as *generated*./li/ul

*2) Custom types and spans*
When a bar line marked as generated is individually changed in type or span,
its /generated/ flag is not set to false and the bar line itself is not
written to the output file (i.e. is lost on saving and reloading)

*3) System-initial bar line*
Editing the span of a system-initial bar line changes the span of *all* the
bar lines of a scores.

System-initial bar lines should probably remain non-editable, as the use
cases proposed for this (mostly related to jazz specific notations) could be
obtained by other means and any customization of these bar lines is lost
when system breaks change.

*4) /BarLine::_generated/ and /Measure::_endBarLineGenerated/ flags*
The meaning of the first flag should be rather clear: if a bar line is
generated, it should not be written to the output file and all its
parameters should be reconstructible on reading the file back.

I could not understand the meaning of the second flag: I believe I found
occurrencies of all the 4 combinations of true and false for the two flags
in a measure and its bar lines. Any authoritative statement about this?

There are other issues, for instance related to repeats and multi-measures,
possibly correlated with these; they are detailed in specific issues and I
will not repeat them here.

Any comment is welcome about how to proceed to improve the situation. So
far, my attempts failed, as little changes here or there trigger big -- and
unexpected -- changes in the score files with loosing of info and improbable
(or wrong) behaviour while editing.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Bar-lines-issues-and-inconsistencies-tp7578969.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Towards MuseScore 2.0 beta1

[Maurizio M. Gavioli]

Aaaalleluja, lleluja, alleeluuj

*Demo:*

I was planning to provide one or two short demo scores of historic
tablatures; say, one Dowland piece for lute (or one Hume piece for viol) for
the French tab style and one Verdelot madrigal tabulated for lute by A.
Willaert for Italian tab style. Each should fit in one or two pages.
Palatable?

What about one XV or XVI c. polyphony piece to show off some moderately
weird ancient stuff? This would be hard to fit in a single page, though (3-4
pages on average).

*Documentation*:

I can take care of documenting the features I contributed most (tabs, basso
continuo, ecc...). The skeleton of them should already be there in the New
features for MuseScore 2.0 section; I'll check it is up-to-date. If anybody
notices something missing, please shout.

*Translation*:

Of course, if necessary, I could deal with the Italian translation
(MuseScore presence in Italy is well below its potential), but the guys who
did the Italian translation for 1.x did a good job and, if they are still
around and still inclined to collaborate, I believe it would be better...

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Towards-MuseScore-2-0-beta1-tp7578893p7578904.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Enum's and plug-ins

[Maurizio M. Gavioli]

Jojo-Schmitz wrote
From: Joachim Schmitz [mailto:

 jojo@

 ] 
From: Maurizio M. Gavioli [mailto:

 miwarre@

 ]

https://qt-project.org/doc/qt-5/qobject.html#Q_ENUMS:
In addition, the class defining the enum has to inherit QObject as well as
 declare the enum using Q_ENUMS().
 
 Here's where the problem starts, I think. How to inherit QObject from
 outside a class? How to use Q_ENUMS() outside a class?

Neither can be done: only a class can inherit QObject and Q_ENUMS() is only
valid within a class.

An attempt of simulating an out-of-class enum for QML can be seen at:
http://qt-project.org/forums/viewthread/18529

I think it is better to avoid dirty tricks of this kind and pull back those
enums into some class; several enums have an obvious class candidate; the
Element class could be used for the other.

Maybe, the enum themselves could be turned into full-fledged classes, but
this probably raises other concerns.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Enum-s-and-plug-ins-tp7578860p7578863.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Enum's and plug-ins

[Maurizio M. Gavioli]

There seem to be problems with enum's in the current plug-in framework:
according to documentation, to be accessible to QML, enum's should be
defined *within* a QObject derived class.

See
https://qt-project.org/doc/qt-5/qtqml-cppintegration-data.html#enumeration-types
or
https://qt-project.org/doc/qt-5/qtqml-cppintegration-exposecppattributes.html

For instance, having brought the ElementType enum outside of the Element
class made it unavailable to QML plug-ins. All plug-ins which rely on score
scanning to detect element of one type or another (i.e. the great majority
of plug-ins) no longer work. This applies to other enum's as well
(DynamicRange, Placement, ...).

I think something should be done to address this.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Enum-s-and-plug-ins-tp7578860.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Keyboard usability and accessibility

[Maurizio M. Gavioli]

AndreiTuicu wrote
 If for example I select a button using TAB and press Return, the button
 will not be clicked, instead the system break action will be triggered. If
 I'm editing text in a textbox and press CTRL+A I'm not selecting the whole
 text, instead I'm triggering the action that selects all the elements from
 the score.

I'm using Linux, but I cannot confirm this:

*Arrows*: I can move around in menus with the arrows, without them affecting
the score.
*TAB/Shift-TAB*: I can move from one dlg control to the other with TAB and
Shift-TAB, without affecting the score (both in modal dlgs, like, for
instance File | Info and non-modal dlgs like Inspector).
*Ctrl-A*: I can select whole text in dlg text controls and even in score
textual elements (in edit mode) with Ctrl-A without it selecting the whole
score.

There is one glitch, though: in the Inspector, numeric fields are assumed to
be 'spinnable' with arrows, but using arrows, for instance with a note
selected, changes the pitch of the note rather than the spin value.
Possibly, something to tune in the dlg design?

For the rest, I am noting no mis-behaving of key strokes associated with
shortcuts.


 1. Move every QAction that affects the score in the ScoreTab object and
 change their shorcutcontext from WindowShortcut to , leaving in the
 MuseScore object (Main window) just those that open subwindows,
 dialogs,etc.
 
 2. Set the focus policy for all the other subwindows of the main window so
 that the they don't receive focus by clicking on their elements (except
 for the case when text editing is necesary)
 
 3. (optional) Restrict the user from assigning keys like Return, Tab,
 Arrow keys as shortcuts.

I have no clear idea of the consequences of 1), but I assume you have
studied the matter.

2) raises some questions. On one hand, the fact that the Inspector, the
Palette and, say, the zoom control keep the focus once open or clicked and
do not release it until the user does not clicks on the score window is
rather inconvenient (for instance, pressing F8 opens the Inspector, but
pressing F8 again does NOT close it). On the other hand, having the
Inspector retaining the focus ensures that it can be navigated via the usual
keystrokes, without re-clicking on it.


 Details [snipped]:
 
 I would like your opinions regarding the following:
 Q1: What do you think about step 3?
 Q2: Do you know other usecases in which  the scoretab should give away the
 focus, except when editing text?

Q1 - Step 3: Except for the 'spinnable' Inspector values, I am not
experiencing any issue with shortcuts using keys also used to navigate dlgs
and menus. I don't know if it a Linux-only privilege, but this point seems
to me fine as it is.

Q2 - window focus: see my doubts above. Would it not rather be the case to
have a 'system'-key which would move the focus to the main score window from
wherever it is? Once upon the time, F10 used to do something similar in many
(Windows?) apps (from the main app window to menus and back).

Hoping this can be of some usefulness,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Keyboard-usability-and-accessibility-tp7578844p7578845.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://www.hpccsystems.com
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Bass guitars in instruments.xml

[Maurizio M. Gavioli]

About the lt:initgt; tag, see for instance:

https://github.com/musescore/MuseScore/blob/master/share/templates/instruments.xml#L7934





--
View this message in context: 
http://dev-list.musescore.org/Bass-guitars-in-instruments-xml-tp7578800p7578822.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Bass guitars in instruments.xml

[Maurizio M. Gavioli]

AndreiTuicu wrote
 The number of strings that are set in the staff properties should match
 the number of lines from the tab.

No, it should not. There is plenty of instruments for which the number of
strings is different from the number of tab lines, for instance most of the
lute models (and most of the instruments derived from it): they can have up
to 14 strings/courses, but always 6 lines are used in tabs. Same for the
7-string viola da gamba.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Bass-guitars-in-instruments-xml-tp7578800p7578823.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Guitars in intruments.xml

[Maurizio M. Gavioli]

Thanks to David for unearthing the original source of these data
(palaeo-organology?).


ChurchOrganist wrote
 I suspect the multitude of guitars have been added to cater for mariachi
 bands which, according to Wikipedia use several sizes of guitars.
 
 http://en.wikipedia.org/wiki/Guitar#Acoustic_guitars
 
 The alto guitar is in very common use as a young children's instrument,
 but in my experience is tuned a minor third higher than a conventional
 guitar, not the fourth higher you mention.

Thanks for these two precisations. All of this however leaves us with the
problem of what to do with all these instruments.

A) We leave everything as it is (easy!), hoping that the data provided will
satisfy the majority of the users.

B) We remove instruments not used widely enough and/or for which
unquestionable data cannot be provided or agreed upon (we should not forget
that an occasionally used instrument can be obtained 'recycling' and
adapting a similar instrument, at least on a per-score basis). Who decides?

I have no idea if writing for the /mariachi/ accounts for a significant part
of the Musescore user base; for instance I noticed the lack of the
/guitarron/ which is used over a large part of the Spanish-speaking world
(in several different variants, I'm sure!) but we need to draw a line
somewhere. Practical suggestions from peoples with specific knowledge and
experience would help.


 There are many different tunings for Pedal Steel that you would probably
 need to provide several different tabs for it. The following Wikipedia
 article may help you, however
 
 http://en.wikipedia.org/wiki/Copedent

Thanks; I tried hard NOT to look at that page and the data it provides! Tab
templates are relatively cheap in terms of coding, but I do not feel the
/Kategorischer Imperativ/ to add templates for each and any tablature ever
used in the history of music. The longer these lists become, the harder will
be for the average user to find what he is after (I'd bet that two or three
items alone accounts for the great majority of the uses).

As the MuseScore tab structure editor allows the user to derive almost
anything in terms of tab structures for stringed instruments, only those
structures which are in 'wide enough' usage should be provided out of the
box as templates. If a few additional templates are needed/useful to match
the need of a representative number of MuseScore users, ok, but, again, we
need to draw a line somewhere.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Guitars-in-intruments-xml-tp7578799p7578824.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Guitars in intruments.xml

[Maurizio M. Gavioli]

I noticed that some guitars lack string data in instruments.xml. Not being
particularly familiar with guitars beyond THE guitar, before messing with
the file, I would prefer someone could confirm the following details:

1) *Soprano guitar*: does it exists? I found surprisingly few references for
it and, according to  Fender web site
https://www.fender.com/news/musical-ranges-and-how-they-relate-to-guitars/ 
, /You don’t really run into it [i.e. the soprano term] in guitar land,
but the smallest of the four common ukulele.../.

In case, it seems from the instruments.xml pitch range that it
is/should/could be tuned one octave above the 'regular' guitar with only 17
frets. 6 strings?

2) *Alto guitar*: same considerations as above. Always according to Fender
web sites: /The term [alto] applies to a small number of instruments
[...], but almost never in the guitar world. Tech Talk googled “alto guitar”
and did find such a thing, but we’re talking seldom seen and extremely
esoteric instrumentation/.

Again from the pitch range in instruments.xml, it seems to be tuned a fifth
above the 'regular' guitar again with 17 frets. 6 strings?

3) *11-string alto guitar*. According to  Wikipedia
http://en.wikipedia.org/wiki/Eleven-string_alto_guitar  , its 6 top string
are tuned lute-style (from G and with third between 3rd and 4th string)
rather guitar-like (from E and with third between 2nd and 3rd string). Can
anyone confirm this?

4) *Pedal steel guitar*: before involving in arcane investigations, does it
make sense to provide string data/tuning for it?

More to come about (guitar) basses...

Thanks,
Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Guitars-in-intruments-xml-tp7578799.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

[Mscore-developer] Bass guitars in instruments.xml

[Maurizio M. Gavioli]

And now about basses and bass guitars.

1) The instruments.xml file contains entries for: A) bass guitar, B)
acoustic bass, C) electric bass. Are they 3 different instruments or A) is
just a generic name for both B) and C)?

2) *MIDI*: They are assigned 3 different MIDI channels: A) 34, B) 32, C) 33.
Is this correct?

3) *Strings*: A) and C) are assigned 4 strings (E1 A1 D2 G2). For B) no
string data are supplied. Should it be the same as the other two?

4) *Ranges*: A) and C) are given a pro/amateur range E1 - F4 while B) is
given an amateur range E1 - D4 and a pro range B0 - G4. Correct? Really B)
goes a fourth below than the other two? Or is a contamination with the
5-string bass (see below)?

5) *5-string bass*: there has been requests for it to be added (for instance 
http://musescore.org/en/node/15289#comment-100627
http://musescore.org/en/node/15289#comment-100627  ) both to
instruments.xml and to the tablature presets. The suggested tuning is B0 E1
A1 D2 G2. Comments?

Thanks,
Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Bass-guitars-in-instruments-xml-tp7578800.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Bass guitars in instruments.xml

[Maurizio M. Gavioli]

Marc, thanks for the reply.

Now that you say it, I think I remember having read about this equivalence
acoustic bass lt;=gt; contrabass in another thread either here on the ML
or in the fora.

Just to avoid future repetitions of the question, I think I will change the
acoustic bass entry in this way:

lt;Instrument id=acoustic-bassgt;
nbsp; nbsp; lt;initgt;contrabasslt;/initgt;
nbsp; nbsp; lt;longNamegt;Acoustic Basslt;/longNamegt;
nbsp; nbsp; lt;shortNamegt;Basslt;/shortNamegt;
nbsp; nbsp; lt;descriptiongt;Acoustic Basslt;/descriptiongt;
nbsp; nbsp; lt;musicXMLidgt;pluck.bass.acousticlt;/musicXMLidgt;
nbsp; nbsp; lt;Channelgt;
nbsp; nbsp; nbsp; nbsp; lt;program value=32/gt;
nbsp; nbsp; lt;/Channelgt;
lt;/Instrument

This should make clear to anybody else perusing the file that the entry
refers to a contrabass, while keeping the specific names and plucked style
(I'll check the lt;initgt; tag supports all the required tags, though).

I think with the details you provided, this part of instruments.xml can be
reasonably considered done.

[Side note: The entry for contrabass is also not entirely clear:
1) it is duplicated into a contrabass and a double-bass entry, with the
same data except for the names; probably an lt;initgt; would be useful
here too.
2) Pitch ranges for both oscillate between a low E tuning and a (5-string?)
low B tuning.]

Thanks,
Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Bass-guitars-in-instruments-xml-tp7578800p7578808.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Introduction

[Maurizio M. Gavioli]

Hello John,

Thanks for the intro and welcome aboard!

I'm the person assigned as mentor to your project; I saw you already walked
a good way on yourself, but do not hesitate to contact me at any moment: in
the MuseScore fora and in the IRC #musescore channel, I go under the
nickname Miwarre, and here and at Github under my real name.

Being the original implementor of tab support in Musescore 2.0, I'm of
course familiar with that part of the code; however I know little about
Guitar Pro and about modern guitar(s) in general (my interest is in historic
tablatures: lute, viol and so on...); so, your knowledge will be primary in
these areas.

I'm confident this project will be successful and a useful addition to
MuseScore features.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Introduction-tp7578717p7578718.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Aeolus Organ Synth

[Maurizio M. Gavioli]

It is not up to me to make objections! Just out of curiosity:

1) You are an organist, I am not. Is McCoy's Jeux (I think you refer to the
1.4 version) good enough (flexible enough) to be worth including an
organ-specific sound font? I played with it years ago and I have no specific
recollections of having been exceedingly impressed (my fault, likely!).

2) Are you aware of Jeux d'Orgue by J. Basquin (  I got it from here
http://www.jeuxdorgues.com/   )? It is larger (22MB) but I seem to
remember it was quite good.

Thanks,

M.



--
View this message in context: 
http://dev-list.musescore.org/Aeolus-Organ-Synth-tp7578364p7578383.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Visual test suite

[Maurizio M. Gavioli]

lasconic wrote
 The font should be the same.

Even with the same fonts, a different freetype version might be enough to
generate slightly different rasterizations.

 Any idea is welcome, but I would prefer to solve the root cause.

Yes, but it is important to detect (and then, if possible, solve) *real*
problems. For instance, a different order of the the same (commutative)
arithmetic operations may lead to different floating point rounding, which
might cause a different grid fitting and make the tests to fail; but there
might be no *real* (= evident to the eye) difference (no *real* layout
change).

Then, my feeling is that a way to have the kind of side-by-side image
comparisons as in the sample test run can be VERY useful to speed up the
check, but the final judge is better to be a human eye (and a human brain).

But this is just my opinion, of course!

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Visual-test-suite-tp7578380p7578389.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Problems building on 32bit linux

[Maurizio M. Gavioli]

Exactly same behaviour (compile succeeds, run fails on loading .qrc
resources) here in a slightly different the system:

Mint 14 64bit
Qt 5.1.0 64bit installed from offline installer
cmake 2.8.9 (default in distro)
gcc 4.7.2 (default in distro)

Commit c4e95c776 (yesterday evening) compiled through Qt Creator. I have
tried 'messing' a little with the definitions in musescore.qrc and with the
loading code but without any result.

A question for heuchi: do you still have Qt 4.8.x installed in your system?
I do and I'm checking for possible conflicts.

Thanks,
Maurizio


heuchi wrote
 I can compile but it doesn't run:
 cannot open shortcuts
 Mscore: fatal error: cannot load internal font :/fonts/mscore-20.ttf
 
 Somehow all the resources defined in musescore.qrc are not available to
 the application. When called with -d switch it omplains about not beeing
 able to load any of the fonts, and a short test showed it can't even load
 the revision number.
 
 My system is running:
 ubuntu 12.04
 gcc 4.8.1
 QMake version 3.0 using Qt version 5.1.0
 cmake 2.8.11.2





--
View this message in context: 
http://dev-list.musescore.org/Problems-building-on-32bit-linux-tp7578222p7578229.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] MuseScore and Qt5

[Maurizio M. Gavioli]

ChurchOrganist wrote
 Are there instructions anywhere on upgrading the MuseScore Development
 Environment to QT 5?
 
 If it's just a case of installing the QT 5 binaries I can probably cope
 with it, but if I need to start sorting out fresh links to MinGW etc, then
 I'm afraid I will need some help.

Last time I checked on Windows, installing Qt 5 was actually simpler than
installing Qt 4.8.x, as it came with everything needed (except cmake, I
think, and of course MuseScore-specific dependencies but you should already
have them from your current setup).

Unless things changed in the meantime, it should be rather straightforward.

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/MuseScore-and-Qt5-tp7577788p7578120.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer

Re: [Mscore-developer] Issues using SimpleText for Harmony editing

[Maurizio M. Gavioli]

lasconic wrote
 Chordnames and Figured bass styles are already hidden in Style - Text
 Style.
 I don't see why they should be selectable in the Text Tool bar (the bottom
 bar when your enter a text), or why this bar should be displayed at all
 for these 2 types.
 Same for right click - text properties.
 
 In the end, I wonder if we really need style at all for these two elements
 since they are not really Text after all. The Text is just used as a proxy
 in the normal case.
 Maurizio, any opinion on this? I can see that you kept the figured bass
 text style.

Sorry for the delay: bad week, dead lines, ...

Usually, a normal, well-formed fig. bass element does not need anything from
either Text or SimpleText: its formatting is totally self-contained and
depends upon the parameters set in Styles | General | Figured Bass.

I kept the fig. bass text style and, even more, I kept the whole FiguredBass
element as derived from the full Text class for a few reasons, some
instrumental and one cautionary:

1) While editing a fig. bass entry, it is easier to re-use the already
implemented (Simple)Text editing functions rather then re-implement them; to
do this, some text style has to be applied to the text, possibly a text
style similar enough to the current Fig. Bass parameters: this is what the
fig. bass text style is used for. In fact, when the Styles | General |
Figured Bass are edited, the fig. bass text style is updated to be as
similar as possible to them.

2) If an entry is not well-formed (I believe to have covered all the
reasonable cases, but I cannot rule out that some sources exist which use
non-standard syntax), the internal formatting is bypassed and the SimpleText
mechanism is used instead. Again, a text style is needed for that and the
fig. bass text style is used.

3) Lastly, it is conceivable that occasionally a fig. bass entry may be
needed which needs special style(s), for emphasis or for didactic purpose
(or for whatever else: user ingenuity has no limit!). So, I wanted to leave
the user free to assign to a fig. bass entry a different style or even to
have it unstyled with full text markup. It is for this reason that the Text
Properties item appears in the contextual menu; this also requires the
Figured Bass text style to appear in the drop lists to be able to
re-assign the default style to a changed entry.

All the above can be discussed, of course, but I think the above decisions
to be reasonable.

Thanks,

Maurizio



--
View this message in context: 
http://dev-list.musescore.org/Issues-using-SimpleText-for-Harmony-editing-tp7578018p7578022.html
Sent from the MuseScore Developer mailing list archive at Nabble.com.

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer