text:
dots missing on mRest

Is there any reason why <mRest> is missing in att.augmentdots?

Centered full-measure rests are not supposed to have augmentation dots.

meaning <mRest> is only one specific symbol? Even in 3/8 meter? And @dots is a visual attribute? Then why is it available on <space> and <mSpace>? And <bTrem>? And <fing>, and <harm>, and <tuplet>?

meaning  is only one specific symbol? Even in 3/8 meter?

Yes, especially in 3/8:

Putting a dot on the whole-measure centered rests (mRest) or making them a dotted-quarter rest in this case would be a serious offense to CMN.
An exception would be for meters equal or greater than 8/4, where a whole-measure rests looks stupid if using a whole rest, so a breve rest should be used.  And by extension meters equal or greater than 16/4 should use a long rest, and equal or greater than 32/4 should use a maxima rest (and 64/4 and higher should use a double maxima rest, but now things are getting silly).

And @dots is a visual attribute?

@dots seem to have a dual purpose of being visual and modifying the @dur of elements.  Are these functions separable in MEI?  In other words, how is the visual dot supposed to be hidden on a dotted half note?

So actually the real reason for the lack of @dots is that  <mRest> is supposed to receive its duration from the prevailing time signature, and it does not contain the duration within itself.  <mRest> should also exclude @dur, but I see it listed:
http://music-encoding.org/documentation/3.0.0/mRest
so I would have a counter-issue complaining that @dur should be removed since @dur and @dots should always be linked together in their inclusion or exclusion from an element.
This is contrary to <space> which does contain duration, and by extension requires @dots.  Notice that <space>, <note>, <rest> and other durational elements cannot represent all durations.  For example, how should a duration of 11 eighth notes be represented?   As far as I have been able to figure out it is impossible to do that in MEI, and therefore a <space> cannot have a duration of 11 eighth notes and must be split into multiple <space> which add up to 11 eighth notes (which by the way is why <space> is really an invisible rest, @kepper).  So regular rests cannot fully represent as a single element in every possible meter duration.
Here is an example of music in 11/8:

Notice that it is impossible to have a single note representing a sustained note filling a measure in 11/8, so it must be split into two notes added together with a tie.   Similarly there is no single rest which represents 11 eighths notes, so the <mRest> could not be assigned a correct duration even if @dots were allowed.
MEI test data:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="3.0.0">
    <meiHead>
        <fileDesc>
            <titleStmt>
                <title />
            </titleStmt>
            <pubStmt />
        </fileDesc>
        <encodingDesc>
            <appInfo>
                <application isodate="2017-04-24T11:10:57" version="0.9.14-dev-98874c6">
                    <name>Verovio</name>

Transcoded from Humdrum

                </application>
            </appInfo>
        </encodingDesc>
        <workDesc>
            <work>
                <titleStmt>
                    <title />
                </titleStmt>
            </work>
        </workDesc>
    </meiHead>
    <music>

            <mdiv>
                <score>
                    <scoreDef xml:id="scoredef-0000001194634597">
                        <staffGrp xml:id="staffgrp-0000001503258451">
                            <staffDef xml:id="staffdef-0000000102767551" n="1" clef.shape="G" clef.line="2" meter.count="11" meter.unit="8" lines="5" />
                        </staffGrp>
                    </scoreDef>

                        <measure xml:id="measure-L3" n="1" type="m-1">
                            <staff xml:id="staff-L3F1N1" n="1">
                                <layer xml:id="layer-L3F1N1" n="1">
                                    <note xml:id="note-L4F1" type="qon-0 qoff-4 pname-c acc-n oct-4 b40c-2 b12c-0  tie-start" dur="1" oct="4" pname="c">
                                        <accid xml:id="accid-L4F1" accid.ges="n" />
                                    </note>
                                    <note xml:id="note-L5F1" type="qon-4 qoff-11_2 pname-c acc-n oct-4 b40c-2 b12c-0  tie-stop" dots="1" dur="4" oct="4" pname="c">
                                        <accid xml:id="accid-L5F1" accid.ges="n" />
                                    </note>
                                </layer>
                            </staff>
                            <tie xml:id="tie-L4F1-L5F1" startid="#note-L4F1" endid="#note-L5F1" />
                        </measure>
                        <measure xml:id="measure-L6" n="2" type="m-2">
                            <staff xml:id="staff-L6F1N1" n="1">
                                <layer xml:id="layer-L6F1N1" n="1">
                                    <mRest xml:id="mrest-0000001150793255" />
                                </layer>
                            </staff>
                        </measure>
                        <measure xml:id="measure-L8" n="3" right="end" type="m-3">
                            <staff xml:id="staff-L8F1N1" n="1">
                                <layer xml:id="layer-L8F1N1" n="1">
                                    <note xml:id="note-L9F1" type="qon-11 qoff-15 pname-c acc-n oct-4 b40c-2 b12c-0  tie-start" dur="1" oct="4" pname="c">
                                        <accid xml:id="accid-L9F1" accid.ges="n" />
                                    </note>
                                    <note xml:id="note-L10F1" type="qon-15 qoff-33_2 pname-c acc-n oct-4 b40c-2 b12c-0  tie-stop" dots="1" dur="4" oct="4" pname="c">
                                        <accid xml:id="accid-L10F1" accid.ges="n" />
                                    </note>
                                </layer>
                            </staff>
                            <tie xml:id="tie-L9F1-L10F1" startid="#note-L9F1" endid="#note-L10F1" />
                        </measure>

                </score>
            </mdiv>

    </music>
</mei>

So actually the real reason for the lack of @dots is that  is supposed to receive its duration from the prevailing time signature, and it does not contain the duration within itself.  should also exclude @dur

Precisely, <mRest> is time signature dependent.  And, yes, @dur shouldn't be allowed.

This is contrary to  which does contain duration, and by extension requires @dots. Notice that <space>, <note>, <rest> and other durational elements cannot represent all durations. For example, how should a duration of 11 eighth notes be represented? As far as I have been able to figure out it is impossible to do that in MEI, and therefore a <space> cannot have a duration of 11 eighth notes and must be split into multiple  which add up to 11 eighth notes (which by the way is why <space> is really an invisible rest, @kepper). So regular rests cannot fully represent as a single element in every possible meter duration.

Again, spot on (except for the invisible rest part, 😀 ).  But this is a limitation within CMN, which MEI simply mimics.

I guess @rettinghaus is coming from examples typical for Bach, where he writes a whole rest in one measure, and then an augmentation dot in the following. While this is not the way we would handle it nowadays, it's perfectly valid for CMN of his period, and, luckily, MEI allows to encode that in a much better way than using @dots: Use the <dot> element in the following measure. Otherwise you'd have to offset everything in there with spaces, and you would end up with a pretty messy encoding.
I think I don't have to comment on all the other aspects in here ;-)

Bach, where he writes a whole rest in one measure, and then an augmentation dot in the following.

That is a different situation, is it not?  In 4/4 that would indicate a rest with 6 quarter notes duration, but the dotted part of the duration is in the next measure.  And that sort of notation was also applied to notes:

The whole note rest still gets its duration from the meter, and the augmentation dot adds half of whatever that is.

It's not that I want to have a (visual) dot on mRest. I just wanted to point out the ambiguity of @dots and that there is something mixed up with att.duration.additive, att.duration.musical, and att.augmentdots.
It simply makes no sense to have @dots on mSpace but not on mRest.
I'm ok with dropping @dur from mRest, but then this should apply to mSpace, too.
If @dur is to stay, then mRest and mSpace should be part of att.duration.additive.
And elements that are part of att.duration.additive already must not be part of att.augmentdots, e.g. <annot> and <fing>.

@rettinghaus, I think we are on the same page then. Yes, @dots should go away from <mRest>. And in order to bring up something even more scary when thinking about "strict" rules of CMN, here's a snippet from Schütz' Matthäuspassion:

How do you solve that one, @craigsapp and @pe-ro ?

That is a funny one with a barline splitting a notehead.
A general problem is what is meant by CMN, with "C" meaning common?  Is splitting the note in half by a barline something a publisher would do, or is it something that it a shorthand for writing the score out by hand (save time to not write out a separate note and draw a tie)?  I wonder what would happen if there were a quarter note in the bottom staff on the last beat of the first measure?  Would that cause the notation of the measure-split note to change?  It would have to be moved to the left to align with the quarter note... And would the performance parts do the same thing?
Barlines had just been invented, and people were experimenting with their syntax, so this is a now extinct transitional species.  Are there any tied notes in the manuscript? I presume that tied notes had been invented by the time this was written, but it would be interesting if not.
Another thing would be the flat in the bottom key signature.  Notice that it splits the clef symbol in half.  Should that be encoded?

Here is how I would do it in SCORE:

This turned out to be moderately easy.    To split the notehead by the barline, I added a horizontal offset to the notehead to place it on the barline.   The dot is represented by a note object that has no stem or notehead, just an augmentation dot and a duration of a quarter note.  In theory I could have attached the dot to the previous note, but in SCORE there is a maximum dot displacement which is slightly less than I wanted, so I had to detach it from the owning note.
The main complication is that you cannot do LJ (line-up and justify for horizontal spacing) with the barline going through a note, even if it has an explicit horizontal offset, since SCORE will force them to not collide.  However, I can make the barline only one staff high, then do LJ, and then make it 2 staves high again to get the proper horizontal spacing:

So the main fiddly part is to temporarily change the barline height.
Here is encoding the stem directions and lengths of the original:

In Humdrum I would encode it with a modern syntax of splitting the notes across the barline with ties.  For analyses based on semantics I would not care about the syntax of the notes in this configuration, but I have dealt with a similar situation in JRP:
http://josquin.stanford.edu/cgi-bin/jrp?a=notationEditText&f=Jos0402a

In this case the long in the tenor part is twice as long as those of the other parts.  This is a terminal long, and such a long can last for several measures.  The note is supposed to be held until everyone comes to their final notes, so it functions similar to a fermata in modern notation while the other parts are finishing.
Here is the Humdrum score at that point in the music:
http://josquin.stanford.edu/cgi-bin/jrp?a=humdrum&f=Jos0402a
=62	=62	=62	=62
0.E	[0.el	2c\	2.g/
.	.	1B	.
.	.	.	4f/
.	.	.	2g/
.	.	2A/	1a
.	.	1B	.
.	.	.	2g#i/
=63	=63	=63	=63
0.AAl	0.e]	0.Al	0.al
==	==	==	==
*-	*-	*-	*-
!!!RDF**kern: l=long note in original notation

