You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when excerpts are generated, the relevant clef, time signature, key signature and, if present, harmony label are copied from the preceding context. This is achieved be looking up the preceding XML element via the event column of the events table and then passing the relevant information to the Excerpt.__init__().
This behaviour should also include tempo markings, of which there are two types:
verbal tempo indications such as Allegro that encode a tempo in terms of quarter notes per minute (qpm)
metronome marks that display the tempo in terms of a beat unit (e.g. halves, dotted quarters...). Internally, metronome marks convert the shown value to qpm.
Considerations
The fact that metronome marks are able to indicate the beat unit gives them an unbeatable advantage for music research. Maybe this is a case for introducing a parameter that let's the user choose the desired behaviour. Copying in from a discussion for time reasons:
The easiest solution would be, just copy the previous one, whatever type it is. If it happens to be a verbal tempo mark, you're missing the base unit that would have been included in a metronome mark. So then, if there happens to be a metronome mark at an earlier point, is it sensible to use its beat unit and convert the new tempo of the verbal indication according to it?
Or do we say, well in case at least one metronme mark is present, then the snippets copy that by default?
If the most simple solution does not serve the purpose and [we] decide to dive a bit deeper, I think the way to go is to make it an argument that allows for choosing
the simple behaviour or
giving preference to either metronome or verbal, or
trying to always construct a metronome mark be converting later verbal indications to the preceding metronome's beat unit.
here for a <Harmony> tag (only a single one, no matter the staff, which is what we need here: Tempo markings can occur in any staff but affect the music globally)
The mechanism used in these is to copy the values of child tags from the relevant columns in the events table and passing them to the Excerpt object. The events table reflects the XML structure with /-separated XML paths in the columns (e.g. Clef/concertClefType meaning a concertClefType tag within a Clef tag) and non-empty cell values indicating the presence of such tag. Tag properties are encoded in an additional column with the property appended with a :, as in offset:x meaning <offset x=value> (discarded by the current code).
Another mechanism is, of course, conceivable, e.g. by retrieving the actual XML tag based on the mc_onset in the events table and passing a copy of the entire tag to the Excerpt if that seems easier. This solution, however, makes it more difficult to create an Excerpt object "by hand", which the given solution that creates a new tag based on a key-value dict enables.
The rest, then, is a matter of picking the desired Tempo object based on a parameter. It is highly recommended to first collect all possible cases (presence and absence of either type plus all combinations of behaviour arguments) and to design rather small dummy test files which, taken together, can cover all these cases.
The text was updated successfully, but these errors were encountered:
By the way, here is how the parser currently processes <Tempo> tags when including the information in the extracted chords table. It would be beneficial if the new code reflected the same terminology used in the respective TSV columns:
qpm "quarter per minute", the 'normalized' tempo
tempo the tempo text or full metronome mark
metronome_base for the metronome's beat unit
metronome_number the number indicating the tempo in [beat units] per second
Currently, when excerpts are generated, the relevant clef, time signature, key signature and, if present, harmony label are copied from the preceding context. This is achieved be looking up the preceding XML element via the
event
column of theevents
table and then passing the relevant information to theExcerpt.__init__()
.This behaviour should also include tempo markings, of which there are two types:
Considerations
The fact that metronome marks are able to indicate the beat unit gives them an unbeatable advantage for music research. Maybe this is a case for introducing a parameter that let's the user choose the desired behaviour. Copying in from a discussion for time reasons:
Avenues
The same mechanism applies that's already used
The mechanism used in these is to copy the values of child tags from the relevant columns in the events table and passing them to the
Excerpt
object. The events table reflects the XML structure with/
-separated XML paths in the columns (e.g.Clef/concertClefType
meaning aconcertClefType
tag within aClef
tag) and non-empty cell values indicating the presence of such tag. Tag properties are encoded in an additional column with the property appended with a:
, as inoffset:x
meaning<offset x=value>
(discarded by the current code).Another mechanism is, of course, conceivable, e.g. by retrieving the actual XML tag based on the
mc_onset
in the events table and passing a copy of the entire tag to theExcerpt
if that seems easier. This solution, however, makes it more difficult to create anExcerpt
object "by hand", which the given solution that creates a new tag based on a key-value dict enables.The rest, then, is a matter of picking the desired Tempo object based on a parameter. It is highly recommended to first collect all possible cases (presence and absence of either type plus all combinations of behaviour arguments) and to design rather small dummy test files which, taken together, can cover all these cases.
The text was updated successfully, but these errors were encountered: