Improve means of describing secondary beam groups

[cecilios]

I would appreciate clarifications or an example of the utility of the valueattribute in <beamed> elements. As I understand, in beamed groups the value of the group is implied by the sum of values of the contained events.

One example from the draft: two child beamed groups of four 32nd notes each, which are in turn placed within a higher-parent beamed group:

	---------------------------------------------------------
	-------------------------	-------------------------
	|	|	|	|	|	|	|	|
	o	o	o	o	o	o	o	o

<beamed>
  <beamed value="/8">
    <event value="/32">...</event>
    <event value="/32">...</event>
    <event value="/32">...</event>
    <event value="/32">...</event>
  </beamed>
  <beamed value="/8">
    <event value="/32">...</event>
    <event value="/32">...</event>
    <event value="/32">...</event>
    <event value="/32">...</event>
  </beamed>
</beamed>

The first <beamed> element has no value. And the second one has value='\8' (an eight note); this value is, effectively the sum of the four 32th contained events. Why the need to encode <beamed value="/8">?

In the description it says that "the value attribute optionally gives the base note value to be assigned to the child group for beaming purposes.". And "The value attribute does not affect beaming within a beamed group, and so has no consequences unless beamed groups are nested." But what are those consequences? The example has nested beamed groups and the value attribute is not used.

My apologies if I have missed something here. The only utility a can see is, perhaps, in tuplets of beamed notes, but in these cases I understand that it is the <tuplet> element the one that will provide the value of the beamed groups and not the <beamed> element. E.g: (i'm not sure if I've place the right inner/outer numbers):

                                        3
	-----------------------------------------------------------------
	-----------------	-----------------	-----------------
	|	|	|	|	|	|	|	|	|
	o	o	o	o	o	o	o	o	o
                3                       3                       3

 <tuplet inner="3/8" outer="1/4">
	<beamed>
 		<tuplet inner="3/16" outer="1/8">
			<beamed>
				<event value="/32">...</event>
				<event value="/32">...</event>
				<event value="/32">...</event>
			</beamed>
		<tuplet>
 		<tuplet inner="3/16" outer="1/8">
			<beamed>
				<event value="/32">...</event>
				<event value="/32">...</event>
				<event value="/32">...</event>
			</beamed>
		<tuplet>
 		<tuplet inner="3/16" outer="1/8">
			<beamed>
				<event value="/32">...</event>
				<event value="/32">...</event>
				<event value="/32">...</event>
			</beamed>
		<tuplet>
	</beamed>
<tuplet>

I would appreciate any help for understanding the utility of the 'value' attribute. Thank you.

[joeberkovitz]

Two points here. And they're both open to further discussion, I just want to expose the thinking more clearly.

1. There are some cases where the beaming level can be ambiguous, and so it's desirable to give the engraver some control.

For instance, take two groups of three 32nd notes (neither of which are tuplets). Each group is beamed (with 3 lines, of course), but there is also a beam connecting the two beamed groups. A case could be made either way that the higher-level beam has 1 line ("rounding up" each group to the value of an 8th note) or has 2 lines ("rounding down" each group to the value of a 16th note).

2. In general MNX tries to put less burden on consumer implementations to examine the content of a container and make inferences. More stuff is explicit in the markup, and this makes developers' lives easier.

[cecilios]

Thank you very much for the explanation.

Just a couple of thoughts (nothing to object to current proposal, just two ideas):

1. To put less burden on consumer implementations perhaps it would be better to make the 'value' attribute mandatory so that not to have to do inferences in any case.

2. Another alternative (requiring doing inferences but avoiding ambiguities) could be to interpret that the <beamed> element supplies just one beam line and the contained events values the remaining beam lines (if any), then the 'value' attribute would not be necessary for your example; if higher-level beam has 1 line this would be encoded as two beamed levels:

<beamed>
	<beamed>
		<event value="/64">
		<event value="/64">
		<event value="/64">
	</beamed>
	<beamed>
		<event value="/64">
		<event value="/64">
		<event value="/64">
	</beamed>
</beamed>

And if it has 2 lines then it will have three beamed levels:

<beamed>
	<beamed>
		<beamed>
			<event value="/64">
			<event value="/64">
			<event value="/64">
		</beamed>
		<beamed>
			<event value="/64">
			<event value="/64">
			<event value="/64">
		</beamed>
	</beamed>
</beamed>

[adrianholovaty]

Closing this in favor of #299.