I add the character "l" to notes which should be displayed as long notes.  This in turn causes all of the attached tied notes (and ties) of the secondary tied notes to be hidden in the rendering of the notation.
For the current example, I would probably do it like this in Humdrum:
**kern	**kern
*clefF4	*clefC4
*k[b-]	*k[b-]
2D	2d
[2B-i	4r
.	[4dN
=	=
4B-]	4d]
4F	4c
2G	2B-
=	=
*-	*-
!!!RDF**kern: i = augmentation dot after barline
!!!RDF**kern: N = notehead on barline

The "i" and the "N" would function similar to "l" in the previous example to instruct the renderer to use a non-modern syntax for those notes.
An advantage of this system is that it is renderable in verovio with my current converter and verovio's current rendering capability:

My converter is also set up to deal with such a representation in a useful way with verovio, where I can highlight the notes in the score that are an exception to current CMN:

I add the text "marked note" to the user signifier definitions, with the default rendering color being red, and then one category is given a green color.
**kern	**kern
*clefF4	*clefC4
*k[b-]	*k[b-]
2D	2d
[2B-i	4r
.	[4dN
=	=
4B-]	4d]
4F	4c
2G	2B-
=	=
*-	*-
!!!RDF**kern: i = augmentation dot after barline, marked note color=lawngreen
!!!RDF**kern: N = notehead on barline, marked note

For encoding in MEI, I leave that up to @per-ro :-)  This is a hierarchy-crossing case which gets messy with tree structures.   Notice that SCORE has no problem with such a case.  Your solution of encoding <dot> works for the augmentation dot (although it is more complicated than the Humdrum solution above).

What if we replaced all invocations of data.DURATION; that is, powers-of-two values, with calls to data.DURATION.additive?  (Actually, it's probably better just to rename data.DURATION.additive to data.DURATION.)  This would put @dur squarely in the logical domain -- <note dur="2."/> is pretty unambiguous.  Then, @dots can become a purely visual domain thing indicating how many augmentation dots are visually present.  Or we can drop @dots entirely and use <dot> children.  Either one provides a clearer separation between the logical and visual domains (though dropping @dots is the clearest).  @dur.ges will continue to be used for the gestural/performance domain.

As this is a pretty huge step, I didn't dare to suggest something like this by myself. But merging data.DURATION and data.DURATION.additive seems like a good idea. And personally I'd like to use <dot>.
I'm just not sure if dropping @dots entirely would be good. Perhaps moving it to the analytical domain for now?

@rettinghaus: I understand your trepidation, but @dots isn't analytical domain material, in my opinion. It would be confusing to find it in MEI.analytical. If we don't want to drop it entirely just yet, then putting it in the visual domain makes the most sense to me.
But, one could still end up with markup like --
<note dur="4.." dots="1"/>

which is confusing at first, especially for those already familiar with MEI.  (After the movement of @dots from the logical to the visual domain, this would indicate that the logical duration is a double-dotted quarter note, but that only 1 dot is actually displayed.)

Another thing to consider is how to easily control the number of dots that events are allowed to have.  Right now, with a separate @dots attribute, one can customize the number of dots pretty easily by modifying the value of data.AUGMENTDOT.

To me, all this feels like we're trying to squeeze too many details into too little room. Also, the proposed change of dur is quite dramatic, I would say. I'm not happy to follow based on the set of arguments on the table right now, even though I'm aware that we have too many different types of durations…

Am 25.04.2017 um 21:42 schrieb pe-ro notifications@github.com:
@rettinghaus: I understand your trepidation, but @dots isn't analytical domain material, in my opinion. It would be confusing to find it in MEI.analytical. If we don't want to drop it entirely just yet, then putting it in the visual domain makes the most sense to me.
But, one could still end up with markup like --

which is confusing at first, especially for those already familiar with MEI. (After the movement of @dots from the logical to the visual domain, this would indicate that the logical duration is a double-dotted quarter note, but that only 1 dot is actually displayed.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Having too many different types of duration is a major problem.  I think this fixes it nicely.
The change is not as big a shift as one might think.  It still leaves logical and visual duration coupled in @dur, it just changes the syntax; that is, collapses @dur + @dots into @dur alone.

This should, in fact, make hand coding easier/better. 😀

It feels like a reminiscence to the good old ASCII days, where one would have to parse different information out of a combined string. I agree having different types of duration is a major problem. It's just I wouldn't start to change on this end…

Am 25.04.2017 um 21:51 schrieb pe-ro notifications@github.com:
Having too many different types of duration is a major problem. I think this fixes it nicely.
The change is not as big a shift as one might think. It still leaves logical and visual duration coupled in @dur, it just changes the syntax; that is, collapses @dur + @dots into @dur alone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Where would you like to change it?

Generally, I agree that attribute value parsing isn't good, but if it makes things simpler (i.e., more easy to understand), then why not?

I don't know right now, and would have to have a deeper look into the issue before being able to give a qualified response. It's just that the duration on notes seems to be the most common one. If there are conflicting definitions, then I would look if we couldn't change the ones that are less frequently used: If there's a solution that breaks only 30% of all existing encodings, that seems preferable over one that breaks 100%, at least from my naive perspective ;-)

Am 25.04.2017 um 21:55 schrieb pe-ro notifications@github.com:
Where would you like to change it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

We've been down the road of breaking everything into multiple attribute values.  The next stage of development is to look for those places where we can reduce the number of attributes even if the result is more complex values.

Breaking existing markup isn't a big deal if we provide a conversion mechanism.

I think all I'm saying is that we should slow down on this a bit, think it over a couple of days, and be sure about the consequences. That change is drastic, and it's not only about breaking compatibility of the encodings, it's also likely to break every existing MEI application (MerMEId being the only exception I can think of…). That seems a lot compared to an uneasiness with the current situation, which might perhaps be addressed by better documentation first. I just don't want to rush into an adventure as big as this one too easily.

Am 25.04.2017 um 21:59 schrieb pe-ro notifications@github.com:
We've been down the road of breaking everything into multiple attribute values. The next stage of development is to look for those places where we can reduce the number of attributes even if the result is more complex values.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

The conversion mechanism is to add the number of dot characters provided in @dots to @dur --
<note dur="4" dots="1"/>

becomes
<note dur="4."/>

4.0 is already going to break existing applications.
You're right, there's no rush to do this.  But, it will hold up getting 4.0 out the door and therefore MEI Basic, because I don't want to release 4.0 without having Basic mostly done.

Then I would table it until we talk about 5.0. Honestly, let's avoid to rush on this. Everyone survived until today with the current situation, and I'm sure no one will die immediately
if we keep it some more months. It's something that should be discussed in person, perhaps at the Hack Day during MEC in Tours…

Am 25.04.2017 um 22:06 schrieb pe-ro notifications@github.com:
4.0 is already going to break existing applications.
You're right, there's no rush to do this. But, it will hold up getting 4.0 out the door and therefore MEI Basic, because I don't want to release 4.0 without having Basic mostly done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

At least we should proceed with the suggestions in https://github.com/music-encoding/music-encoding/issues/429#issuecomment-296931773.

agreed

Please don't change something like this without adequate time for community notice and feedback. I agree that this should wait until 5.0 at the earliest.

Conversion mechanisms are OK for converting data, but breaking changes also break software, and there is no conversion mechanism for that.

All the more reason to put as many breaking changes as possible into a single version.  Parceling them out can feel like death by a thousand cuts.
But, if you want to wait, we'll wait.

We need to give people time to adjust to changes, and understand the reasons for making them. MEI doesn't have the luxury of not bringing lots of people along for the ride now, and making changes to fundamental components, like the representation of durations, is something we need to communicate before, during, and after the change.
Do we really gain that much more by changing this? What sorts of operations does this affect? I know it will affect our ability to do math directly on number-like duration values, for one, which seems like a pretty significant loss of functionality. @dur=2. is not unambiguous if you consider a dot following a number to be a decimal point. There's probably also implications for removing numeric values for dots as well.
I'm with Johannes, that this feels very un-MEI and hearkens back to the string-parsing days. That's fine, but it's not MEI. The "." is really only a useful character because of its shape; an ASCII period is not an indicator that half the preceding value should be added to it.

http://music-encoding.org/documentation/2.1.1/att.duration.additive
http://music-encoding.org/documentation/2.1.1/data.DURATION.additive

When the duration is "irrational", as is sometimes the case with tuplets, multiple space-separated values that add up to the total duration may be used. When dotted values are present, the dots attribute must be ignored.

I would avoid using the word irrational since musical rhythms are mathematically called rational numbers (but that does not stop musicians from using the term irrational for rational numbers :-).  An irrational rhythm would be pi-uplets or the square-root-of-three-uplets.

When dotted values are present, the dots attribute must be ignored.

It does not seem too large of a change due to this sentence: currently when there are dots in @dur[technically no dots currently allowed for regular notes/rests yet], then ignore @dots [they would become visual dots in that case].  But there is a problem with the case where there are visual dots but no logical dots.
What about @dots.vis for visual dots that do not match the rhythmic @dots value? mRest could ignore @dots when calculating visual dots (since an mRest should never have dots).  If dots are wanted on mRest then they would be forced with @dots.vis. Otherwise using @dots.vis="0" on regular rests/notes would suppress display of augmentation dots.  @dots would remain logical dots (always affect the value of @dur), and @dots.vis would indicate visual dots which do not match the value in @dots.
I have come across a few cases of visual dots not matching rhythmic dots in C.P.E. Bach digital scores (but I would have to search my notes for where they are).  But they are very rare (other than for mensural music where augmentation dots are usually invisible :-)

So for this example:

The additive duration of the rest would be something like:
dur="1 4."

or
dur="8 8 8 8 8 16 16 8 8. 16 8 8"

It is a bit of a bother that there are innumerable ways to represent an additive rhythm...
In humdrum I describe that rhythm as the actual sum 8%11 which means 11/8ths of a whole note.  Notice that I call 8%11 a rhythm, and its reciprocal 11/8 a duration (as it is 11/8ths of a whole note duration), analogous to 4 representing a quarter note which is 1/4 (a quarter) of a whole note. MEI calls rhythms durations (i.e., 4 = 1/4).
You could instead modify additive duration representation to represent an actual sum rather than a list of space separated durations with augmentation dots (space-delimited values are way too complex for some programmers who cannot parse strings).  The addition has to be done on the inverse of the rhythms (i.e., as actual durations):
1/1 + 1/4 + 1/2 * 1/4 = 11/8   ==> 8%11

Augmentation dots could then be removed from such a representation since it is purely logical and visual dots are not needed, although you will have to decide if it should allow non-power-of-two rhythmic values before dots are applied .  Also breves would be 1%2 (2/1 whole notes), longs are 1%4 (4 whole notes), and maximas are 1%8 (8 whole notes), at least in modern/imperfect mensurations.
"4." means 3/8ths of a whole note, so in Humdrum **recip representation (recip = reciprocal), this can be also represented by "8%3" without the dot.

Interlude:
In terms of rhythmic reforms, I would be most interested in phasing out variable-unit @tstamps in favor of a constant-unit stamp, such as @qstamp.  In other words in 4/4 meters the units of @tstamps are quarter notes, in 3/8 they are eighth notes.  What are they suppose to be in compound meters such as 2/4+1/8?  Or in Debussy's sunken cathedral prelude where the meter shift unmarked between 6/4 and 3/2? Also identifying the reference rhythmic value of @tstamps for random access to the data is computationally expensive (you have to search backward in the music to find the most recent key signature).  This forces most processing of MEI data to be linear.  Properly extracting measure 382 of some music would require backtracking to the start of the score searching for the more recent meter in order to identify the units that @tstamp refer to in that measure.

The "." is really only a useful character because of its shape; an ASCII period is not an indicator that half the preceding value should be added to it.

That is a good point (as in decimal point).  Computer programmers will first think it is a decimal point and get confused.  Especially since some durational units such as @tstamp can contain floating-point decimals.

I'm with Johannes, that this feels very un-MEI and hearkens back to the string-parsing days.

The good news is that SCORE is purely numeric.  Here is the 11/8 meter represented in SCORE numeric form:
8 1 0 0 0 100
3 1 1.5
18 1 8.999 0 11 8
1 1 18.999 1 10 2 4
5 1 18.999 -0.2 -0.2 35.77 -1.603 -2
1 1 35.766 1 10 0 1.5 0 10
14 1 45.924 1
2 1 49.253 0 -2 0 5.5 0 56.24
14 1 69.352 1
1 1 72.681 1 10 2 4
5 1 72.681 -0.2 -0.2 89.45 -1.603 -2
1 1 89.448 1 10 0 1.5 0 10
14 1 100 1 2

All dots in the above data are decimal points.
This example also reminds me that SCORE has an additive duration representation for text-based user input.  It is basically the spaced rhythms system of MEI additive-durations without the spaces or the dots).  All rhythmic values can be represented by numbers, but the main power-of-two ones have letter abbreviations, and these letter abbreviations can be glued together to form an additive duration:
1 = whole note
w = whole note
4.  == dotted quarter note
q. == dotted quarer note
wqe = whole plus quarter plus eighth (for the dot on the quarter note)

