Comments (9)
axelberndt
commented on August 20, 2024
The supplied environment was not the problem. Your accid elements do not provide attributes oloc and ploc. So they are taken from the parent note and here something went wrong. It should be fixed with meico version 0.3.4. Could you test it on your data? Thanks.
from meico.
TillReininghaus
commented on August 20, 2024
Sorry for reopening this issue again, but in the recent MEICO version I have found the following bug. In encodings with the child elements <supplied><accid/></supplied> which reference to with @oct.ges, the element is obviously not recognized correctly by Meico and therefore played incorrectly (in the example Mozart, String Quartet K. 589, mvt 1, m. 30: "e flat" instead of "e").
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei meiversion="4.0.0" xmlns="http://www.music-encoding.org/ns/mei">
<meiHead>
<fileDesc>
<titleStmt>
<title>example K. 589/1, m. 30, Vc - note with @oct.ges and supplied accid</title>
</titleStmt>
<pubStmt/>
</fileDesc>
</meiHead>
<music>
<body>
<mdiv n="1">
<score>
<scoreDef key.accid="f" key.mode="major" key.pname="b" key.sig="2f" meter.count="3" meter.unit="4" optimize="false">
<staffGrp bar.thru="true" symbol="bracket">
<staffDef clef.line="4" clef.shape="F" lines="5" n="1"/>
</staffGrp>
</scoreDef>
<section>
<measure n="28">
<staff n="1">
<layer n="1">
<mRest tstamp="1" xml:id="mRest_9906"/>
<clef line="2" shape="G" tstamp="3.5" xml:id="clef_9912"/>
</layer>
</staff>
</measure>
<measure n="29">
<staff n="1">
<layer n="1" xml:id="layer_10062">
<note dur="4" oct="5" oct.ges="4" pname="c" tstamp="1" xml:id="note_10068"/>
<note accid="n" dur="4" oct="5" oct.ges="4" pname="e" tstamp="2" xml:id="note_10074"/>
<note dur="4" oct="5" oct.ges="4" pname="g" tstamp="3" xml:id="note_10080"/>
</layer>
</staff>
</measure>
<measure n="30">
<staff n="1">
<layer n="1" xml:id="layer_10242">
<note accid.ges="f" dur="2" oct="5" oct.ges="4" pname="b" tstamp="1" xml:id="note_10248"/>
<beam xml:id="beam_10254">
<note dur="8" oct="5" oct.ges="4" pname="g" tstamp="3" xml:id="note_10260"/>
<note color="red" dur="8" oct="5" oct.ges="4" pname="e" tstamp="3.5" xml:id="note_10266">
<supplied xml:id="supplied_10266">
<accid accid="n" xml:id="accid_10266"/>
</supplied>
</note>
</beam>
</layer>
</staff>
</measure>
<measure n="31">
<staff n="1">
<layer n="1" xml:id="layer_10488">
<note dur="4" oct="5" oct.ges="4" pname="f" tstamp="1" xml:id="note_10494"/>
<rest dur="4" tstamp="2" xml:id="rest_10500"/>
<rest dur="4" tstamp="3" xml:id="rest_10506"/>
</layer>
</staff>
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>
from meico.
axelberndt
commented on August 20, 2024
Thanks for reporting the bug. I will look into it.
from meico.
axelberndt
commented on August 20, 2024
Found the problem. This is a typical MEI ambiguity situation, basically a mishmash of information from the graphical and gestural domain where meico has to make the most reasonable choice, even though counter-intuitive at first glance.
When processing the <accid>, meico looks at the parent to determine the pitch and octave which the <accid> is aplied to. In this case, there is an oct="5" and an oct.ges="4". Since the <accid> is (in MEI) a graphical domain element, meico chooses the @oct to assign the accidental to an octave, thus staying consistent with this domain. It would take the @oct.ges only in the absence of @oct as a fallback.
In other words, as <accid> comes from the graphical domain meico first tries to stay consistent within this domain when processing it. Within this domain, the <accid> belongs to oct="5". However, when computing the performed pitch of the note, meico prioritizes the gestural domain which means that the <note> is at oct.ges="4". But there is nothing telling meico, that there is an accidental at this octave level or that the graphical <accid> should also be applied to this gestural octave level.
MEI-wise the semantically correct encoding for this case would be to add accid.ges="n" to the <note>.
from meico.
axelberndt
commented on August 20, 2024
Hm, ... I keep thinking about it. What I might do is, that such an accidental can propagate up to the <note> and put in an @accid. Then, meico would play this <note> with the accidental but subsequent notes will ignore it for the reason explained above. Is this a desired behavior? This needs discussion.
from meico.
ndubo
commented on August 20, 2024
@axelberndt, I think, you outlined the solution already. MEICO could simply take the information in all <accid> and process them internally as @accid (and ignore the <supplied> anyway). Yes, this is the desired behavior. In my opinion, however, the reasoning behind it is a different one. The coding of the alteration with the element <accid> (as a child element to <note>) is equivalent to the coding with the attribute @accid in <note> (second note in m. 29). In order to be able to address the alteration (in this case it is necessary because it is added by means of the element <supplied>), the coding with <accid> was the only choice for the red note. From a semantic or logical viewpoint, there is no difference; and the coding with <accid> has nothing to do with the graphical domain. Most importantly, <accid> is a child element to <note>, it descibes a property of the note. As such it does not need to have an @oct assigned.
BTW, as a background information to the example given by @TillReininghaus . This is what some people call a “false treble clef” which is often found in cello parts. The section in the treble clef is supposed to sound an octave lower than notated. In MEI, this can easily be expressed through @oct=”x” plus @oct.ges=”x-1”. Thus for the acoustic output, MEICO should always allow to overwrite @oct by @oct.ges.
from meico.
axelberndt
commented on August 20, 2024
I have implemented this and tested it. ... Basically, it works in your case BUT the following will sooner or later happen. Therefor, you have to keep in mind that <note> will propagate the accidental throughout the whole measure.
- Subsequent notes on the same gestural pitch and in the same measure will not take notice of the accidental because it is specified for a different pitch.
- Subsequent notes on that other pitch will take notice of the accidental an be altered.
What I did so far was keeping the ambiguous <accid> out of the game. But now, once I propagate it to the parent note's @accid, it is in, with all the consequences.
By the way, the same happens with the regular <note> elements' @accid attributes when they are masked by @accid.ges. You have an accidental in play that alters subsequent notes even though the note where it comes in plays on another pitch than it is printed.
I am surprised that no one stumbled over this, yet. With this new change, however, it becomes more likely to happen. Before I make a new release I would like to hear some opinions.
from meico.
kepper
commented on August 20, 2024
Having been asked on separate channels to comment on this, I don't really see the problem of propagation. If someone supplies @*.ges, I believe it's safe to assume that this has been done consistently – if a subsequent note is supposed to be affected by an accidental, octave shift, whatever, it will carry the required @*.ges attributes as well. I believe it would be an extremely bad habit to use those attributes only occasionally, and someone doing that should not expect software to correctly guess the meaning of her or his encodings. From what I read, meico currently tries to carry over logic required for processing a purely graphical encoding over to one which also has gestural information – which I think is already a step too far. I doubt that any solution in this territory can really satisfy everyone, while strictly sticking to values provided by @*.ges is a very easy position to explain and defend. Just a first thought, though…
from meico.
axelberndt
commented on August 20, 2024
Alright, thanks Till for reporting the issue and thanks Norbert and Johannes for your opinions, as always very plausible and convincing. The new release version is online.
from meico.
Related Issues (20)
- File names with capital extensions
- Add XSLT interface to window mode HOT 1
- Default choices for variant HOT 2
- New GUI HOT 1
- MEI coverage documentation HOT 1
- Expansions
- Support for MusicXML format HOT 1
- Use meico like a library to convert midi HOT 1
- Support for @sameas HOT 3
- command line utility does not work with v0.8.0 HOT 1
- Error initializing QuantumRenderer: no suitable pipeline found HOT 2
- Compatibilty with android HOT 1
- Recognition of the instruments HOT 2
- Portato HOT 2
- App cannot be launched HOT 5
- Arpeggio direction in MEI-to-MPM export
- Negative Timing in Performance Rendering
- meicoApp.jar doesn't work with openjdk HOT 11
- MSM resolve repetitions duplicates xml:ids
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from meico.