Suppress the 'non-controlling' attribute in measures

[cecilios]

Excuse my English. If something is not clear please ask me for clarifications.

I propose to suppress the 'non-controlling' attribute in measures. I think there are some conceptual problems about the 'non-controlling' attribute that I would like to share.

I understand that MusicXML inherits the 'non-controlling' concept from MuseData, probably without much questioning. I assume that in MuseData this attribute is just a 'trick' for dealing with multi-metric music.

But for a modern web standard these kind of tricks should be avoided.

MusicXML can provide explicit information about line breaks and page breaks, as well as much more formatting information. Therefore, no need for tricks. Either export all formatting information or do not export it at all and leave the importer application to deal with formatting. In any case, MusicXML importers need to be prepared to deal with files with no formatting information. The 'non-controlling' attribute adds nothing but noise!

It can be argued that this attribute doesn't cause harm and can be of help. But:

1. Where is this concept clearly defined? This is the only definition I found (from DTD):

" The non-controlling attribute is intended for use in multimetric music like the Don Giovanni minuet. If set to "yes", the left barline in this measure does not coincide with the left barline of measures in other parts. The value is "no" if not specified. "

With this definition the value of this attribute can be easily computed just by analysing the time position of barlines! Do we need to explicitly encode an easily derivable value? It is good practice not to represent derived values, only primitive ones. Among other issues, inconsistencies could arise.

1. Is this attribute mandatory? No!!! Then, why any line break algorithm should bother about it? The layout algorithms can not rely on this attribute as it might not be present when needed! But on the contrary, it adds work for MusicXML export (unless, as it is not mandatory, the exporter program decides not to deal with it!). What is the benefit from having this attribute?
2. Its mere existence 'contaminates' any music program trying to export MusicXML format: if a web standard needs it, this transmits the idea that for music layout this is necessary information, being difficult to do proper layout without it. And somehow may condition internal music representation.

It should be expected that line-break algorithms are prepared for breaking lines at barlines, but also line-break algorithms should naturally deal with music with no barlines at all, without relaying on more tricks (non-visible barlines). And multi-metric music is just an intermediate case between both, in which breaks should be allowed only at barlines common to all parts.

If my interpretation is wrong and the 'non-controlling' concept is more than explicitly signalling easily deducible information from barlines alignment in time, then the concept needs clarification. Probably, it is a new concept: 'hints' for algorithms? This will open the door for demanding more 'hints': why hints for line break and not for other tasks?

So, if my understanding is correct and I did'nt miss anything, I would suggest to consider removing this attribute. Otherwise, I would appreciate clarifications. Thank you!

Regards,
Cecilio Salmeron

[BJungmann]

The non-controlling topic has been discussed on the List in August 2012, and again March 2013. Have you seen the Don Giovanni example? I doubt if you really see the problem, it is not mainly the line break question, but the barline alignment. There are two pages as pdf at http://bjungmann.privat.t-online.de/MusicXML/DonGiov195_12.pdf, and a capella file at http://bjungmann.privat.t-online.de/MusicXML/DonGiov195_12.cap and a corresponding MusicXML version at http://bjungmann.privat.t-online.de/MusicXML/DonGiov195_12.xml. capella can convert them into each other since July 2013. As far as I know, capella is the only music notes editor that can cope with this.

By the way, line breaks in the midst of measures are quite common and easily written in capella, but you need tricks to export a staff with a half measure without barline at the end to MusicXML. But this is not the use case for the non-controlling attribute, as far as I know.

I am not very fond of this attribute's definition, but I've managed to use it somehow. And I cannot give a better solution for the Don Giovanni use case. Or should we simply say, Mozart was wrong?

Cheers,
Bernd

[cecilios]

Hi Bern,

Thank you very much for your comments.

When proposing this change I was aware of multi-metric music and of the typical Don Giovanni example. But, certainly, I was not aware of any 'barline alignment' problem. In my software, barlines are naturally aligned by the same rule used for aligning noteheads: all barlines at the same position in time must go aligned. In a multi-metric score this implies than only common barlines for all parts will be aligned. This is what human engravers have always done for years without the need to create new concepts for balines.