So wqe is the text-based string I typed when entering whole-measure rest in the 11/8 example music.
Likewse, MEI additive durations could exclude dots by expanding them:
1 4. would expand to 1 4 8

@craigsapp:
I like the idea of expanding the dots in an additive duration --

1 4. would expand to 1 4 8

The idea behind making all durations adhere to the additive datatype was to be able to force @dots to record only visual information -- the number of dots (to be) rendered.  Calling it @dots.vis, however, would definitely help to clarify its use.  Making all durations potentially additive also has the effect of putting @dur truly in the logical domain.
Re: qtstamps -- Although it's not called @qstamp, @tstamp.ges can record Humdrum recip values, etc.  Would you have a look there and let me know if it doesn't fit your needs?  We're probably closer to a resolution of this than you think.  It seems to me that mostly we have a terminological problem -- what is currently labelled as being in the gestural domain, you'd prefer to label as logical.
The ultimate goal is to resolve the issues MEI has regarding duration sooner rather than later by employing @dur (using data.DURATION.additive) for "logical" info, @dur.vis + @dots.vis for "visual" info, and @dur.ges for gestural/performance info.

Re: qtstamps -- Although it's not called @qstamp, @tstamp.ges can record Humdrum recip values, etc. Would you have a look there and let me know if it doesn't fit your needs? We're probably closer to a resolution of this than you think. It seems to me that mostly we have a terminological problem -- what is currently labeled as being in the gestural domain, you'd prefer to label as logical.

I don't see this as related to gestural vs. logical.  Here is an illustration of the problem:

In both cases the duration of each measure is the same: (3 quarter notes = 6 eighth notes), and rhythmically in both cases there is a fermata on each eighth note, but the @tstamps for each measure are all different:
        <fermata staff="1" tstamp="1" place="above" />
        <fermata staff="1" tstamp="1.5" place="above" />
        <fermata staff="1" tstamp="2" place="above" />
        <fermata staff="1" tstamp="2.5" place="above" />
        <fermata staff="1" tstamp="3" place="above" />
        <fermata staff="1" tstamp="3.5" place="above" />

versus:
        <fermata staff="1" tstamp="1" place="above" />
        <fermata staff="1" tstamp="2" place="above" />
        <fermata staff="1" tstamp="3" place="above" />
        <fermata staff="1" tstamp="4" place="above" />
        <fermata staff="1" tstamp="5" place="above" />
        <fermata staff="1" tstamp="6" place="above" />

What I am saying is that it seems more logical to have the same time unit for the stamps across all meters (or cases where there are no meters or compound meters):
        <fermata staff="1" qstamp="1" place="above" />
        <fermata staff="1" qstamp="1.5" place="above" />
        <fermata staff="1" qstamp="2" place="above" />
        <fermata staff="1" qstamp="2.5" place="above" />
        <fermata staff="1" qstamp="3" place="above" />
        <fermata staff="1" qstamp="3.5" place="above" />

versus:
        <fermata staff="1" qstamp="1" place="above" />
        <fermata staff="1" qstamp="1.5" place="above" />
        <fermata staff="1" qstamp="2" place="above" />
        <fermata staff="1" qstamp="2.5" place="above" />
        <fermata staff="1" qstamp="3" place="above" />
        <fermata staff="1" qstamp="3.5" place="above" />

Full measure 1:

    <scoreDef>
         <staffGrp>
                <staffDef n="1" clef.shape="G" clef.line="2" meter.count="3" meter.unit="4" lines="5" />
          </staffGrp>
    </scoreDef>
    <measure>
        <staff n="1">
            <layer n="1">
                <beam>
                    <note dur="8" oct="4" pname="e"/>
                    <note dur="8" oct="4" pname="f"/>
                </beam>
                <beam>
                    <note dur="8" oct="4" pname="e"/>
                    <note dur="8" oct="4" pname="f"/>
                </beam>
                <beam>
                    <note dur="8" oct="4" pname="e"/>
                    <note dur="8" oct="4" pname="f"/>
                </beam>
            </layer>
        </staff>
        <fermata staff="1" tstamp="1" place="above" />
        <fermata staff="1" tstamp="1.5" place="above" />
        <fermata staff="1" tstamp="2" place="above" />
        <fermata staff="1" tstamp="2.5" place="above" />
        <fermata staff="1" tstamp="3" place="above" />
        <fermata staff="1" tstamp="3.5" place="above" />
    </measure>

Full measure 2:
    <scoreDef meter.count="6" meter.unit="8" />
    <measure right="end" type="m--1">
        <staff n="1">
            <layer n="1">
                <beam>
                    <note xml:id="note-L12F1" dur="8" oct="4" pname="e"/>
                    <note xml:id="note-L13F1" dur="8" oct="4" pname="f"/>
                    <note xml:id="note-L14F1" dur="8" oct="4" pname="e"/>
                </beam>
                <beam>
                    <note xml:id="note-L15F1" dur="8" oct="4" pname="f"/>
                    <note xml:id="note-L16F1" dur="8" oct="4" pname="e"/>
                    <note xml:id="note-L17F1" dur="8" oct="4" pname="f"/>
                </beam>
            </layer>
        </staff>
        <fermata staff="1" tstamp="1" place="above" />
        <fermata staff="1" tstamp="2" place="above" />
        <fermata staff="1" tstamp="3" place="above" />
        <fermata staff="1" tstamp="4" place="above" />
        <fermata staff="1" tstamp="5" place="above" />
        <fermata staff="1" tstamp="6" place="above" />
    </measure>

Imagine that someone  wants to change the 6/8 meter in:
    <scoreDef meter.count="6" meter.unit="8" />

to 3/4 (either explicitly, or by deleting it and letting the previous meter continue).
Then the @tstamps in measure 2 must be altered:
    <measure right="end" type="m--1">
        <staff n="1">
            <layer n="1">
                <beam>
                    <note xml:id="note-L12F1" dur="8" oct="4" pname="e"/>
                    <note xml:id="note-L13F1" dur="8" oct="4" pname="f"/>
                    <note xml:id="note-L14F1" dur="8" oct="4" pname="e"/>
                </beam>
                <beam>
                    <note xml:id="note-L15F1" dur="8" oct="4" pname="f"/>
                    <note xml:id="note-L16F1" dur="8" oct="4" pname="e"/>
                    <note xml:id="note-L17F1" dur="8" oct="4" pname="f"/>
                </beam>
            </layer>
        </staff>
        <fermata staff="1" tstamp="1" place="above" />
        <fermata staff="1" tstamp="1.5" place="above" />
        <fermata staff="1" tstamp="2" place="above" />
        <fermata staff="1" tstamp="2.5" place="above" />
        <fermata staff="1" tstamp="3" place="above" />
        <fermata staff="1" tstamp="3.5" place="above" />
    </measure>

To go back to the C.P.E. Bach Fantasia in C major (Wq 61/6) that I used for the measure number letters discussion:

What should the @tstamp of the fermata in the last system top staff be?  The measure is technically unmeasured (as often happend in fantasias).  Should the meter of the last metric measure be used (2/4).  But looking at the beaming in the free measure (four eighth-notes beamed together), is fits better with a meter that has "2" on the bottom.

In both cases the duration of each measure is the same: (3 quarter notes = 6 eighth notes)

Not necessarily.  It depends on what remains constant in the change from 3/4 to 6/8. If the 8th notes take the same amount of time in both measures, then the performed duration of the measures is the same.  But, if the quarter note in m. 1 is equal to the dotted quarter note in m. 2, then the performed duration of the measures is different.
MEI currently expects
<fermata staff="1" tstamp.ges="1p" place="above" />
<fermata staff="1" tstamp.ges="2p" place="above" />
<fermata staff="1" tstamp.ges="3p" place="above" />
<fermata staff="1" tstamp.ges="4p" place="above" />
<fermata staff="1" tstamp.ges="5p" place="above" />
<fermata staff="1" tstamp.ges="6p" place="above" />

