`.measures()` to accept `stream.measure` objects?

cuthbertLab / music21

music21 is a Toolkit for Computational Musicology

https://www.music21.org/

Other

2.13k stars 402 forks source link

`.measures()` to accept `stream.measure` objects? #1517

Open MarkGotham opened 1 year ago

MarkGotham commented 1 year ago

Motivation

The stream.measures() method currently expects start and end measure numbers.

That's fine until the measure number in the score is complex. E.g., multiple movements or sections, each starting from number 1.

Feature summary

Either accept stream.measure objects instead for those cases where you have already identified the relevant objects (e.g., having run an iterator search).
Or accept measure count (the Nth measure in the successive list of measures)
Or both?

Would that be helpful to others? I find myself writing wacky workarounds.

mscuthbert commented 1 year ago

These are all good ideas -- I think though that we should probably have a separate method for at least the first if not others -- why? For symmetry, I eventually want .measures to work like .parts (and .voices, .scores) and return a StreamIterator, but (for backwards compatibility) add a __call__ method to that Iterator which returns the excerpted score.

If a score has multiple movements, it seems best to use an Opus object and store each movement as a Score, so that you'd do s.scores[2].measures(11, 20) to get the right one. If you have the Measure object already (suggestion 1) then why not just run m.getContextByClass(stream.Score).measures(m.number, m.number + 10)?

(just a note for the future, would you mind using the suggestion template? I'm tracking which are ones that I need to return to and which are here for community discussion).

MarkGotham commented 1 year ago

Thanks. Quick answers:

+1 for measures working more like parts: that would be helpful for intuition. I remember getting confused by then when I started on m21.
m.number drops, so you end up with multiple cases of measure number 1, 2, 3 ...
suggestion template: Happy to though GitHub is currently presents me with a choice of Bug report or Feature request. Am I missing something?

Thanks again.

mscuthbert commented 1 year ago

This is probably a feature request, no? It's something the system doesn't currently do and doesn't advertise that it should do it, but you'd like it to do. :-)

MarkGotham commented 1 year ago

Ok. I took your comment to mean that "suggestion" was a third category of template after "Bug report" and "Feature request"? I now guess you mean the suggested template provided for "Feature request"? If so, I omit the "Proposed implementation" because I don't have one, and the "Intent" because none of the options quite do it. How about:

[X] I'm happy for anyone else to work on this. I'm also prepared to work up a PR if

that's welcome in principle,
welcome now specifically, and
there's reasonable clarity on what form that should take.

Otherwise, I'm simply flagging it up.

Or should these suggestions start life on the google group?