This brings to my mind the MusicXML issue of distinguishing between left and right barlines (what are they? in music there are only barlines, and no one book on music engraving says a word about left-barlines or right-barlines!. The position of a barline, at left or are right is just an issue for a local observer, i.e. a note. Even, in MusicXML certain barlines (repetition) are splitted into two barlines!! In my opinion (just one un-informed opinion, I'm not an expert) the issue of barlines in MusicXML should be revised. Probably, as with natural languages, representation languages condition what can be easily managed and what can not. And probably the problem of 'barline alignment' that you mention and I still not see, is something related to the MusicXML barlines model. MusicXML relies on using the concept of 'measure' for organizing music. But this is a derived concept: a measure is just what is inside between two barlines. Therefore, barlines is all what is needed. The program can determine, if necessary, what is the content for a given measure. Many music notation programs are organized in the same way, around measures. Therefore, they need tricks for dealing, for instance, with music with no time signatures, typically non-visible barlines. Or, as you mention, they need tricks for dealing with music not ended in a barline.

In my software, the music internal model does not need the concept of 'measure' as a primary concept and I do not find problems for aligning barlines, for dealing with multimetric music, for dealing with music without time signatures or for dealing with music without a final barline. But I do find problems for exporting MusicXML barlines: when should I export a barline as left barline or as right barline? when a barline is non-controllig? Must I artificially split a repetition barline into a left and a rigt barline?

If the suppression of the 'non-controlling' attribute could cause barline alignment problems or other, please close this issue. But in that case I would appreciate clear rules for exporting this attribute. In Don Giovanni example there is only one part in 2/4 time signature, but if there were more, then all the barlines in parts in 2/4 must go aligned! Should the non-controlling attribute still be used?:

• If yes, how to represent that the non-controlling attribute relates olny to parts not in 2/4 but that these non-controlling barlines must go aligned with other left barlines in parts in 2/4?
• If no, this implies that the software can deal properly with multi-metric without using this attribute!

MusicXML has done a great job by facilitating not only a good de-facto standard for interchanging music between notation applications, but also for grouping around its forum and working groups all the people interested in music notation representation. Thank you!!!

Best regards,
Cecilio

[BJungmann]

The music internal model of capella does not need the concept of 'measure' as a primary concept, either. But Finale's and Sibelius' do, and so does MusicXML's model. There may be measures that are not filled completely in some voice or staff, but no barline is generated there. So MusicXML needs the extra hint "non-controlling". If your software is different in that respect, it should easily be able to encode and display such multi metric things. And it should be possible for you to support the non-controlling attribute for exchange.
Of course this is not quite trivial, and the world wide range of stakeholders and customers for this feature is small. But if you want to do more work on that, I can give you some support. E.g. the capella export is done with a python script CapToMusic.py, open source. You can get it from the capella demo version, or directly from http://bjungmann.privat.t-online.de/CapToMusic.zip. But I warn you: It is long and more complicated than I had expected when I started with it! For further details contact me off list at bjungmann@t-online.de.

[cecilios]

Thank you Bernd. I very much appreciate your help. But for now I'm going to forget about exporting non-controlling attribute, as I have more important issues to solve.

Nevertheless, I still believe that for a future web standard this attribute should be reviewed.

Best regards,
Cecilio Salmeron
s.cecilio@gmail.com

[mdgood]

Thank you for raising this issue. I agree that barlines in MusicXML 3.0 could use some work. Issue #104 for instance covers just one of the points that you made. However, I think a broader look at barline representation is better suited for MNX than for MusicXML 3.1, given the compatibility constraints on MusicXML 3.1.

I do believe that the non-controlling attribute is needed to signal non-aligned barlines in multi-metric music. In other types of multi-metric music you can have different time signatures with aligned barlines. Something has to signal that the barlines are not aligned. The non-controlling attribute is MusicXML 3.0's way of doing that, though as you note it is not complete.

If someone has a proposal for enhancing the non-controlling attribute to work better in MusicXML 3.1, please let us know.

[cecilios]

Hi Michael,

In issue #115 I proposed to suppress this attribute and give some reasons.
I would like to hear about refutations of my arguments:

For me, non-controlling attribute is just a clue for the algorithm to break
music into systems, for signalling that non-controlling barlines are not a
proper point for a break. With this interpretation:

• The non-controlling attribute just signals a point in which a system
  break should not be placed. And, this seems arbitrary: why to signal just
  one point and not all the points where breaks should not be placed? If the
  intent is to signal were the breaks should be, it is simpler to export the
  system breaks. MusicXML can provide explicit information about line breaks
  and page breaks, so use it. No need for 'clues'. If the music parts have
  time signature, breaks should be placed at common barlines to all parts;
  thus, the non-controlling attribute is irrelevant. If some or all parts do
  not have time signature, break points are more difficult to compute, but
  again, the non-controlling attribute is irrelevant for this.

It should be expected that line-break algorithms are prepared for breaking
lines at barlines, but also line-break algorithms should naturally deal
with music with no barlines at all, without relaying on more tricks
(non-visible barlines). And multi-metric music is just an intermediate case
between both, in which breaks should be allowed only at barlines common to
all parts.

• As the non-controlling attribute is not mandatory, any MusicXML importer
  must be prepared for dealing with non-controlling barlines even when they
  are not marked as such. Therefore, when the non-controlling attribute is
  present it is quite useless!
• You say that "something has to signal that the barlines are not aligned".
  Again, why not to signal that other elements are not aligned? Music is
  aligned by time. A barline that doesn't coincide in time with other
  barlines is necessarily non-controlling, just as a consequence of how the
  music was created. No need for an explicit marker.
• To me, what is behind the non-controlling attribute is an specific
  approach for managing multi-metric music, and thus, the non-controlling
  attribute (as the backup and forward elements) are reminiscences of a
  procedural language. MusicXML should be freed of these 'procedural'
  elements and attributes, and move to a clear declarative language.

And if my interpretation is wrong and the 'non-controlling' concept is more
than explicitly signalling easily deducible information from barlines
alignment in time, then the concept needs clarification. Probably, it is a
new concept: 'hints' for algorithms? If this is the case, the
non-controlling attribute opens the door for demanding more 'hints': why
hints for line break and not for other tasks?

Hope this helps,
Cecilio Salmeron

On Wed, Sep 21, 2016 at 2:17 AM, Michael Good notifications@github.com
wrote:

Thank you for raising this issue. I agree that barlines in MusicXML 3.0
could use some work. Issue #104
#104 for instance covers just one
of the points that you made. However, I think a broader look at barline
representation is better suited for MNX than for MusicXML 3.1, given the
compatibility constraints on MusicXML 3.1.

I do believe that the non-controlling attribute is needed to signal
non-aligned barlines in multi-metric music. In other types of multi-metric
music you can have different time signatures with aligned barlines.
Something has to signal that the barlines are not aligned. The
non-controlling attribute is MusicXML 3.0's way of doing that, though as
you note it is not complete.

If someone has a proposal for enhancing the non-controlling attribute to
work better in MusicXML 3.1, please let us know.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_vl2mib1y1UDr7YlY96oN3eymrV-ZBks5qsHeOgaJpZM4HEbTU
.

[mdgood]

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not related to system breaks. System breaks are handled with the print element and its new-system attribute, which can indeed be placed anywhere within the flow of music data. The print and sound elements are indeed hints for layout and performance algorithms, as are many element attributes for display and playback.

No MusicXML software handles everything in the MusicXML format. A great many features are optional, based on the principles of selective encoding. This does not make them useless. A feature like profiles, proposed as part of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like parts, they are a fundamental way of organizing music. In by far the most common case in common Western music notation, measures and barlines are aligned between parts. It makes sense to explicitly signal when this is not the case, as in multi-metric music where measures and barlines are not aligned between parts. The non-controlling attribute conveys musical semantics. This information is not easily deducible from other semantic MusicXML data. As you have pointed out, this could be done in a more comprehensive way, but we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling attribute, as it is used by applications like capella for just the purposes that it was intended. We are not making incompatible changes to MusicXML 3.1, though such changes may well be made for MNX.

[cecilios]

Michael, many thanks for the explanation.

But excuse me, I still do not understand the purpose of the non-controlling
attribute. I would appreciate your help for understanding its purpose.

You mention that some applications use the non-controlling attribute for
the purposes that it was intended. What is that purpose? Again I can only
think on not breaking the system in those barlines. It is useless for play
back, for harmonic analysis or for other tasks.

You say that "it covers musical semantics, as measures and barlines are
aligned between parts and, therefore, it makes sense to explicitly signal
when this is not the case, as in multi-metric music". But IMHO the only
semantics a barline provides is to signal the end of a measure. If a
barline is aligned or not is only of interest for layout (correct me if
this is not the case, please). In fact the word 'aligned' implies layout!
Therefore, if the purpose is to signal that a barline is not aligned, IMHO
this is a layout hint that is only of interest for system breaks.

A different issue is backwards MusicXML compatibility. But I'm making
proposals for MNX.

On Wed, Sep 21, 2016 at 6:10 PM, Michael Good notifications@github.com
wrote:

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not related
to system breaks. System breaks are handled with the print element and its
new-system attribute, which can indeed be placed anywhere within the flow
of music data. The print and sound elements are indeed hints for layout and
performance algorithms, as are many element attributes for display and
playback.

No MusicXML software handles everything in the MusicXML format. A great
many features are optional, based on the principles of selective encoding.
This does not make them useless. A feature like profiles, proposed as part
of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like parts, they
are a fundamental way of organizing music. In by far the most common case
in common Western music notation, measures and barlines are aligned between
parts. It makes sense to explicitly signal when this is not the case, as in
multi-metric music where measures and barlines are not aligned between
parts. The non-controlling attribute conveys musical semantics. This
information is not easily deducible from other semantic MusicXML data. As
you have pointed out, this could be done in a more comprehensive way, but
we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling attribute,
as it is used by applications like capella for just the purposes that it
was intended. We are not making incompatible changes to MusicXML 3.1,
though such changes may well be made for MNX.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_vl6ygv2fgCRnQWAB-WhUHVRbaGLMvks5qsVbbgaJpZM4HEbTU
.

[BJungmann]

Hi Cecilio,

in this context, "a barline is aligned" means that the barline
corresponds to the same playback time in every part. My MusicXML
importer will insert invisible rests, if a barline is encountered in
some part, and the measure is not yet full, i.e. not as long as in some
other part. It will not do that, if the non-controlling attribute is found.

Hope this helps,
Bernd
Am 21.09.2016 um 19:48 schrieb Cecilio Salmeron:

Michael, many thanks for the explanation.

But excuse me, I still do not understand the purpose of the
non-controlling
attribute. I would appreciate your help for understanding its purpose.

You mention that some applications use the non-controlling attribute for
the purposes that it was intended. What is that purpose? Again I can only
think on not breaking the system in those barlines. It is useless for play
back, for harmonic analysis or for other tasks.

You say that "it covers musical semantics, as measures and barlines are
aligned between parts and, therefore, it makes sense to explicitly signal
when this is not the case, as in multi-metric music". But IMHO the only
semantics a barline provides is to signal the end of a measure. If a
barline is aligned or not is only of interest for layout (correct me if
this is not the case, please). In fact the word 'aligned' implies layout!
Therefore, if the purpose is to signal that a barline is not aligned, IMHO
this is a layout hint that is only of interest for system breaks.

A different issue is backwards MusicXML compatibility. But I'm making
proposals for MNX.

On Wed, Sep 21, 2016 at 6:10 PM, Michael Good notifications@github.com
wrote:

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not related
to system breaks. System breaks are handled with the print element
and its
new-system attribute, which can indeed be placed anywhere within the
flow
of music data. The print and sound elements are indeed hints for
layout and
performance algorithms, as are many element attributes for display and
playback.

No MusicXML software handles everything in the MusicXML format. A great
many features are optional, based on the principles of selective
encoding.
This does not make them useless. A feature like profiles, proposed
as part
of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like parts, they
are a fundamental way of organizing music. In by far the most common
case
in common Western music notation, measures and barlines are aligned
between
parts. It makes sense to explicitly signal when this is not the
case, as in
multi-metric music where measures and barlines are not aligned between
parts. The non-controlling attribute conveys musical semantics. This
information is not easily deducible from other semantic MusicXML
data. As
you have pointed out, this could be done in a more comprehensive
way, but
we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling
attribute,
as it is used by applications like capella for just the purposes that it
was intended. We are not making incompatible changes to MusicXML 3.1,
though such changes may well be made for MNX.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute
the thread

https://github.com/notifications/unsubscribe-auth/AE_vl6ygv2fgCRnQWAB-WhUHVRbaGLMvks5qsVbbgaJpZM4HEbTU
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AP73uhexwuGPk7aDm-HlqD2qFoXwBgFTks5qsW4IgaJpZM4HEbTU.

[cecilios]

Thanks Bernd,

I appreciate very much your answers.

My understanding of the 'non-controlling' meaning is also what you say: '"a
barline is aligned" means that the barline corresponds to [barlines in] the
same playback time in every part". non-controlling := this barline is not
synced. with barlines in all parts

With this meaning, my point is that the attribute is not necessary, as it
is trivial to deduce if at a given play back time, at which a barline is
encountered in one part, there are barlines in all parts at the same play
back time. This is the same kind of check that I assume it is necessary to
do for aligning other objects, i.e. notes. I assume that for layout and
playback, any application has to order the objects in time wise order.

You say that your MusicXML importer "insert invisible rests, if a barline
is encountered in some part, and the measure is not yet full, i.e. not as
long as in some other part. It will not do that, if the non-controlling
attribute is found". If I understand correctly, this introduces a new
meaning for the non-controlling attribute: "if not present and the measure
that finishes in current barline is shorter than other measures, this
measure is not yet full; for layout and play back some space/silence need
to be inserted so that the barline is correctly positioned at end of
measure". Thus, this interpretation considers non-controlling attribute a
way for dealing with uncompleted measures in normal scores (not necessarily
for multi-metric scores) and for not considering 'uncompleted' some
measures in multi-metric music. Notice that if we define non-controlling :=
measure full but shorter than measures in other parts, then all barlines in
2/3 part of Don Giovani would be wrongly non-controlling!

Even for dealing with un-completed measures, I don't see the need of this
attribute as it is trivial to deduce if a barline is not full: if measure
duration < duration implied by time signature.

All this just creates me more confusion about the meaning of this
attribute. In multi-metric music non-controlling barlines are just barlines
not alligned with barlines in all parts, but not incomplete measures.And
the definition of this attribute in MusicXML documentation says nothing
about uncompleted measures.

Clearly, there is something I'm missing. I'm really confused. What is
really the semantics or meaning of "non-controlling"? Barline not synced.
with barlines in all parts? Full measure but shorter that measures in other
parts? non-controlling what? Playback? Layout? System breaks?
a-very-specific-algorithm in MuseData?

My main points are:

• The meaning of this attribute is not clear and open to interpretations.
  Until now, I have not found a clear definition, including the definition in
  MusicXML documentation.
• The attribute is not-mandatory. Therefore applications consuming MusicXML
  can not only rely on this attribute for any task, as it is not mandatory.
  If my application exports MusicXML without this attribute (it is just a
  hint and no real music content), it will be the importer application fault
  if the file is not represented (layout, playback or other) reasonably well,
  as it would be the case with other other optional information (i.e.
  positioning). Unless 'optional' for this non-controlling attribute has a
  new meaning "optional for value 'no' but mandatory for value 'yes'".

I don't like to argue and really I don't mind if this attribute is dropped
or will remain in MNX. I'd just tried to give my point of view just in case
it could be useful, and I will not continue arguing. Everybody seem to
agree on the need of this non-controlling attribute and seem to understand
it. I'm feeling like I'm missing some trivial point. But that's life! I
just would appreciate a clear definition of this attribute in MusicXML (and
in MNX).

Thank you Bernd.

Regards,
Cecilio

On Thu, Sep 22, 2016 at 3:33 PM, BJungmann notifications@github.com wrote:

Hi Cecilio,

in this context, "a barline is aligned" means that the barline
corresponds to the same playback time in every part. My MusicXML
importer will insert invisible rests, if a barline is encountered in
some part, and the measure is not yet full, i.e. not as long as in some
other part. It will not do that, if the non-controlling attribute is found.

Hope this helps,
Bernd

Am 21.09.2016 um 19:48 schrieb Cecilio Salmeron:

Michael, many thanks for the explanation.

But excuse me, I still do not understand the purpose of the
non-controlling
attribute. I would appreciate your help for understanding its purpose.

You mention that some applications use the non-controlling attribute for
the purposes that it was intended. What is that purpose? Again I can only
think on not breaking the system in those barlines. It is useless for
play
back, for harmonic analysis or for other tasks.

You say that "it covers musical semantics, as measures and barlines are
aligned between parts and, therefore, it makes sense to explicitly signal
when this is not the case, as in multi-metric music". But IMHO the only
semantics a barline provides is to signal the end of a measure. If a
barline is aligned or not is only of interest for layout (correct me if
this is not the case, please). In fact the word 'aligned' implies layout!
Therefore, if the purpose is to signal that a barline is not aligned,
IMHO
this is a layout hint that is only of interest for system breaks.

A different issue is backwards MusicXML compatibility. But I'm making
proposals for MNX.

On Wed, Sep 21, 2016 at 6:10 PM, Michael Good notifications@github.com
wrote:

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not
related
to system breaks. System breaks are handled with the print element
and its
new-system attribute, which can indeed be placed anywhere within the
flow
of music data. The print and sound elements are indeed hints for
layout and
performance algorithms, as are many element attributes for display and
playback.

No MusicXML software handles everything in the MusicXML format. A great
many features are optional, based on the principles of selective
encoding.
This does not make them useless. A feature like profiles, proposed
as part
of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like parts, they
are a fundamental way of organizing music. In by far the most common
case
in common Western music notation, measures and barlines are aligned
between
parts. It makes sense to explicitly signal when this is not the
case, as in
multi-metric music where measures and barlines are not aligned between
parts. The non-controlling attribute conveys musical semantics. This
information is not easily deducible from other semantic MusicXML
data. As
you have pointed out, this could be done in a more comprehensive
way, but
we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling
attribute,
as it is used by applications like capella for just the purposes that
it
was intended. We are not making incompatible changes to MusicXML 3.1,
though such changes may well be made for MNX.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute
the thread

<https://github.com/notifications/unsubscribe-auth/AE_vl6ygv2fgCRnQWAB-
WhUHVRbaGLMvks5qsVbbgaJpZM4HEbTU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AP73uhexwuGPk7aDm-
HlqD2qFoXwBgFTks5qsW4IgaJpZM4HEbTU>.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_vl-UhSlokXvj6Z-RfvBmGiIOJvVw_ks5qsoONgaJpZM4HEbTU
.

[BJungmann]

I agree with you that the non-controlling attribute is more a hardly
sufficient patch than an elegant solution for the needs of multi-metric
music. But at the time it was introduced, I did not succeed in finding a
better definition for this either, without changing MusicXML compatibility.

Sorry this won't really help,
Bernd
Am 22.09.2016 um 17:32 schrieb Cecilio Salmeron:

Thanks Bernd,

I appreciate very much your answers.

My understanding of the 'non-controlling' meaning is also what you
say: '"a
barline is aligned" means that the barline corresponds to [barlines
in] the
same playback time in every part". non-controlling := this barline is not
synced. with barlines in all parts

With this meaning, my point is that the attribute is not necessary, as it
is trivial to deduce if at a given play back time, at which a barline is
encountered in one part, there are barlines in all parts at the same play
back time. This is the same kind of check that I assume it is necessary to
do for aligning other objects, i.e. notes. I assume that for layout and
playback, any application has to order the objects in time wise order.

You say that your MusicXML importer "insert invisible rests, if a barline
is encountered in some part, and the measure is not yet full, i.e. not as
long as in some other part. It will not do that, if the non-controlling
attribute is found". If I understand correctly, this introduces a new
meaning for the non-controlling attribute: "if not present and the measure
that finishes in current barline is shorter than other measures, this
measure is not yet full; for layout and play back some space/silence need
to be inserted so that the barline is correctly positioned at end of
measure". Thus, this interpretation considers non-controlling attribute a
way for dealing with uncompleted measures in normal scores (not
necessarily
for multi-metric scores) and for not considering 'uncompleted' some
measures in multi-metric music. Notice that if we define
non-controlling :=
measure full but shorter than measures in other parts, then all
barlines in
2/3 part of Don Giovani would be wrongly non-controlling!

Even for dealing with un-completed measures, I don't see the need of this
attribute as it is trivial to deduce if a barline is not full: if measure
duration < duration implied by time signature.

All this just creates me more confusion about the meaning of this
attribute. In multi-metric music non-controlling barlines are just
barlines
not alligned with barlines in all parts, but not incomplete measures.And
the definition of this attribute in MusicXML documentation says nothing
about uncompleted measures.

Clearly, there is something I'm missing. I'm really confused. What is
really the semantics or meaning of "non-controlling"? Barline not synced.
with barlines in all parts? Full measure but shorter that measures in
other
parts? non-controlling what? Playback? Layout? System breaks?
a-very-specific-algorithm in MuseData?

My main points are:

• The meaning of this attribute is not clear and open to interpretations.
  Until now, I have not found a clear definition, including the
  definition in
  MusicXML documentation.
• The attribute is not-mandatory. Therefore applications consuming
  MusicXML
  can not only rely on this attribute for any task, as it is not mandatory.
  If my application exports MusicXML without this attribute (it is just a
  hint and no real music content), it will be the importer application fault
  if the file is not represented (layout, playback or other) reasonably
  well,
  as it would be the case with other other optional information (i.e.
  positioning). Unless 'optional' for this non-controlling attribute has a
  new meaning "optional for value 'no' but mandatory for value 'yes'".

I don't like to argue and really I don't mind if this attribute is dropped
or will remain in MNX. I'd just tried to give my point of view just in
case
it could be useful, and I will not continue arguing. Everybody seem to
agree on the need of this non-controlling attribute and seem to understand
it. I'm feeling like I'm missing some trivial point. But that's life! I
just would appreciate a clear definition of this attribute in MusicXML
(and
in MNX).

Thank you Bernd.

Regards,
Cecilio

On Thu, Sep 22, 2016 at 3:33 PM, BJungmann notifications@github.com
wrote:

Hi Cecilio,

in this context, "a barline is aligned" means that the barline
corresponds to the same playback time in every part. My MusicXML
importer will insert invisible rests, if a barline is encountered in
some part, and the measure is not yet full, i.e. not as long as in some
other part. It will not do that, if the non-controlling attribute is
found.

Hope this helps,
Bernd

Am 21.09.2016 um 19:48 schrieb Cecilio Salmeron:

Michael, many thanks for the explanation.

But excuse me, I still do not understand the purpose of the
non-controlling
attribute. I would appreciate your help for understanding its purpose.

You mention that some applications use the non-controlling
attribute for
the purposes that it was intended. What is that purpose? Again I
can only
think on not breaking the system in those barlines. It is useless for
play
back, for harmonic analysis or for other tasks.

You say that "it covers musical semantics, as measures and
barlines are
aligned between parts and, therefore, it makes sense to explicitly
signal
when this is not the case, as in multi-metric music". But IMHO the
only
semantics a barline provides is to signal the end of a measure. If a
barline is aligned or not is only of interest for layout (correct
me if
this is not the case, please). In fact the word 'aligned' implies
layout!
Therefore, if the purpose is to signal that a barline is not aligned,
IMHO
this is a layout hint that is only of interest for system breaks.

A different issue is backwards MusicXML compatibility. But I'm making
proposals for MNX.

On Wed, Sep 21, 2016 at 6:10 PM, Michael Good
notifications@github.com
wrote:

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not
related
to system breaks. System breaks are handled with the print element
and its
new-system attribute, which can indeed be placed anywhere within the
flow
of music data. The print and sound elements are indeed hints for
layout and
performance algorithms, as are many element attributes for
display and
playback.

No MusicXML software handles everything in the MusicXML format.
A great
many features are optional, based on the principles of selective
encoding.
This does not make them useless. A feature like profiles, proposed
as part
of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like
parts, they
are a fundamental way of organizing music. In by far the most common
case
in common Western music notation, measures and barlines are aligned
between
parts. It makes sense to explicitly signal when this is not the
case, as in
multi-metric music where measures and barlines are not aligned
between
parts. The non-controlling attribute conveys musical semantics. This
information is not easily deducible from other semantic MusicXML
data. As
you have pointed out, this could be done in a more comprehensive
way, but
we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling
attribute,
as it is used by applications like capella for just the purposes
that
it
was intended. We are not making incompatible changes to MusicXML
3.1,
though such changes may well be made for MNX.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute
the thread

<https://github.com/notifications/unsubscribe-auth/AE_vl6ygv2fgCRnQWAB-
WhUHVRbaGLMvks5qsVbbgaJpZM4HEbTU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AP73uhexwuGPk7aDm-
HlqD2qFoXwBgFTks5qsW4IgaJpZM4HEbTU>.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute
the thread

https://github.com/notifications/unsubscribe-auth/AE_vl-UhSlokXvj6Z-RfvBmGiIOJvVw_ks5qsoONgaJpZM4HEbTU
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AP73utAY8PfHi1InwXQrQXLk20NUtMRwks5qsp-VgaJpZM4HEbTU.

[Glenn-smufl]

On 9/22/2016 8:32 AM, Cecilio Salmeron wrote:

My main points are:

• The meaning of this attribute is not clear and open to interpretations.
  Until now, I have not found a clear definition, including the definition in
  MusicXML documentation.
• The attribute is not-mandatory. Therefore applications consuming MusicXML
  can not only rely on this attribute for any task, as it is not mandatory.
  If my application exports MusicXML without this attribute (it is just a
  hint and no real music content), it will be the importer application fault
  if the file is not represented (layout, playback or other) reasonably well,
  as it would be the case with other other optional information (i.e.
  positioning). Unless 'optional' for this non-controlling attribute has a
  new meaning "optional for value 'no' but mandatory for value 'yes'".

I don't like to argue and really I don't mind if this attribute is dropped
or will remain in MNX. I'd just tried to give my point of view just in case
it could be useful, and I will not continue arguing. Everybody seem to
agree on the need of this non-controlling attribute and seem to understand
it. I'm feeling like I'm missing some trivial point. But that's life! I
just would appreciate a clear definition of this attribute in MusicXML (and
in MNX).

Some notation applications that use the non-controlling attribute,
because they are dealing with mixed metric music, may wish to assist the
composer/notator with cross-checks that bar lines that should be aligned
(that do not have the non-controlling attribute) are, and bar lines that
shouldn't, or need not, be aligned, all have the non-controlling attribute.

Deducing it from the music in the other staves does not allow such
cross-checking.

Of course, I don't know of any particular music or notation program that
does such, I'm only speaking theoretically, to the potential usefulness
of such a feature.

Yes, it could be lost across notation programs, and one that imports a
file into a "cross-checking" notation programs, might have to do manual
labor to reinstate the attribute in appropriate places, in order to
benefit from the cross-checking.

Glenn

[cecilios]

Anyway, thank you Bern.

On Thu, Sep 22, 2016 at 5:55 PM, BJungmann notifications@github.com wrote:

I agree with you that the non-controlling attribute is more a hardly
sufficient patch than an elegant solution for the needs of multi-metric
music. But at the time it was introduced, I did not succeed in finding a
better definition for this either, without changing MusicXML compatibility.

Sorry this won't really help,
Bernd
Am 22.09.2016 um 17:32 schrieb Cecilio Salmeron:

Thanks Bernd,

I appreciate very much your answers.

My understanding of the 'non-controlling' meaning is also what you
say: '"a
barline is aligned" means that the barline corresponds to [barlines
in] the
same playback time in every part". non-controlling := this barline is
not
synced. with barlines in all parts

With this meaning, my point is that the attribute is not necessary, as it
is trivial to deduce if at a given play back time, at which a barline is
encountered in one part, there are barlines in all parts at the same play
back time. This is the same kind of check that I assume it is necessary
to
do for aligning other objects, i.e. notes. I assume that for layout and
playback, any application has to order the objects in time wise order.

You say that your MusicXML importer "insert invisible rests, if a
barline
is encountered in some part, and the measure is not yet full, i.e. not as
long as in some other part. It will not do that, if the non-controlling
attribute is found". If I understand correctly, this introduces a new

meaning for the non-controlling attribute: "if not present and the
measure
that finishes in current barline is shorter than other measures, this
measure is not yet full; for layout and play back some space/silence need
to be inserted so that the barline is correctly positioned at end of
measure". Thus, this interpretation considers non-controlling attribute a
way for dealing with uncompleted measures in normal scores (not
necessarily
for multi-metric scores) and for not considering 'uncompleted' some
measures in multi-metric music. Notice that if we define
non-controlling :=
measure full but shorter than measures in other parts, then all
barlines in
2/3 part of Don Giovani would be wrongly non-controlling!

Even for dealing with un-completed measures, I don't see the need of this
attribute as it is trivial to deduce if a barline is not full: if measure
duration < duration implied by time signature.

