[MusicXML] import assumes beam=NONE if no beam information

• Oct 15, 2014 - 21:54
Type
Functional
Severity
S4 - Minor
Status
active
Regression
No
Workaround
No
Project
Tags

9f15fa3269

Apparently the import process assumes no beam at all if there is no beam information in the score. It leads to some weird results out of the box. Like with this file from Notion 4 http://musescore.org/sites/musescore.org/files/test%20croches%20XML.xml

Maybe MuseScore could assume autobeam instead?


Comments

@lvinken Do you see any problem in making the default setting for beam to be AUTO? In your experience, the absence of any beam instruction in Sib/Fin means no beam at all?

No really easy answer here.

The files in my sample collection that were created by Finale, Sibelius with Dolet or Sibelius with direct export all contains beam information. This implies that a missing beam element probably really means "no beam". Sibelius 7.1.3 (direct export) even explicitly states it supports beams (supports element="beam" type="yes" /). Not that Finale (at least in Recordares samples) does not write a "supports beam".

Other applications mostly seem to write beam information, but I do not have sufficient samples to be conclusive. Most applications do not write a "supports beam", so you can seldom be sure what missing beam info means.

I do believe that for Finale, Sibelius with Dolet or Sibelius with direct export the absence of any beam instruction really means no beam at all, in which case AUTO is incorrect. This may not be true for other applications or older files.

@lasconic, no update on this one for more than two months. Do you still want to change anything ? Setting beam AUTO on all notes without beams might result in slightly different beaming compared to what Finale or Sibelius does, but in improved handling of files without any beams, such as your example.

Note that setting all notes to auto beamed is as easy as selecting all notes and double clicking "auto" in the beam palette. I do realize this is something that may not be self-explanatory.

I have no wrong opinion either way. The current trunk behavior seems "more correct" but possibly less user friendly.

I did notice that beams were assumed auto by version 1.3 and none by version 3.0 - I will search for the XML to correct this - but if anyone knows, please let me know. Thanks
Bob MacDonald
@drmacdonald

Bob, what exactly would you like to know ?

MuseScore's MusicXML behavior was changed after 1.3 as it seemed to me to better handle the files generated by our major competitors. See reply #2 for the explanation.

Note that the MusicXML specification is unclear on this subject. It does not state that a beamed note must have one or more beam elements, nor what the absence of a beam element means.

My application reads external data from tanach.us and produces a file in musicxml from the cantillation accents in the text. I looked in the XML help but couldn't find where to code beam=none. I expect I would have to treat it like slur and code the individual notes with begin, continue, end or such like. It's feasible but a tiny nuisance at the moment.

It is easy enough to select all and double click auto. I can do that if I were creating a score from the xml, say with an English as well as an automated Hebrew lyric line. I suspect no one is reading my scores much anyway. Most students of the texts I am investigating are tone deaf or they read the accents as punctuation. If anyone is interested in the automated reading of the text and production of music, my work area with several hundred examples is here - https://drive.google.com/folderview?id=0BzkrfxErEx0Ca3lzQ1ZkMktROTg&usp…

You should specify the beams with begin, continue, end on the first note of each chord.

If you leave out the beam information, the importing program may decide how to interpret that (no beams or automatic beams).

on the first note of each chord

So you mean it is quite different from slurs which I only specify for duplets and triplets. A chord would not have a beam if it was in quarter notes. The begin /continue / end would not be meaningful in that context.

I think I may not understand you. The context of beam is note and they would only apply to eighth notes or lesser. If I put a start beam on a note that was a quarter note and never ended it would that be an error? And would it auto beam every eight note group from then on? That seems odd.

The context of slur is notations under note - and it has only start and stop attributes.

While I'm on these questions, does Musescore support a dotted slur - for things like folksongs where the word underlay may vary but the words are not explicitly in the lyrics lines.

Thanks again for the conversation

In reply to by Leon Vinken

I think this is correct only if the imported file does not specify that it gives beam information, i.e. does not state

supports element="beam" type="yes"

If it specifies so, in contrast, the absence of a beam specification must be interpreted as "no beam", since there is no other way to specify the absence of a beam, AFAIK.