Other than the trailing "p" (for pulse), which is required because @tstamp.ges allows different values which must be differentiated, this is the same as your example.  If we were to decide that @tstamp.ges should henceforth use only one kind of value, then the "p" could be removed.
But thinking about your example more carefully, I think you're probably right that @tstamp.ges is the wrong label.  Assuming equivalence at the 8th-note level needs a different name -- I have no objection to @qstamp.  I think we still must retain @tstamp for time signature-based input.  Both @tstamp and @qstamp describe the notation.  @tstamp.ges may still be necessary to resolve any conflicts between the notation and its performance.

Not necessarily. It depends on what remains constant in the change from 3/4 to 6/8. If the 8th notes take the same amount of time in both measures, then the performed duration of the measures is the same. But, if the quarter note in m. 1 is equal to the dotted quarter note in m. 2, then the performed duration of the measures is different.

OK to be more precise, they have the same score-time duration of three quarter notes (as you noticed after thinking more carefully :-).
score-time is a symbolic time unit based on rational numbers (integers and fractions)
real-time or performance-type is based on physical measurements of time such as seconds, hours, years, eons.  These values are real numbers rather than rational numbers, such as
@tstamp and @qstamp are durations in score-time (not rhythms such as @dur and humdrum **recip values) and a 3/4 and 6/8 measure have the same duration of 3 quarter notes regardless of the tempo that a performance would realize them in.

But thinking about your example more carefully, I think you're probably right that @tstamp.ges is the wrong label. Assuming equivalence at the 8th-note level needs a different name -- I have no objection to @qstamp. I think we still must retain @tstamp for time signature-based input. Both @tstamp and @qstamp describe the notation. @tstamp.ges may still be necessary to resolve any conflicts between the notation and its performance.