All this just creates me more confusion about the meaning of this
attribute. In multi-metric music non-controlling barlines are just
barlines
not alligned with barlines in all parts, but not incomplete measures.And
the definition of this attribute in MusicXML documentation says nothing
about uncompleted measures.

Clearly, there is something I'm missing. I'm really confused. What is
really the semantics or meaning of "non-controlling"? Barline not synced.
with barlines in all parts? Full measure but shorter that measures in
other
parts? non-controlling what? Playback? Layout? System breaks?
a-very-specific-algorithm in MuseData?

My main points are:

• The meaning of this attribute is not clear and open to interpretations.
  Until now, I have not found a clear definition, including the
  definition in
  MusicXML documentation.
• The attribute is not-mandatory. Therefore applications consuming
  MusicXML
  can not only rely on this attribute for any task, as it is not mandatory.
  If my application exports MusicXML without this attribute (it is just a
  hint and no real music content), it will be the importer application
  fault
  if the file is not represented (layout, playback or other) reasonably
  well,
  as it would be the case with other other optional information (i.e.
  positioning). Unless 'optional' for this non-controlling attribute has a
  new meaning "optional for value 'no' but mandatory for value 'yes'".

I don't like to argue and really I don't mind if this attribute is
dropped
or will remain in MNX. I'd just tried to give my point of view just in
case
it could be useful, and I will not continue arguing. Everybody seem to
agree on the need of this non-controlling attribute and seem to
understand
it. I'm feeling like I'm missing some trivial point. But that's life! I
just would appreciate a clear definition of this attribute in MusicXML
(and
in MNX).

Thank you Bernd.

Regards,
Cecilio

On Thu, Sep 22, 2016 at 3:33 PM, BJungmann notifications@github.com
wrote:

Hi Cecilio,

in this context, "a barline is aligned" means that the barline
corresponds to the same playback time in every part. My MusicXML
importer will insert invisible rests, if a barline is encountered in
some part, and the measure is not yet full, i.e. not as long as in some
other part. It will not do that, if the non-controlling attribute is
found.

Hope this helps,
Bernd

Am 21.09.2016 um 19:48 schrieb Cecilio Salmeron:

Michael, many thanks for the explanation.

But excuse me, I still do not understand the purpose of the
non-controlling
attribute. I would appreciate your help for understanding its
purpose.

You mention that some applications use the non-controlling
attribute for
the purposes that it was intended. What is that purpose? Again I
can only
think on not breaking the system in those barlines. It is useless for
play
back, for harmonic analysis or for other tasks.

You say that "it covers musical semantics, as measures and
barlines are
aligned between parts and, therefore, it makes sense to explicitly
signal
when this is not the case, as in multi-metric music". But IMHO the
only
semantics a barline provides is to signal the end of a measure. If a
barline is aligned or not is only of interest for layout (correct
me if
this is not the case, please). In fact the word 'aligned' implies
layout!
Therefore, if the purpose is to signal that a barline is not aligned,
IMHO
this is a layout hint that is only of interest for system breaks.

