Problem processing Humdrum mensural data

craigsapp commented 10 months ago

Commit baf8d5939783b22356a3f2c15c3be046ce8ce61a generates a problem with Humdrum mensural data. Starting with this commit, the following data generates a segmentation fault:

**mens
*clefC3
Lc
*-

Prior to this commit, the same data will be rendered as expected without a segmentation fault:

And generates the following MEI data:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.0">
 <meiHead>
  <fileDesc>
   <titleStmt>
    <title />
   </titleStmt>
   <pubStmt />
  </fileDesc>
  <encodingDesc>
   <appInfo>
    <application isodate="2023-12-01T01:11:46" version="4.1.0-dev-fbc82ac">
     <name>Verovio</name>
     <p>Transcoded from Humdrum</p>
    </application>
   </appInfo>
  </encodingDesc>
  <workList>
   <work>
    <title />
   </work>
  </workList>
 </meiHead>
 <music>
  <body>
   <mdiv xml:id="mp7h2jo">
    <score xml:id="s87fen0">
     <scoreDef xml:id="s1lve27n" midi.bpm="400.000000">
      <staffGrp xml:id="si97bg4">
       <staffDef xml:id="staffdef-L1F1" n="1" notationtype="mensural.white" lines="5">
        <clef xml:id="clef-L2F1" shape="C" line="3" />
       </staffDef>
      </staffGrp>
     </scoreDef>
     <section xml:id="section-L1F1">
      <staff xml:id="staff-L1F1" n="1">
       <layer xml:id="layer-L1F1N1" n="1">
        <note xml:id="note-L3F1" dur="longa" oct="4" pname="c" />
       </layer>
      </staff>
     </section>
    </score>
   </mdiv>
  </body>
 </music>
</mei>

The above MEI data does not generate a segmentation fault.

Here is a stack trace when loading Humdrum mensural data in this commit:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   vrv::Object::operator=(vrv::Object const&) + 152
1   vrv::ScoreDef::operator=(vrv::ScoreDef const&) + 24
2   non-virtual thunk to vrv::ScoreDefSetCurrentFunctor::VisitPage(vrv::Page*) + 60
3   vrv::Object::Process(vrv::Functor&, int, bool) + 76
4   vrv::Object::Process(vrv::Functor&, int, bool) + 256
5   vrv::Object::Process(vrv::Functor&, int, bool) + 256
6   vrv::Doc::ScoreDefSetCurrentDoc(bool) + 140
7   vrv::Doc::ConvertToCastOffMensuralDoc(bool) + 96
8   vrv::HumdrumInput::convertHumdrum() + 5036
9   vrv::HumdrumInput::Import(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 684
10  vrv::Toolkit::LoadData(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 1076
11  vrv::Toolkit::LoadFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 424
12  main + 5000
13  start + 2236

It looks like something is no longer set properly in the scoreDef after loading Humdrum mensural data. So perhaps there are function(s) that are needed to be called after the conversion of mensural data that is not being done (similar things have happened in the past).

lpugin commented 9 months ago

@DavidBauer1984 I am going to look at it, but maybe you have an idea?

lpugin commented 9 months ago

I made this fix. A call to Doc::PrepareData is now necessary to gather visible scores. Nothing wrong with this but it would be good to have a clear idea what the call dependencies are.

brdvd commented 9 months ago

Yes, this call looks a bit odd. I will have a deeper look into this in the next days.

rism-digital / verovio

Problem processing Humdrum mensural data #3553