specs's Introduction
specs's People
Forkers
pythouillespecs's Issues
'next' description in schema
To complete the descriptions of the keys, I propose for 'next' (here) :
"description": "The bars that follow this one, in performance order, expressed by their 'count'. Most bars have exactly one entry in this list; those before a repeat may have two or more. The value -1 refers to the end of the piece.",
"examples": [
[2],
[9,1],
[59,-1],
]
I could not push the change / another branch for the moment. Is there some rights to grant so I can contribute to it?
Compressed version standard
What are the specification for compressed / uncompressed? The aim is to keep only necessary information without any loss of information.
- First of all, a fully compressed version is also non-verbose (see non-verbose specification #2 (comment)): the only values that are written are those that are different from the default values.
- If a measure can be entirely deduced from the previous one, then it does not appear in the compressed measure map. The following displayed measure must mention its
number
so that we can deduce how many measures were skipped this way. - The last measure of the original measure map is always put in the compressed measure map -- with its 'number'.
- (An alternative solutions have been proposed to indicate endings: an end-of-piece token with qstamp indicating the length of the piece in quarter notes (and 'count' -1 ?))
Remarks/questions:
- 1- We mentioned that having specific
ID
for each measure involves that they all need to be in the measure map (i.e. no compression possible). Should we discourage this practice, or accept to lose this information in some cases? - We have a short compression example in the article
[{'time_signature': 'cut'}, {'number': 563}]
:2- Why do we put 'number' instead of 'count'? It gives information on the numbering (more on the 'logical' side), but the length of the piece is harder to read if we have - let's say - a split measure. Wouldn't 'count' be more robust?: see Mathieu's answer- 3- In the first measure, the
count
is not mentioned. This is not a major problem since we can easily deduce its default value is 1. Nevertheless, current json schema impose that we have at leastcount
orid
: should we reconsider this, or allow compressed versions only to break the rule? (or add counts to compressed!)
Defaults values for non-verbose version
For each key in the schema, we can define default values so that only 'important' keys are needed. (This is different to 'compressed' version which also erase entire unnecessary measure). Besides, could some of these default values be part of the schema?
Current proposition:
count
:<previous 'count'> + 1
, and to 1 for the first measure (cannot be overridden)id
: defaults to current 'count' (converted to str)number
: defaults to<previous 'number'> + 1
, and to 1 for the first measurename
: defaults to currentnumber
(converted to string) ; if previousname
is in the form of a number followed by a single letter (e.g. "19a"), the same letter is added on current name ("20a") (edit: see #3 (comment))time_signature
: defaults to the previoustime_signature
, and tonull
for the first measurenominal_length
: defaults to4.0 * numerator/denominator
based on current time signatureactual_length
: defaults to currentnominal_length
qstamp
: defaults to<previous 'qstamp'> + <previous 'actual_duration'
, and 0.0 for the first measurestart_repeat
: defaults to Falseend_repeat
: defaults to Falsenext
: defaults to[<current 'count'> + 1]
, and to[-1]
for the last measure
A verbose version can be easily built by iterating on each measure to add default values for missing keys -- in the order above ; using both previous and current measure's info.
Any changes to consider before integrating this as official specs?
Start_repeat and end_repeat
I regroup few issues or questions about handling the repeats keys (start_repeat
and end_repeat
)
In this file, measure 8 mentions (accurately) "end_repeat": true
and continues to measure 1; however, measure 1 have "start_repeat": false
. It should be true
, right?
Similar issues appears in _measures.tsv
files from ms3, like this one (line 21 should have a start
repeat), but the problem is more on the side of Musescore file conversion. As a first step, the Measure Map extraction doesn't aim at fixing these errors: we explicitly take what we have, without trying to be smart. However, it should be nice to detect that "our measure map has some repeat issues".
Especially, the start/end_repeat must match the next
lists. Is it always true that :
"count": 18, "next": [11, 19]
implies that :- current measure (18) has
"end_repeat": true
- measure
11
has"start_repeat": true
- current measure (18) has
"count": 18, "next": [19, 23]
implies that there is a second ending
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.