A different issue is backwards MusicXML compatibility. But I'm making
proposals for MNX.

On Wed, Sep 21, 2016 at 6:10 PM, Michael Good
notifications@github.com
wrote:

Hello Cecilio,

As Bernd explained earlier, the non-controlling attribute is not
related
to system breaks. System breaks are handled with the print element
and its
new-system attribute, which can indeed be placed anywhere within
the
flow
of music data. The print and sound elements are indeed hints for
layout and
performance algorithms, as are many element attributes for
display and
playback.

No MusicXML software handles everything in the MusicXML format.
A great
many features are optional, based on the principles of selective
encoding.
This does not make them useless. A feature like profiles, proposed
as part
of MNX, can make this flexibility easier for software to manage.

Measures and barlines are special in MusicXML because, like
parts, they
are a fundamental way of organizing music. In by far the most
common
case
in common Western music notation, measures and barlines are aligned
between
parts. It makes sense to explicitly signal when this is not the
case, as in
multi-metric music where measures and barlines are not aligned
between
parts. The non-controlling attribute conveys musical semantics.
This
information is not easily deducible from other semantic MusicXML
data. As
you have pointed out, this could be done in a more comprehensive
way, but
we need a proposal to consider in order to do that.

For MusicXML 3.1 we will not be eliminating the non-controlling
attribute,
as it is used by applications like capella for just the purposes
that
it
was intended. We are not making incompatible changes to MusicXML
3.1,
though such changes may well be made for MNX.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#115 (comment)
,
or mute
the thread

