Figured bass figures are not attached to the correct point

[ahankinson]

From rism-digital/verovio#2533

The problem seems to come from the fact that all harm/fb are having a @startid="#m-121", which means they are all positioned under the same note. Also, there are some empty fb, which do not make sense. Removing them and using only tstamp without @startid fixes the issue

Tagging @vivianteresa for visibility on this.

[th-we]

Can we have a sample Sibelius file?

[vivianteresa]

Here are links to the Sibelius files in my repository: File 1 (Long) and File 2 (Short).. The first file (the "long version") has the whole song that I've transcribed; the second file (the "short version") has just the section with the figured bass figures in question. (The figures only end up colliding / not being attached to the correct point when I export the file into MEI.) I should also say that, with the help of the Verovio team, I was able to adjust the MEI code so that the figures don't collide.

[th-we]

Thanks, @vivianteresa! I see the output @tstamps are correct, but the @startid does not make sense. You could solve that problem by stripping all the @startids from the <harm> elements, e.g. with a small XSLT.

The empty <fb> are however due to empty text objects that are present in the Sibelius file. We might want to ignore those when exporting. I'll create issue #193 for that.

The attachment problem brings up the bigger question if we should just omit @startids whenever elements are not perfectly attached to a note or rest. That would however also mean that objects that are slightly off would not get a @startid. Opinions?

figbass-attachment.sib.zip

[ahankinson]

I think this is the code that attaches objects to the closest note:

sibmei/src/Utilities.mss

Lines 216 to 278 in e6bd3aa

	function GetNoteObjectAtPosition (bobj) {
	//$module(Utilities.mss)
	// takes a bar object, and returns the NoteRest object closest to its position.
	// If one isn't found exactly at the end position, it will first look back (previous)
	// and then look forward, for candidate objects.
	voice_num = bobj.VoiceNumber;
	if (voice_num = 0)
	{
	// Things like titles or composer text needn't/shouldn't be attached to
	// voices or notes.
	return null;
	}
	objectPositions = Self._property:ObjectPositions;
	staff_num = bobj.ParentBar.ParentStaff.StaffNum;
	bar_num = bobj.ParentBar.BarNumber;
	staffObjectPositions = objectPositions[staff_num];
	barObjectPositions = staffObjectPositions[bar_num];
	voiceObjectPositions = barObjectPositions[voice_num];
	if (voiceObjectPositions = null)
	{
	// theres not much we can do here. Bail.
	Log('Bailing due to insufficient voice information');
	return null;
	}
	if (voiceObjectPositions.PropertyExists(bobj.Position))
	{
	obj_id = voiceObjectPositions[bobj.Position];
	obj = libmei.getElementById(obj_id);
	return obj;
	}
	else
	{
	// if we can't find anything at this position,
	// find the previous and subsequent objects, and align the
	// lyrics with them.
	next_obj = bobj.NextItem(voice_num, 'NoteRest');
	if (next_obj != null)
	{
	obj_id = voiceObjectPositions[next_obj.Position];
	obj = libmei.getElementById(obj_id);
	return obj;
	}
	else
	{
	prev_obj = bobj.PreviousItem(voice_num, 'NoteRest');
	if (prev_obj != null)
	{
	// there should be an object registered here
	obj_id = voiceObjectPositions[prev_obj.Position];
	obj = libmei.getElementById(obj_id);
	return obj;
	}
	}
	}
	return null;
	} //$end

It was added because quite a few things are placed visually, and not tied to any particular note event even though they affect a note event. Things like slurs, trills, and certain other symbols. Syllables are perhaps the most important thing:

sibmei/src/ExportProcessors.mss

Line 309 in e6bd3aa

obj = GetNoteObjectAtPosition(syl);

This is generally applied with a bunch of other attributes in the AddControlEventAttributes function:

sibmei/src/Utilities.mss

Line 280 in e6bd3aa

function AddControlEventAttributes (bobj, element) {

I wouldn't necessarily omit @startids whenever any element is not perfectly attached to a note, but perhaps only some things can take @tstamp values with no @startid.

For figured bass, however, am I right in understanding that the figure underneath does apply to the note on the staff? In which case we should probably store some sort of pointer to it.

What about something using @corresp like:

<harm xml:id="m-122" staff="2" corresp="#m-121" tstamp="1.000000" ho="2.1328mm" layer="1">
  <fb xml:id="m-123">
    <f xml:id="m-124" n="1">♭6</f>
    <f xml:id="m-125" n="2">5</f>
  </fb>
</harm>

This would contain a link to #m-121, but also Verovio would then (I believe) fall back to using @tstamp for placing the items.

Would that work?

[th-we]

I wouldn't necessarily omit @startids whenever any element is not perfectly attached to a note, but perhaps only some things can take @tstamp values with no @startid.

As long as we can find good rules for where to omit @startid if there's no precise attachment I'm all for it. Dynamics/hairpins for example. For some other items it may be more difficult to decide, though. Take fermatas. They usually only make sense when they are attached to a NoteRest but they could also be placed above a barline.

For figured bass, however, am I right in understanding that the figure underneath does apply to the note on the staff? In which case we should probably store some sort of pointer to it.

What about something using @corresp like:

<harm xml:id="m-122" staff="2" corresp="#m-121" tstamp="1.000000" ho="2.1328mm" layer="1">
  <fb xml:id="m-123">
    <f xml:id="m-124" n="1">♭6</f>
    <f xml:id="m-125" n="2">5</f>
  </fb>
</harm>

Oh, good point. I like the idea of using @corresp instead of @startid for figured bass. A figure without an associated bass note does not make a lot of sense after all.