johentsch
commented
4 years ago Separators are not necessary because the rule is to sort changes in descending manner: Since 13 is the largest possible interval, parsing is always unambiguous. The suggestion with additional parantheses and commas look less streamlined, too.
I think it is not necessary to have the regex check for validity of changes.
Instead of an overloaded omit I have suggested elsewhere to allow -, which would be a logical correspondence to +. It is true that - is used for separating alternatives but IMO it would be worth it to overcome this problem. Either by adapting the code that splits the alternatives (downward compatible) or by replacing the alternatives-separator (would not be downward compatible).
fabianmoss
I think we should change the representation of chord extensions a bit. So far, we put everything in parentheses, e.g.
(b9),(64),(247).If I remember correctly, this was more or less a pragmatic decision to facilitate the annotation. From the viewpoint or parsing and analyzing the chord symbols, it would be better to separate them, e.g. by using one pair of parentheses for each chord change, e.g.
V(6)(4)or separate them by commas, e.g.V(6,4). I prefer the latter.I am talking here about the internal representation. We can still introduce a fixed and clearly defined set of abbreviations for common chord changes,
(64)=(6,4)` to make the work of the annotators easier.Moreover, I would like to introduce
omitas another prefix to chord changes. So far, we can have things like(b9)or(#11). In the REGEX, this would look something like(b?|#?|omit)\d*. We could also replace\dby[1-13]to avoid nonsensical alterations such as(99)and might catch some typos this way.I can implement this if we agree on this change.