<https://github.com/notifications/unsubscribe-auth/AE_vl6ygv2fgCRnQWAB-
WhUHVRbaGLMvks5qsVbbgaJpZM4HEbTU>

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AP73uhexwuGPk7aDm-
HlqD2qFoXwBgFTks5qsW4IgaJpZM4HEbTU>.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute
the thread

<https://github.com/notifications/unsubscribe-auth/AE_vl-UhSlokXvj6Z-
RfvBmGiIOJvVw_ks5qsoONgaJpZM4HEbTU>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#115 (comment),
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AP73utAY8PfHi1InwXQrQXLk20NUtMRwks5qsp-VgaJpZM4HEbTU>.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_vl6qFzXwBoA1ur8cURtwoOBMEJ7joks5qsqT2gaJpZM4HEbTU
.

[cecilios]

Hi Glenn,
I agree that the only utility is for cross-checking when present, without
solving anything. But applications can not relay on its existence and this
creates inconsistency problems in cross checking when not present. Better
remove it or make it mandatory.

Regards,
Cecilio

On Thu, Sep 22, 2016 at 7:14 PM, Glenn-smufl notifications@github.com
wrote:

On 9/22/2016 8:32 AM, Cecilio Salmeron wrote:

My main points are:

• The meaning of this attribute is not clear and open to interpretations.
  Until now, I have not found a clear definition, including the definition
  in
  MusicXML documentation.