I can see how current @tstamp is useful for hand-encoding, but I don't do much of that :-).  However it is also a bit confusing because 6/8 has two beats of a dotted quarter note.  So if you want to put a fermata on beat 2 in 6/8, the @tstamp has to be set to 4.  This seems just as bad as using @qstamp with a value of 2.5, since a musician would want to use 2 for beat 2.
Adding @qstamp would be nice since it adds no additional complexity for software support of both @tstamp and @qstamp at the same time (@tstamp is the complicated one to support).
How these two interact would have to be defined: does one have precedence over the other if both attributes are given for the same element?  Or should that be marked as invalid syntax or a warning on syntax with schemotrion?  Or should only @tstamp or @qstamp be used exclusively in a given file (i.e., if you are using one in a file, then don't use the other)?

How these two interact would have to be defined: does one have precedence over the other if both attributes are given for the same element? Or should that be marked as invalid syntax or a warning on syntax with schemotrion? Or should only @tstamp or @qstamp be used exclusively in a given file (i.e., if you are using one in a file, then don't use the other)?

It's possible to do any of these using Schematron after consensus is achieved.
We've discussed this before and I don't think we're going to convince each other, but I see no inconsistency in how MEI deals with @tstamp.  If 2/2 has 2 beats, 3/4 has 3 beats, and 5/8 has 5 beats, why is it radical or confusing to assert that 6/8 has 6 beats?  😀

Some example markup using my conception of the new regime--
A whole-measure rest in 11/8:
<mRest tstamp="1" qstamp="1" dur="1 4 8" dots.vis="1"/>

A dotted quarter note:
<note tstamp="1" dur="4 8"/>

The same dotted quarter note captured by a hand-coder:
<note tstamp="1" dur.vis="4" dots.vis="1"/>

The same note with both sets of attributes:
<note tstamp="1" qstamp="1" dur="4 8" dur.vis="4" dots.vis="1"/>

@tstamp indicates the starting point in terms of the time signature
@qstamp records a non time signature based starting point
@dur holds the duration as a set of values to be added together; dotted values aren't allowed
@dots is renamed to @dots.vis and is an indication of how many dots actually appear; it no longer plays any role in determining the logical or gestural/performed duration.
@dur.ges is untouched by this proposal but may be modified in the future.

It would be useful to also add @dur.vis to capture the written duration when it differs from the so-called "logical" duration.  In this example, @dur.vis could be set to 1 to represent a whole-note rest.  Using @tstamp, @dur.vis, and @dots.vis, hand coders can continue in much the same way they have before.  One advantage of the change is that it makes a clearer separation between the logical and visual realms.
As @craigsapp suggests, Schematron can be added to disallow (or at least warn against) the simultaneous use of @tstamp and @qstamp.

We've discussed this before and I don't think we're going to convince each other, but I see no inconsistency in how MEI deals with @tstamp. If 2/2 has 2 beats, 3/4 has 3 beats, and 5/8 has 5 beats, why is it radical or confusing to assert that 6/8 has 6 beats? 😀

Yes, you will never move me from my current musician-based viewpoint: 6/8 is a compound meter with two beats.  This time signature comes from the decay of mensural music, representing music which would have been notated with C-Dot in mensural music: the breve (measure) is divided into two semi-breves [beats], and the semi-breve [beat] is divided into three minims [sub-beats].  Ideally this should have been converted to 2/4. (two beats, where each beat is a dotted quarter), but instead it was converted into 6/8 which was originally hard-wired to mean C-Dot (probably because 17th-century musicians were also computer programmers and they did not want to use the dot).  But over time, 6/8 was used for cases where there are actually 6 beats in the measure, such as slow middle movements in sonatas.  So CMN time signature are ambiguous: traditionally compound meters such as 6/8 can also be used as simple meters.
@tstamps are a purely simple-meter viewpoint of time-signatures (which is one of my objections to them, but that is not the main objection).  I would make an analogy to the arguments about using 4. as a duration: the . confuses programmers who think it is a decimal point rather than an augmentation dot.  For musicians, the same thing occurs when you call an eighth note a beat in 6/8.  Luckily you did not call @tstamp @beat or @bstamp, because then I would be complaining a lot more.  But I sometimes complain about @tstamp as well because as explained above there is score time which is symbolic and real time which is physical.  Scores are written in score time and performers convert these into real-time.  The conversion is not linear since performers will add phrasing, rits, accels., and agogic accents. These two are conflated in music all of the time.  Usually "time" has a primary definition of being physical time, so the label @tstamp is ambiguous when used to indicate score time, particularly to a novice MEI user as to whether or not it refers to physical time or score time.
But my complaint is more that beats have variable widths in different meters rather than about what is called the beat in a particular time signature.  We both agree that 2/2 has a beat every half note and 5/4 has a quarter note beat and 3/8 has an eighth note beat.  But even these that we agree on have computational complexity built into them due to their dependency on the need to reference a time-signature.  The problem with computational processing is illustrated in the above example where the time signature of a measure is changed (or the measure is extracted out of context of the meter).  When the beat width changes, then all @tstamps in measures belonging to the old time signature have to be changed.  For manual encoding of a fixed score, this will not happen too often.  But for a score editing program, this could happen more often.
And there is still the case of extracting a musical excerpt from a score.  How should that be handled?  For example, if someone wanted to extract a measure from an MEI score to use as a musical example in a paper analyzing the piece, the meter would somehow have to be included in the extraction.  That means it would have to be found during the extraction process.  When it is included in the musical excerpt, suppose that the author of the paper does not want the time signature shown (typically it is not shown for a musical excerpt, as the music is not for performance and it can mostly be inferred from the duration of the measure and the beaming patterns).  Is there a way to make the time signature invisible?  With @qstamps (or @estamps for eighth-notes, or @wstamps for whole-notes, etc.), it does not matter what the time signature is, so when extracting the measure you do not need to search for the prevailing time signature to include in the excerpt so that @tstamps remain valid.

A whole-measure rest in 11/8:

<mRest tstamp="1" qstamp="1" dur="1 4 8" dots.vis="1"/>

I am presuming that you mean:
<mRest tstamp="1" qstamp="1" dur="1 4 8" dots.vis="0"/>

As dots on whole-measure rests got this thread started :-)

I am presuming that you mean:

Well, yes and no.  I wasn't trying to be entirely accurate, just trying to illustrate that the number of dots displayed has nothing to do with duration.

Or can have nothing to do with duration if we adopt this new approach.

Or can have nothing to do with duration if we adopt this new approach.

Yes, being able to split visual dots from logical dots will be useful.   One application is that it more or less makes it possible to print mensural music with a CMN typesetting program (i.e., augmentation dots are usually dropped in mensural music).

What about adding optional units to @tstamp?  Without units it behaves as currently.  @qstamp would be equivalent to @tstamp with a unit of "q", such as @tstamp="3q".  There could also be units of "e" for eighth notes, h for half, w for whole, as desired.  Perhaps even dq meaning dotted quarter note units.

Sounds like a reasonable proposal, at least something we should discuss, but anything having to do with revision of @dur, @tstamp, and such won't make it into the next release.

Here's where I got to in the ODD before placing #429 on hold --

  <macroSpec ident="data.DURATION.additive" module="MEI" type="dt" mode="delete"/>

  <classSpec ident="att.duration.additive" module="MEI.shared" type="atts" mode="replace">
    <desc>Attributes that permit total duration to be represented by multiple values.</desc>
    <attList>
      <attDef ident="dur" usage="opt">
        <desc>Records duration using optionally dotted, relative durational values provided by the
          data.DURATION datatype. Multiple space-separated values that add up to the total duration
          may be used. When dotted values are present, the dots attribute must be ignored.</desc>
        <datatype maxOccurs="unbounded">
          <rng:ref name="data.DURATION"/>
        </datatype>

      </attDef>
    </attList>
  </classSpec>

  <classSpec ident="att.annot.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes for annot. Values for the type attribute can be taken from any
      convenient typology of annotation suitable to the work in hand; e.g. annotation, gloss,
      citation, digression, preliminary, temporary, etc.</desc>

    <classes>
      <memberOf key="att.duration.additive"/>
      <memberOf key="att.layerIdent"/>
      <memberOf key="att.staffIdent"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp.logical"/>
      <memberOf key="att.timestamp.gestural"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.beamSpan.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.beamedWith"/>
      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.bend.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.dir.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.dynam.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.f.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.fing.log" module="MEI.fingering" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.fingGrp.log" module="MEI.fingering" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
    <attList>
      <attDef ident="form" usage="opt">
        <valList type="closed">
          <valItem ident="alter">
            <desc>alternation of fingers.</desc>
          </valItem>
          <valItem ident="combi">
            <desc>combination of fingers.</desc>
          </valItem>
          <valItem ident="subst">
            <desc>substitution of fingers.</desc>
          </valItem>
        </valList>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.gliss.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.hairpin.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
    <attList>
      <attDef ident="form" usage="req">
        <desc>Captures the visual rendition and function of the hairpin; that is, whether it
          indicates an increase or a decrease in volume.</desc>
        <valList type="closed">
          <valItem ident="cres">
            <desc>Crescendo; i.e., louder.</desc>
          </valItem>
          <valItem ident="dim">
            <desc>Diminuendo; i.e., softer.</desc>
          </valItem>
        </valList>
      </attDef>
      <attDef ident="niente" usage="opt">
        <desc>Indicates that the hairpin starts from or ends in silence. Often rendered as a small
          circle attached to the closed end of the hairpin. See Gould, p. 108.</desc>
        <datatype>
          <rng:ref name="data.BOOLEAN"/>
        </datatype>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.harm.log" module="MEI.harmony" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
    <attList>
      <attDef ident="chordref" usage="opt">
        <desc>Contains a reference to a <gi scheme="MEI">chordDef</gi> element elsewhere in the
          document.</desc>
        <datatype>
          <rng:ref name="data.URI"/>
        </datatype>
        <constraintSpec ident="check_chordrefTarget" scheme="isoschematron">
          <constraint>
            <sch:rule context="@chordref">
              <sch:assert role="warning" test="not(normalize-space(.) eq '')">@chordref attribute
                should have content.</sch:assert>
              <sch:assert role="warning"
                test="every $i in tokenize(., '\s+') satisfies substring($i,2)=//mei:chordDef/@xml:id"
                >The value in @chordref should correspond to the @xml:id attribute of a chordDef
                element.</sch:assert>
            </sch:rule>
          </constraint>
        </constraintSpec>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.ligatureSpan.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.line.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Attributes for describing the logical behaviour of a line.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>
      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.octave.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.octaveDisplacement"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
    <attList>
      <attDef ident="coll" usage="opt">
        <desc>Indicates whether the octave displacement should be performed simultaneously with the
          written notes, i.e., "coll' ottava". Unlike other octave signs which are indicated by
          broken lines, coll' ottava typically uses an unbroken line or a series of longer broken
          lines, ending with a short vertical stroke. See Read, p. 47-48.</desc>
        <valList type="closed">
          <valItem ident="coll">
            <desc>Coll' ottava (with the octave).</desc>
          </valItem>
        </valList>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.ornam.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>
      <memberOf key="att.duration.additive"/>
      <memberOf key="att.ornamentAccid"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.phrase.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.slur.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.trill.log" module="MEI.cmnOrnaments" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.ornamentAccid"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>
  <classSpec ident="att.tuplet.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.event"/>
      <memberOf key="att.beamedWith"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.duration.ratio"/>
      <memberOf key="att.startEndId"/>
    </classes>
  </classSpec>
  <classSpec ident="att.tupletSpan.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.controlEvent"/>
      <memberOf key="att.beamedWith"/>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.duration.ratio"/>
      <memberOf key="att.startEndId"/>
      <memberOf key="att.timestamp2.logical"/>
    </classes>
  </classSpec>

  <classSpec ident="att.augmentDots" module="MEI.shared" type="atts" mode="replace">
    <desc>Attributes that record the number of dots of augmentation.</desc>
    <attList>
      <attDef ident="dots.vis" usage="opt">
        <desc>Records the number of augmentation dots displayed.</desc>
        <datatype>
          <rng:ref name="data.AUGMENTDOT"/>
        </datatype>

      </attDef>
    </attList>
    <remarks>

The <att>dots.vis</att> attribute records the number of augmentation dots displayed.

    </remarks>

  </classSpec>

  <classSpec ident="att.mRest.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.event"/>
    </classes>
  </classSpec>
  <classSpec ident="att.mSpace.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes in the CMN repertoire.</desc>
    <classes>

      <memberOf key="att.duration.additive"/>
      <memberOf key="att.event"/>
    </classes>
  </classSpec>

  <classSpec ident="att.ambNote.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.accidental"/>
      <memberOf key="att.coloration"/>
      <memberOf key="att.duration.additive"/>

      <memberOf key="att.pitched"/>
    </classes>
  </classSpec>
  <classSpec ident="att.bTrem.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.event"/>

      <memberOf key="att.duration.additive"/>

      <memberOf key="att.numbered"/>
    </classes>
    <attList>
      <attDef ident="form" usage="opt">
        <desc>Indicates whether the tremolo is measured or unmeasured.</desc>
        <valList type="closed">
          <valItem ident="meas">
            <desc>Measured tremolo.</desc>
          </valItem>
          <valItem ident="unmeas">
            <desc>Unmeasured tremolo.</desc>
          </valItem>
        </valList>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.chord.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes for chord. The artic, dots, and dur attributes encode the
      written articulations, augmentation dots, and duration values. The beam, fermata, lv, slur,
      syl, tie, and tuplet attributes may be used to indicate the attachment of these things to this
      chord. If visual information about these things needs to be recorded, then either the elements
      corresponding to these attributes or the attributes available in the att.vis.chord class
      should be employed.</desc>
    <classes>
      <memberOf key="att.articulation"/>

      <memberOf key="att.chord.log.cmn"/>
      <memberOf key="att.duration.additive"/>

      <memberOf key="att.event"/>
      <memberOf key="att.sylText"/>
    </classes>
  </classSpec>
  <classSpec ident="att.chord.vis" module="MEI.visual" type="atts" mode="replace">
    <desc>Visual domain attributes for chord.</desc>
    <classes>
      <memberOf key="att.altSym"/>
      <memberOf key="att.augmentDots"/>
      <memberOf key="att.color"/>
      <memberOf key="att.enclosingChars"/>
      <memberOf key="att.extSym"/>
      <memberOf key="att.stems"/>
      <memberOf key="att.typography"/>
      <memberOf key="att.visibility"/>
      <memberOf key="att.visualOffset.ho"/>
      <memberOf key="att.visualOffset.to"/>
      <memberOf key="att.xy"/>
      <memberOf key="att.chord.vis.cmn"/>
    </classes>
    <attList>
      <attDef ident="cluster" usage="opt">
        <desc>Indicates a single, alternative note head should be displayed instead of individual
          note heads. The highest and lowest notes of the chord usually indicate the upper and lower
          boundaries of the cluster note head.</desc>
        <datatype>
          <rng:ref name="data.CLUSTER"/>
        </datatype>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.fTrem.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.event"/>

      <memberOf key="att.duration.additive"/>

    </classes>
    <attList>
      <attDef ident="form" usage="opt">
        <desc>Describes the style of the tremolo.</desc>
        <valList type="closed">
          <valItem ident="meas">
            <desc>Measured tremolo.</desc>
          </valItem>
          <valItem ident="unmeas">
            <desc>Unmeasured tremolo.</desc>
          </valItem>
        </valList>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.fTrem.vis" module="MEI.visual" type="atts" mode="replace">
    <desc>Visual domain attributes.</desc>
    <classes>
      <memberOf key="att.augmentDots"/>
    </classes>
    <attList>
      <attDef ident="beams" usage="opt">
        <desc>Indicates the number of beams present.</desc>
        <datatype>
          <rng:data type="positiveInteger">
            <rng:param name="minInclusive">1</rng:param>
            <rng:param name="maxInclusive">6</rng:param>
          </rng:data>
        </datatype>
      </attDef>
      <attDef ident="beams.float" usage="opt">
        <desc>Captures the number of "floating" beams, i.e., those not attached to stems.</desc>
        <datatype>
          <rng:data type="nonNegativeInteger"/>
        </datatype>
        <constraintSpec ident="check_beams.floating" scheme="isoschematron">
          <constraint>
            <sch:rule context="mei:fTrem[@beams and @beams.float]">
              <sch:assert test="@beams.float <= @beams">The number of floating beams must be less
                than or equal to the total number of beams.</sch:assert>
            </sch:rule>
          </constraint>
        </constraintSpec>
      </attDef>
      <attDef ident="float.gap" usage="opt">
        <desc>Records the amount of separation between floating beams and stems.</desc>
        <datatype>
          <rng:ref name="data.MEASUREMENTABS"/>
        </datatype>
      </attDef>
    </attList>
  </classSpec>
  <classSpec ident="att.halfmRpt.log" module="MEI.cmn" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>
      <memberOf key="att.event"/>
      <memberOf key="att.duration.additive"/>

    </classes>
  </classSpec>
  <classSpec ident="att.halfmRpt.vis" module="MEI.visual" type="atts" mode="replace">
    <desc>Visual domain attributes.</desc>
    <classes>
      <memberOf key="att.altSym"/>
      <memberOf key="att.augmentDots"/>
      <memberOf key="att.color"/>
      <memberOf key="att.expandable"/>
      <memberOf key="att.extSym"/>
      <memberOf key="att.typography"/>
      <memberOf key="att.visualOffset"/>
    </classes>
  </classSpec>
  <classSpec ident="att.note.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>

      <memberOf key="att.coloration"/>
      <memberOf key="att.duration.additive"/>

      <memberOf key="att.event"/>
      <memberOf key="att.note.log.cmn"/>
      <memberOf key="att.note.log.mensural"/>
      <memberOf key="att.pitched"/>
    </classes>
  </classSpec>
  <classSpec ident="att.note.vis" module="MEI.visual" type="atts" mode="replace">
    <desc>Visual domain attributes.</desc>
    <classes>
      <memberOf key="att.altSym"/>
      <memberOf key="att.augmentDots"/>
      <memberOf key="att.color"/>
      <memberOf key="att.enclosingChars"/>
      <memberOf key="att.extSym"/>
      <memberOf key="att.noteHeads"/>
      <memberOf key="att.staffLoc"/>
      <memberOf key="att.stems"/>
      <memberOf key="att.typography"/>
      <memberOf key="att.visibility"/>
      <memberOf key="att.visualOffset.ho"/>
      <memberOf key="att.visualOffset.to"/>
      <memberOf key="att.xy"/>
      <memberOf key="att.note.vis.cmn"/>
    </classes>
  </classSpec>
  <classSpec ident="att.rest.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>

      <memberOf key="att.duration.additive"/>

      <memberOf key="att.event"/>
      <memberOf key="att.rest.log.cmn"/>
    </classes>
  </classSpec>
  <classSpec ident="att.rest.vis" module="MEI.visual" type="atts" mode="replace">
    <desc>Visual domain attributes.</desc>
    <classes>
      <memberOf key="att.altSym"/>
      <memberOf key="att.augmentDots"/>
      <memberOf key="att.color"/>
      <memberOf key="att.enclosingChars"/>
      <memberOf key="att.rest.vis.cmn"/>
      <memberOf key="att.rest.vis.mensural"/>
      <memberOf key="att.staffLoc"/>
      <memberOf key="att.staffLoc.pitched"/>
      <memberOf key="att.typography"/>
      <memberOf key="att.visualOffset"/>
      <memberOf key="att.xy"/>
    </classes>
  </classSpec>
  <classSpec ident="att.space.log" module="MEI.shared" type="atts" mode="replace">
    <desc>Logical domain attributes.</desc>
    <classes>

      <memberOf key="att.duration.additive"/>

      <memberOf key="att.event"/>
    </classes>
  </classSpec>

The element-by-element approach is probably overkill.  That is, it might be possible to accomplish the same thing by altering att.event and att.controlEvent. Still, some "shifting" might be required.
In any case, at this point we can fix the issue with regard to <mRest> and <mSpace>; that is, remove @dots, but anything beyond that too hot to handle, it seems.

When the duration is "irrational", as is sometimes the case with tuplets, multiple space-separated values that add up to the total duration may be used. When dotted values are present, the dots attribute must be ignored.

I would avoid using the word irrational since musical rhythms are mathematically called rational numbers (but that does not stop musicians from using the term irrational for rational numbers :-).  An irrational rhythm would be pi-uplets or the square-root-of-three-uplets.

Here is some music with irrational durations:
http://www.finalemusic.com/blog/pi-day-finale-font-update

authors: ahankinson craigsapp kepper pe-ro rettinghaus


text:
🛑 Musikwerk Cloud is down

In 32f8d70, Musikwerk Cloud (https://cloud.musikwerk-stuttgart.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Musikwerk Cloud is back up in 4823fb2 after 21 minutes.

source: gharchive/issue

repo: musikwerk-stuttgart/upptime

license: MIT

license_type: permissive

license_source: github-api


text:
GPL 3 Licence too restricitve for commercial applications

Good day Mustafa
Is it likely for the license to be changed to something more permissive, like BSD, MIT, Apache or the like? The GPL 3 triggers alerts in commercial systems and devs have to re-implement the functionality rather than use the good tested solution.
Completely understand and respect the decision to stick to GPL 3.0 if you do so.

Hi @vatula , I can change to MIT. is it okay for you ?

Hi @vatula , I can change to MIT. is it okay for you ?

Yes! 👍

I have updated @vatula .

authors: mustafadalga vatula

repo: mustafadalga/remove-attr


text:
README

@MarkusRabe If you have time, do you mind giving some worked examples of the API in the README?

Will do.

authors: MarkusRabe mvcisback

repo: mvcisback/py-aiger-analysis


text:
Нова стаття про фізику і Scratch

Оновлення від Oleksandr Miziuk

Дякую, чудово

source: gharchive/pull-request

authors: gtmizyuk mvsros

repo: mvsros/book


text:
Update for dbt v1.0.0

This was released mid-December at Coalesce.
Can you release a new version? How should we specify that?
https://coalesce.getdbt.com/talks/dbt-v10-reveal/

FYI, I would also want to the (preview) dbt-databricks adapter
    Could not find adapter type databricks!

Hi there,
I created a new branch for dbt v1.0.0 and the databricks adapter. Can you please try your workflow with:
uses: mwhitaker/dbt-action@fishtown-v1.0

Once it looks good I can update the main branch.
Michael

Worked! Thanks for the fast turnaround :-)

authors: drernie mwhitaker

repo: mwhitaker/dbt-action


text:
Simple bitwise operations

Simple bitwise operations as primitives. Useful for bitset operations and also the theory of bitvectors. See commented out section of test for bitset operations. Should supporting things like that be something in the surface language?

I feel like those should be primitives, no? What is the advantage of them being functions instead?

repo: mwillsey/egg-smol


text:
Golang build broken: parameterToString undefined

Cross posting here in case there is more visibility on this repo. It seems that the golang build is broken.
https://github.com/mxenabled/mx-platform-go/issues/47

I think we need to close this, as the link you mentioned in issue has a PR linked to it.
Please refer https://github.com/mxenabled/mx-platform-go/issues/47

@JigarJoshi04 That's fine. Can you try to get some attention on that PR?

Fixed by https://github.com/mxenabled/mx-platform-go/pull/49

repo: mxenabled/openapi


text:
Superset and SQLLab - queries never finish in the query dialogue

(preview works fine now).
If I enter a query or use the copy to clipboard and paste in the UI says pending but it never returns.
These are queries with limits and should be just fine.
The log shows this endlessly..
2018-02-11 14:38:04,522:INFO:root:Parsing with sqlparse statement SELECT `LINE_ITEM_ID`,
       `SAPID`,
       `CUSTOMER`,
       `CAMPAIGN_NAME`,
       `AD_NAME`,
       `AD_TYPE`,
       `PLATFORM`,
       `COUNTRY`,
       `COST_BASIS`,
       `ACTUAL_RATE_ORIGNAL_CURRENCY`,
       `CURRENCY_ORIGINAL`,
       `ORDER_SALESPERSON`,
       `STARTDATE`,
       `GROSS_RATE`,
       `DISCOUNT`,
       `LASTMODIFIEDDATE`,
       `bq_load_timestamp`
FROM visualizations.MASTER_RATE_RPT
LIMIT 100
2018-02-11 14:38:05,062:INFO:root:Triggering query_id: 28
2018-02-11 14:38:05,062:INFO:root:Running query on a Celery worker
2018-02-11 14:38:06,916:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:08,918:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:10,914:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:12,921:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:14,925:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:16,920:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:38:18,912:DEBUG:root:[stats_logger] (incr) queries
...
[2018-02-11 14:39:04 +0000] [3334] [CRITICAL] WORKER TIMEOUT (pid:3793)
[2018-02-11 14:39:04 +0000] [3793] [INFO] Worker exiting (pid: 3793)
Loaded your LOCAL configuration at [/home/derwin/venv/bin/superset_config.pyc]
[2018-02-11 14:39:04 +0000] [4389] [INFO] Booting worker with pid: 4389
2018-02-11 14:39:04,911:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:39:06,914:DEBUG:root:[stats_logger] (incr) queries
2018-02-11 14:39:08,917:DEBUG:root:[stats_logger] (incr) queries

when I press stop..
2018-02-11 14:39:13,317:DEBUG:root:[stats_logger] (incr) stop_query

This might be a superset config issue .. checking into this Celery thing..

Yes .. just an issue with having redis configured.

repo: mxmzdlv/pybigquery

license: mit

license_source: bigquery


text:
chore: update dependencies

Not sure if we should do it.

** Node.js CI / build (pull_request) ** Failing after 15s

This seems to be a still-unresolved issue tracked here: https://github.com/actions/toolkit/issues/1075:
    TypeError: Cannot destructure property 'access' of 'fs_1.promises' as it is undefined.

Eventually, we'll have to update, methinks. Might as well do it when it's not urgent.

authors: dscho mxschmitt

repo: mxschmitt/action-tmate


text:
Chrome's CSP Blocks loading of bundle.js

On Chrome OSX v49.0.2623.87 (64-bit), the application suffers a fatal crash, because the js/bundle.js refuses to be loaded.
In my console I get the following message:
Refused to load the script 'http://localhost:3000/js/bundle.js' because it violates the following Content Security Policy directive: "script-src 'none'".

This happens right after cloning / npm install / npm start, so I haven't modified any files yet.

I did some digging around, and this was actually caused by me disabling JS in the browser. :disappointed_relieved:

repo: mxstbr/react-boilerplate


text:
关于yolov5的移植问题

我在作者的基础上修改一些代码，移植好了yolov5，但目前有些问题没搞明白：
用high-precision量化的wk跑起来仍然有一些精度损失，主要表现为confidence略有下降，对于本身得分就不高的目标容易发生漏检，请问这个现象是合理吗？还是说哪里弄得有问题，现在我也在检查很久了，没发现问题。
ps：(最好的办法是每一层打印输出和torch模型对比，但可能我太菜了。。觉得这个工作量有点难受)

量化会产生一定的精度损失，所以模型选择的时候不光要考虑 precision&recall，还有考虑权重范围分布和推理平台最匹配的模型

repo: mxsurui/NNIE-lite


text:
2 accounts on one Home assistance give issue

When adding 2 accounts to home assistant there is only one warning created.
In the logs you get the following error:
Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:540
Integration: Sensor (documentation, issues)
First occurred: 17:42:59 (1 occurrences)
Last logged: 17:42:59
Platform bibliotheek_be does not generate unique IDs. ID Bibliotheek.be warning already exists - ignoring sensor.bibliotheek_be_warning

You can add multiple library cards within the bibliotheek.be account. No need to add multiple accounts.
I know, it may not cover all use cases, but else I'll have to add a username in every sensor...

authors: myTselection trvrcr


text:
All override methods must be added @override

All override methods must be added @override

@kazuki43zoo all resolved


text:
[control plane][BE] return buyer company id and name in api activity log

a/c:

return the buyer company id and name who triggered the sonata api request in api activity log for each record

tested with pass

buyer: uuid

pass

repo: mycloudnexus/kraken


text:
testdriver: update errlogmatch logic

This PR will update errlogmatch so that the search start offset for the next call is based on the last match instead of how the errlog looked at the last call.
It will also rename the flag leavelast to peek to reflect the new behavior.

Fixes #433

repo: myitcv/govim


text:
🛑 kara is down

In 1f8cce9, kara (https://www.カラ.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: kara is back up in 09fbee7.

repo: mymovielist/uptime


text:
fix(product-settings): fix updating without hpos

INT-203

en de migratie?

de pdkProductRepository roept all het WC_Data->save_meta_data aan, dus de call naar wcProduct->save was overbodig en zo merkten we niet dat die toch niets deed. De call verwijderd uit de migratie. (ter info, de ->markMigrated method savet ook zelf de metadata...)

authors: Mark-Ernst joerivanveen

repo: myparcelnl/woocommerce


text:
Match failure upon playback

I've observed VCR/webmock raising an error:
WebMock::NetConnectNotAllowedError: Real HTTP connections are disabled. Unregistered request: GET https://myaccount.sdge.com/security/signin.fcc?<LONG_STRING>

... even though the corresponding cassette file has a URI entry of
uri: https://myaccount.sdge.com:443/security/signin.fcc?<LONG_STRING>

A minimal test and companion cassette are in git://gist.github.com/908795.git (hey, why didn't GitHub flavored markdown autolink that??)

@rdpoor: The request matching works significantly differently in VCR 2.0, as I blogged about a few days ago.
Can you give VCR 2.0 beta 1 a try and see if it solves the problem for you?

@myron: with pleasure.  i'm up to my elbows in alligators on another project, so it will take me a couple of days to get to it.

I'm closing this as I'm fairly certain the new request matcher stuff in VCR 2 will solve this issue.  @rdpoor: feel free to reopen or create new issue if you're still having problems.

Sounds entirely right.  I'll reopen if I discover it's still a problem.  Thanks.
On Thu, Dec 1, 2011 at 23:23, Myron Marston
reply@reply.github.com
wrote:

I'm closing this as I'm fairly certain the new request matcher stuff in VCR 2 will solve this issue.  @rdpoor: feel free to reopen or create new issue if you're still having problems.

Reply to this email directly or view it on GitHub:
https://github.com/myronmarston/vcr/issues/52#issuecomment-2987125

authors: myronmarston rdpoor

repo: myronmarston/vcr


text:
Need good README.md

Make a good README.me file with all the required details  mentioned in the previous readme file..add the app screenshots to the readme file. which is given under the project with folder name snapshots.

Hey @myselfdeepdas, May you assign this to me?

@Anubhakri13 Do it  !!


text:
createConnection db is passed as valid even though non existent.

Hi so I have a createConnection that looks like this:
var connection = mysql.createConnection({
	host: 'localhost',
	user: 'root',
	password: 'Tino0211',
	db: 'stack_' + req
});

req is a variable passed from a function.
Lets say the database stack_foo exists, then it returns true and there is no error. However, if I say stack_bar, which is not a valid database, there is still no error on connection.
Why is this?
Thanks

Haha, I found the error, I have to say database not db...

repo: mysqljs/mysql


text:
Question: Is there a way view/modify config settings prior to request

Is there any way to modify the config before a request is made? For instance I'd like to introspect config.method and depending on the method choose a setting for config.headers.

Yes, you can use a request interceptor for that. E.g.:
axios.interceptors.request.use(function(config) {
  if (config.method === 'get') {
    config.headers.foo = 'bar';
  }
  return config;
});

That did the trick, thanks!

authors: j-funk rubennorte

repo: mzabriskie/axios


text:
Unable to search .MSP spectral database since MZmine 3.4.14

Basic information

My operating system and version: Windows 10
My MZmine version: tested with 3.4.14 and 3.9.0 (the same workflow works fine on MZmine 2.53 and 3.3.0)

What happened
I would like to do database search on my peak list within MZmine (similar to a NIST search, spectral match). The workflow employed is the following:

Mass detection
ADAP chromatogram builder
ADAP peak resolver
Spectral deconvolution by hierarchical clustering
Search in .MSP database (export from NIST library or custom in-house databse in .MSP format)

In MZmine 2.53 and 3.3.0, this wotkflow give wotks fine (even though searching in NIST DB can take a lot of time, MZmine 3.3.0 really improved it though), but with MZmine 3.4.14 and earlier, there is not matches in the DB. It looks as if the data is not even look up because the task runs in just a second (wheareas matching against a .MSP DB with a few thousand compounds takes at least a few seconds in MZmine 2 and 3.3.0).
The "Spectral match" column of the feature list remain empty, whatever is threshold entered for the match.
I cannot say if it is problem during the import of the DB, an incompatibility of the .MSP formating or an issue in the spectral search module. I tried to convert my DB into a feature list, I got the right list of compounds but I am unable to visualize the spectras, maybe this can be a clue for the troubleshooting?
I have not try the other DB formats as NIST DB only offers .MSP as a compatible format with MZmine.
Best regards
Grégoire
Update : it works well with 3.4.0 too, so the problem may have appeared with 3.4.14.

Hi,
on first glimpse i cant find anything that we changed in between these versions that should affect the parsing. Can you upload a single entry of that database that is not being parsed?
Which module do you use to search the database? Do you import the spectral library and then use the spectral libary search, or do you use the NIST MS search?
Another question: If you use the library import: When the library is imported to MZmine: How many entries does it say it has? (In the libraries tab)

Hi,
the .msp is formatted as follow:
Name: Decane
Formula: C10H22
MW: 142
ExactMass: 142.172151
CASNO: 124185
RI:1015
Comment:  Any=1000 ; NIST MS# 114147, Seq# M27626 |RI:1015|
Num peaks: 43
14 7.99
15 4.00
16 5.00
27 164.85
29 248.78
30 6.99
39 168.85
41 638.42
42 203.82
43 801.28
44 33.97
50 4.00
51 13.99
52 6.99
53 52.95
54 32.97
55 247.78
56 269.76
57 999.00
58 45.96
65 9.99
66 4.00
67 18.98
68 12.99
69 79.93
70 199.82
71 442.60
72 21.98
77 5.00
79 3.00
82 4.00
83 20.98
84 126.89
85 292.74
86 17.98
98 70.94
99 82.93
100 6.99
112 25.98
113 45.96
114 4.00
142 73.93
143 8.99
I used the "spectral library search", with the same parameters (MS1 only, 0.6 m/z in tolerance and match parameter similar to NIST). The library import is done separately before the search.
I tried to use NIST MS Search but I got an error which is I think related to Java "C:\IXCR Data\IXCR.MSD The system cannot find the path specified".
During the library import, the number of entries is correct.

authors: SteffenHeu gdelap


text:
GUI Design ListView vs TreeView

Hey Tomas,
I was wondering why we are using ListView instead of TreeView  for the RawDataTree in the main window. I talked to @robinschmid today about the possibility to use TableTreeView. That would make it more complicated but would also enable nice possibilities to observe a raw file.
What do you think?

This is something we can still change, of course. But in the past, when giving tutorials or workshops with MZmine, I found that many users are initially confused by the "+" buttons in the project tree. For example when asked to open the feature list, they don't know if they should click on the + button or double click on the feature list name. In contrast, ListView is conceptually simpler and easy to understand for everyone. And we could add an option to explore the RawDataFile using a separate window (e.g., list all scans of the file and details about them in a table). The separate window could be implemented using TreeTableView, as you suggest. What do you think about that?

@robinschmid @Annexhc By the way, I am about half-way done with JavaFXing the whole MZmine on my branch: https://github.com/tomas-pluskal/mzmine3/tree/javafx_parameters
Feel free to take a look. It still has compilation errors, but you can run it in Eclipse, load files and projects, run TIC plots, etc.

Once the JavaFXing is done, we can talk more about how to improve the main window further - e.g., using tabs or dockable components.

Nice progress Tomas! I totally get your point. The TreeView of ALL scans isnt really the best option anyway. I like the idea of a separated window to visualize the raw data. @robinschmid do you agree?

I know some people who did get confused with the feature lists. They would only open the feature list with the + of the tree and not by double clicking the item. I still like the tree or the idea for a TableTreeView. However, this could be a checkbox menu item ("advanced project trees").
@tomas-pluskal Great :)
I also saw that you have switched to EChartViewer. Nice.

authors: Annexhc robinschmid tomas-pluskal


text:
Parser for structure IDs (smiles, inchi)

A CDK-based parser to translate SMILES to InChI keys and vice-versa

Hi mmattano, thank you for contributing.
I think the test is currently failing.
As far as i can see, the parser currently is not incorporated into any module.
Where do you see implementation of this parser?
In my opinion, this could be incorporated to the parsing process of csv files in the compound database search module, to add additional metadata.

Hi Steffen, thanks for checking! I worked on this with Robin for the BioHackathon and we were planning to use it in an MS2 fragment structure annotation tool

That's great, thanks 👍

I incorporated this into one of my branches with substructure support. Will create a new PR soon

authors: SteffenHeu mmattano robinschmid


text:
The event for casper.test fail event no longer fires with --fail-fast option (1.1.x)

I used to have code that would capture an image when tests failed.  So I hooked into this event:
casper.test.on('fail', function (failure) {
    // do something
});

But it no longer appears to fire.  At least with the code we ported to 1.1.
I've been trying to figure out a work around, but haven't found one yet.  I see some of the code around this event has changed since the last version of casper we were using.
I tried to search and didn't find another open issue, so sorry if this is a duplicate.
One other added bit of info is that we're using failfast, which by looking at the code changes makes me think that the event won't be captured by the time the code exits.  Though it did used to work very well.
Thanks,
Mike

Good job !

I'm running into this issue, and was surprised to see that it's been fixed in the repo since July of 2014, yet there has not been a new release since 1.1.0-beta3 back in November 2013.
Are there any plans for another release?  I really like Casper and hope this doesn't mean that the project has been abandoned.  I see that people are still making commits, just wondering when we can expect another version?

We need to ensure casper works with PhantomJS2 and latest Slimer, which is being worked on by @hexid atm. When this is addressed, I'll release a new version.

OK great, thanks @n1k0.  I wondered if the Phantom 2 release was holding things up.  Looking forward to it!

authors: brettjonesdev mle-ii n1k0 surenderssm


text:
🛑 rasp.n1l.dev is down

In 9deb917, rasp.n1l.dev (https://rasp.n1l.dev) was down:

HTTP code: 0
Response time: 0 ms

Resolved: rasp.n1l.dev is back up in 9e41db8 after 19 minutes.


text:
n3 line chart only in single value

In graph only in single value x-axis values become so far
eg: yerar in axis 500 1000 3000 4000 ...
but year is present 2015 like that

Hi, could you be more specific ? Not sure I'm getting what you mean...
Thanks !

Hey, we're closing this because it's been a while and we're trying to avoid zombie issues. If the problem persists, please open a new issue (and don't forget, your issue is much more likely to be fixed if you provide a working CodePen : easier for us, faster for you !).
Thanks again for helping us making n3-charts awesome.
--
Sébastien & Christoph


text:
Error Unexpected end of JSON input

Hi,
When modifying Page assist - Settings on windows Edge - i got this on Windows 11 - Edge browser
Error
Unexpected end of JSON input
i didnt touch any Json file after Edge extension install.

Hey, sorry about that. Which setting did you try to change when you got this error? I'll look into it

Hey.
You shouldn't sorry anything :)  - we should Thank You for your amazing work!  :)
Click on Settings then Manage Model.

then deleting one of the model shows this:

Ah, got it. I’ll fix it in the 1.2.2 release.


text:
Add a module:make-component

Laravel has a component command, which is really awesome, and I think that people would like to see the same functionality in this package.
My use case is that I'm making a Laravel vapor-like site, and I'd like to use the newly added dynamic-component in one of my modules.

+1

#1110 Fixes this issue

Closed in 850931b

authors: FoksVHox magic-thomas

repo: nWidart/laravel-modules


text:
Update Metar.php

The reported pressure was always being assigned as hPa thus resulting display and conversion errors when the reported pressure was inHg.
Also the VFR/IFR (VMC/IMC) determination was using minimum 5 nmi and 3000 ft cloud base, it must be 5 km and 3000 ft.
With this state, this PR should fix issue #948 and partly fixes issue #963

Conversion and view just works fine as expected.
MetarTest must be checked for inHg and hPa logic. As any reported pressure with Annnn is inHg and Qnnnn is hPa. But as far as I see on the metarTest1 the units are wrong. Did not wanted to commit a change on the test.

The tests need to be fixed as part of this

Do you approve the change of VFR to VMC and IFR to IMC , I can do that too ... It is kind of habit thing , technically they are VMC/IMC but on everyday use people tend to say VFR/IFR too often :)
Will send the MetarTest commit soon btw

