Meterless mode

• Jul 24, 2016 - 20:28

I've done a bit of searching through the forums and have found a few old discussions on this subject, but no resolution and nothing in the issue tracker. But I think there are a good number of use-cases for what we might call a 'Meterless mode' in MuseScore--IOW, a mode which would disable automatic summing of note durations and allow/require the user to place barlines manually. No time signature would be required (or honoured) in such a mode, and the user could then typeset a series of measures with randomly varying durational content. While little music intended for performance would ever be written in this way, most theory textbooks, performance-practise manuals, and instrumental method books often do contain musical examples of this sort.

Attached are a couple of quick examples, taken at random from my files.

While it is now possible, using workarounds, to produce such examples, it often a lengthy and difficult process.

So, questions:

1. Has any work in this direction already been undertaken? I didn't find anything in the issue tracker indicating anyone has, but I am not as good at searching as others here.

2. What is the consensus of the developer team about the usefulness of this? I see use cases for educational users and publishers, and possibly for composers of contemporary music.

3. Would it be possible to create such a mode, given the architecture of the program, and if so, what would be the main issues to be solved? I see a need for a manual bar-line placement function, and either a way to 'turn off' time signautres, or the creation of an 'infinite:infinite' time signature. But I'm sure there are more deeply buried issues than I, as a non-developer, can see from here.

Discussion?


Comments

As far as I know no work has been done, or even any sort of formal design proposed, for any such thing - just the occasional discussion on the forum about how it could be useful.

The architecture of the program is built pretty heavily around the idea of measures, each having a specific duration. So in imagining how to present something that looks like meterless music, I think it would be best to think about how to square that desire with the reality of implementation.

One thing that comes to mind is a note input mode where you enter notes into a temporary buffer - an infinitely-long measure much like continuous mode provides an infinitely-long system - and then, when you tell MuseScore you are done with that section of music, it would automatically create a real measure of the appropriate length, split the measure across systems if necessary, etc. So you'd never actually have to count beats or use split & join, but MuseScore would still be happy internally. You could still right click the measure and see Measure Properties, etc - the actual score created would be a perfectly normaly score. It would just be a new editing mode.

This implementation could also relate to the "scratch pad" mode sometimes wished for in forum discussions - one where you can easily insert or delete notes or change their duration and have everything else afterwards shift over as necessary. Except it would be everything else in this temporary buffer. So maybe there would be two ways of exiting this new mode: one where you say you want this to be one long measure (or at most split as needed at system boundaries), and another where you say you want the music pasted into regular measures. But the editing facility itself could potentially be the same.

In reply to by Marc Sabatella

The architecture of the program is built pretty heavily around the idea of measures, each having a specific duration. So in imagining how to present something that looks like meterless music, I think it would be best to think about how to square that desire with the reality of implementation. (emphasis added)

Ay, there's the rub. ;o)

But you have triggered a new perspective with that observation, so let's see where that might take us.

A 'real' measureless mode would be ideal for users needing one, but if the program offered a workaround to produce the visual effect of such a tool--a workaroud so simple that it were no more complicated to use than a 'real' tool would be--then the problem could be considered solved. Even better would be if such a workaround could be 'automated' and given its own menu command, even if all that did was what a very experienced (and very patient) user could have done manually. I don't know if that's what you'd call 'plug-in' territory...?

So, thinking out loud a bit here: The program already makes it possible to typeset music without showing the barlines (a relatively easy procedure: click on a barline, select all similar elements, and type V to make them all invisible) and it's also possible to insert user-placed barlines where they 'should not' be.

However, what's not so easy is to space all the elements in the resulting music properly, because the invisible barlines leave the space they occupy behind them in the staff. (User-placed barlines do adjust the space around them when they are placed, OTOH.) Yes, it is possible for a user to manually adjust the position of notes before and after each real (but invisible) barline by using the offset controls in the Inspector, but this is a lengthy, labour intensive process. So as it stands, that whole workaround procedure is not a solution in a practical sense.

Two thoughts: If that re-spacing process could be automated somehow, we'd be well on our way to a solution, I think. Alternatively, I am wondering if the architecture admits of the possibility of creating a 'remove visible barlines' command, as opposed to just making them invisible? What I mean to say is, a command that would leave the 'actual' barline element present in the code, but remove its visible and spatial attributes completely. Is that sort of thing doable?

The request for some kind of 'scratch pad' or 'non-metrical mode' to enter notes has come up before. (In fact, some early music requires no meter.)

Anyway, here's some food for thought:
The way things stand now, a single note entered into MuseScore has both a musical and a graphical quality.
See this attachment:
Musical_vs_Graphical.mscz

So, one question is... should the 'scratch pad' have play back capabilities?

I ask this because under normal conditions, when entering a note, Musescore assigns a temporal value to it. To verify this, click on the note, and the status bar shows to what beat (or fraction thereof) that note is assigned. This 'temporal rigor' (as I call it) is necessary for playback. That's why cut and paste is needed for moving notes, instead of 'dragging stuff around'. Physically moving a note/rest without regard to its temporal position can have consequences.
More specifically, see this:
Temporal Rigor.mscz
...where I intentionally 'moved notes around' .... *not* copy/pasting into the correct time positions.

[BTW: The file above was posted as a reply to a forum post from someone who simply wanted to 'move a rest':
https://musescore.org/en/node/103366 ]

Regards.

In reply to by Jm6stringer

A very astute analysis. And those examples you posted are good ones to show the difference between the two aspects of what MuseScore does. How long did it take you to whomp up the example with the graphics-only staff? (I presume you did that by dragging symbols from the Master Palette?)

Anyway, my first thought when formulating this feature request was that, no, such a 'scratch-pad' or 'pen-and-ink' mode would not require playback to be useful. But the fact is, users of scorewriters are so used to playback by now that when we don't have it, we feel deprived. (For instance, that bug in the 'replace pitches without altering rhythm' tool, which doesn't play the notes when new entry is done via midi keyboard.) So it would be better if playback could be preserved for something like this. Still, I wouldn't call it a 'deal-breaker.' And if something along the lines I suggested in my reply to Marc (above) could be worked out, would that necessarily have to affect playback? MuseScore doesn't place playback emphasis on strong versus weak beats in any measure, so in theory, lack of visible barlines should not affect it.

Do you still have an unanswered question? Please log in first to post your question.