• The attribute is not-mandatory. Therefore applications consuming
  MusicXML
  can not only rely on this attribute for any task, as it is not mandatory.
  If my application exports MusicXML without this attribute (it is just a
  hint and no real music content), it will be the importer application
  fault
  if the file is not represented (layout, playback or other) reasonably
  well,
  as it would be the case with other other optional information (i.e.
  positioning). Unless 'optional' for this non-controlling attribute has a
  new meaning "optional for value 'no' but mandatory for value 'yes'".

I don't like to argue and really I don't mind if this attribute is
dropped
or will remain in MNX. I'd just tried to give my point of view just in
case
it could be useful, and I will not continue arguing. Everybody seem to
agree on the need of this non-controlling attribute and seem to
understand
it. I'm feeling like I'm missing some trivial point. But that's life! I
just would appreciate a clear definition of this attribute in MusicXML
(and
in MNX).

Some notation applications that use the non-controlling attribute,
because they are dealing with mixed metric music, may wish to assist the
composer/notator with cross-checks that bar lines that should be aligned
(that do not have the non-controlling attribute) are, and bar lines that
shouldn't, or need not, be aligned, all have the non-controlling attribute.

Deducing it from the music in the other staves does not allow such
cross-checking.

Of course, I don't know of any particular music or notation program that
does such, I'm only speaking theoretically, to the potential usefulness
of such a feature.

Yes, it could be lost across notation programs, and one that imports a
file into a "cross-checking" notation programs, might have to do manual
labor to reinstate the attribute in appropriate places, in order to
benefit from the cross-checking.

Glenn

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#115 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE_vl8amQJJeAUbHnO7PI7qI017sM_Ezks5qsrdpgaJpZM4HEbTU
.

[mdgood]

I am closing this issue. A general multi-metric music question is already included as part of MNX issue 143.