I would leave it as VFR/IFR, which's normally used... that's also how I learned it in my PPL classes. IIRC, there is a difference between VMC and VFR. I'll have to look it up in more detail but I would leave that as-is. I will think about turning that into a translation maybe.

authors: FatihKoz nabeelio

repo: nabeelio/phpvms


text:
内存限制失败

现在服务器docker运行nacos:latest镜像直接down掉，原因是nacos把内存吃光了
下面是docker-compose，已经限制最大500m，可是还剩1.5g左右内存都起不来，去掉memory: 550M后直接把服务器内存吃光
nacos:
    image: nacos/nacos-server:latest
    container_name: nacos
    environment:
      - PREFER_HOST_MODE=hostname
      - MODE=standalone
      - MYSQL_DATABASE_NUM=1
      - SPRING_DATASOURCE_PLATFORM=mysql
      - MYSQL_SERVICE_HOST=mysql
      - MYSQL_SERVICE_DB_NAME=nacos_dev
      - MYSQL_SERVICE_PORT=3306
      - MYSQL_SERVICE_USER=nacos
      - MYSQL_SERVICE_PASSWORD=nacos
      - MYSQL_SERVICE_DB_PARAM=characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
      - JVM_XMS=500m
      - JVM_XMX=500m
      - JVM_XMN=300m
    volumes:
      - /opt/docker-file/nacos/logs:/home/nacos/logs
      - /opt/docker-file/nacos/conf/custom.properties:/home/nacos/init.d/custom.properties
    depends_on:
      - mysql
    ports:
      - "8848:8848"
      - "9848:9848"
      - "9555:9555"
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 550M
      restart_policy:
        condition: on-failure
    logging:
      driver: "json-file"
      options:
        max-size: "200m"
        max-file: "5"
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://127.0.0.1:8848/nacos"]
      interval: 10s
      timeout: 30s
      retries: 3
      start_period: 5m

这是没人管了？？？

转Consul吧，阿里的kpi开源项目

deploy:
  resources:
    limits:
      cpus: '0.50'
      memory: 550M

这个内存给的太小了。  实际使用内存 要大于 550M。 这其中包括：-XX:MetaspaceSize

resources:
  limits:
    cpu: 2000m
    memory: 2048Mi
  requests:
    cpu: 1000m
    memory: 1024Mi

可以参考这个设置会更顺畅运行

限制docker容器内存会导致容器崩溃重启

2024-0909 依然无效果

repo: nacos-group/nacos-docker


text:
Crash: IndexOutOfBoundsException (Crystalize Base, Animation, "tiny_potatog/animation.tongue")

Trimmed stacktrace:
net.minecraft.util.crash.CrashException: Exception ticking world
Caused by: java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 3
	at io.github.nahkd123.crystalize.anim.Timeline.interpolate(Timeline.java:47) ~[main/:?]
	at io.github.nahkd123.crystalize.anim.TimelineGroup.interpolate(TimelineGroup.java:26) ~[main/:?]
	at io.github.nahkd123.crystalize.anim.controller.TemplatedAnimationController.animate(TemplatedAnimationController.java:95) ~[main/:?]
	at io.github.nahkd123.crystalize.fabric.model.BonePart.updateTree(BonePart.java:89) ~[main/:?]
	at io.github.nahkd123.crystalize.fabric.model.BonePart.updateTree(BonePart.java:124) ~[main/:?]
	at io.github.nahkd123.crystalize.fabric.model.BonePart.updateTree(BonePart.java:124) ~[main/:?]
	at io.github.nahkd123.crystalize.fabric.model.BonePart.updateTree(BonePart.java:124) ~[main/:?]
	at io.github.nahkd123.crystalize.fabric.model.CrystalizeElementHolder.onTick(CrystalizeElementHolder.java:111) ~[main/:?]
	... ?? more

The exception appears to be coming from Crystalize Base.

Error with SCALE channel


text:
[feature] Advanced parameter creation

(Note: I will gladly implement this, this is more of an FYI and spec for myself)
Currently we get a basic form of parameters, using just dumped json or the request actually sent via the spec. Nothing wrong with that - gets us up and running quickly.
However, I would like to add some additional info according with the Parameter specs.
I was thinking something like this is the specs:
RSpec.describe '/api/v1/resources', apidoc:true, resource_group: 'Resources' do
  let (:doc_parameters) do
    {
      some_param: {description: 'So param, very important', default: 0, type: :number, optional: true }
    }
  end

  RSpec.describe 'POST /do_something', resource: 'Resource', action: 'Do something', parameters: doc_parameters do
    xhr :post, '[url]', some_param: 56
  end
end

Would become:
+ Parameters
    + id (number, optional) - So param, very important
        + Default: `0`

Some notes:

I would skip the <example value> because it doesn't make sense with rspec generated response bodies (already some example values there).

Thanks for logging this, I really appreciate it.
I'm curious, why using let variables over test metadata like the other metadata we are attaching?

It's the same way (metadata). I just gave an example using :let because it seems more readable than:
  RSpec.describe 'POST /do_something', resource: 'Resource', action: 'Do something',
    parameters: some_param: {description: 'So param, very important', default: 0, type: :number, optional: true } do
...
end

Got it. We might consider recommending writing the metadata a la
post_do_something = {
  action: 'Do something',
  parameters: {
    some_param: {
      description: 'So param, very important',
      # etc.
    }
  {
}
RSpec.describe 'Post /do_somthing', post_do_something.merge(resource: 'Resource') do
end

Up to you however

authors: GregPK nambrot

repo: nambrot/rspec-api-blueprint-formatter


text:
Implicit type casting in the VAD example

In the outputs of the ACFAveraging_fun function of the VAD example(s) an implicit conversion from Word32 to short is performed which is not documented.
The interface to the invoked acf_averaging function expects arrays of Word32 data type for the outputs however the result of the computation are assigned to elements of a L_av_t type for communication which packs short values.
Is this behavior safe and intended? If yes, it is better to be documented in the code.

Dear Hosein,
First, just for the observation. In a recent commit i have just added the following comment close to the call to the acf_averaging function within the wrapper function:
	// Note: there is an implicit conversion from Word32 array (acf_averaging prototype)
	//       the short array in this wrapper function, which enables the match to the
	//       short array declared at the corresponding output edges (E1 and E2)
	//       The conversion does not produces any change of the VAD functionality,
	//       since the outputs are flags, result of the voice detection (or not),
	//       and only the LSB is used actually.
	//       Thanks Hosein for the observation!

authors: nandohca shaniaki

repo: nandohca/kista


text:
MCP41xxx addition

Added MCP41xxx.py file for MCP41xxx library support to control MCP41xxx digital potentiometers.

Coverage decreased (-0.1%) to 41.987% when pulling 7a95026b5c02f067fdfbcefda42f3b8bd63bf6b7 on egarris2:MCP41xxx_addition into 9661d75d349ead8fb01c9ee43c1bd8ad1a8b7ab9 on nanpy:master.

Thanks for this @egarris2 !

authors: astagi coveralls egarris2

repo: nanpy/nanpy


text:
🛑 naoTimes [web/docs] is down

In 26f7597, naoTimes [web/docs] (https://naoti.me/) was down:

HTTP code: 403
Response time: 34 ms

Resolved: naoTimes [web/docs] is back up in 0ccc926.

repo: naoTimesdev/status


text:
Add explicit tracking of pathogens of interest

It would be good to have a standard list of pathogens we look for in the workflow, with a standard way of presenting the results. We can use the select agent list and MA list of reportable pathogens as references here.

This might or might not be subsumed by our Q4 plans to enhance our list of reference pathogens, downweighting for now.

Update, no current plans to do this and unclear if it fits in the direction the v2 pipeline is developing. Closing this for now.

repo: naobservatory/mgs-workflow


text:
add API support

for iOS app and browser plug-in, or something more...

取消此功能，准备移除已有的接口。

啊真是可惜呢……本来有打算写个App之类的……

@cdiscrete 因为发现通过 API 进来的数据，没有实时显示出来，需要刷新之后才能看到。

@naoyeye iOS应该可以实现实时更新的呀。

刚试了下打开 perber.com 后（在电脑 chrome 和 iOS safari 都打开），然后从电脑的 chrome 中访问 douban.com，打开开发者工具，在 console 中通过 API 向 perber 发布新内容：
var data = { msg: "HAKULAMATATA test api" };
$.ajax({
    url:'http://www.perber.com/api/v1/new',
    contentType: 'application/json; charset=utf-8',
    type: 'POST',
    data : JSON.stringify(data)
});

请求发布成功，但是 电脑 chrome 和 iOS safari  中的 Perber 都没有显示出这条消息。刷新页面后，显示。

看了下之前的代码
https://github.com/naoyeye/Perber/blob/master/perber/api/index.js#L58
发现当时我只把这个接口进来的数据存到 mysql 里了，没有走 socket，所以其他设备没法实时收到从接口进来的消息。😂

囧，所以走socket通道就好了呀。

TODO:
现在的通过 API 进来的消息没有带上地址信息。需要在处理请求时，拿到 IP 地址。

authors: cdiscrete naoyeye

repo: naoyeye/Perber


text:
Python 3 support

See details in the parent issue napalm-automation/napalm#199

Python3 issue in PYEZ with parsing YAML: https://github.com/Juniper/py-junos-eznc/issues/639

Closed via https://github.com/napalm-automation/napalm-junos/commit/c40cc819d8de6695468869ac45a64a18045930ce

authors: dbarrosop ktbyers mirceaulinic

repo: napalm-automation/napalm-junos