Marking-defining parts A, B, C etc for further use in the score.

• Mar 13, 2018 - 05:33

Many scores have complex repeat structure that involves repeat of certain sections, for example A B A d A d A B

No one likes spaghetti-like score, a complex maze of jumps and/or turning pages during performance. Compact scores are treasured by performers.

It would be nice if we can LABEL (or define) "section A-A" "section X-X" etc.. from their beginnings to their ends and then be able to recall these sections at any time later in the score, indicating the correct number of bars that the repeat actually takes to maintain the correct bar count.

I am sort-of doing it in my compositions (example included), but it is awkward and there is no playback - only multi-bar rests.

Defining re-usable "code fragments" is the essence of all programming, so perhaps this principle could also be included in computer-based music score generation and presentation. Musescore is in a good position to lead the way and introduce a new modern repeat notation...

Defining and then recalling score fragments should be much "more convenient" and much "more versatile" alternative to jumps...

Thank you for your help
Tom

Attachment Size
Fantazja7+compact.pdf 151.58 KB

Comments

• Mar 13, 2018 - 07:40

It is hard to say whether or not this should be incorporated into MuseScore, because it is not part of standard notation, which only uses DSes. However, I do often see pop and jazz charts which operate as you describe, and trying to describe some complicated forms using only DSes can be problematic, so maybe it makes sense to adopt this practice too.

Reply

• Mar 13, 2018 - 16:45

In general, MuseScore is more in the business of supporting standard notations than trying to invent new ones. That said, these sorts of notations aren't that new, and we do already support them using the built-in facilities - but indeed, you won't get playback of such non-standard notations. There are some major improvements to MuseScore's ability to follow complex roadmaps coming in 2.2, but further down the road I could definitely see also adding a facility to identify sections and create "playlists". Playback remains very much secondary in important which is why these things tend not to be prioritized highly, but I do see as something that may come eventually.

Reply

• Mar 13, 2018 - 19:39

Marc,

Of all features of the standard notation, repeat functionality is the most annoying and the most confusing for both composers and performers.

Even simple repeats are a problem, because they are (theoretically) ignored after DS and other jumps. There is no way for composer/arranger to communicate that selected "simple repeat" needs to be executed after a jump.

When using the standard notation repeat functionality rigidly it is frequently impossible to define the precise timeline of the music unless a "spaghetti" method is being used (explicitly writing all repeated segments, forcing multiple page turns for performers).

By marking and re-using score segments, we can easily define the timeline. When timeline is defined - programming playback is trivial. Playback is only a problem when the timeline is either undefined or ambiguous.

Reply

• Mar 14, 2018 - 00:33

Neither jumps nor repeats can be nested without creating ambiguities and confusion about the timeline.

The simplest way to define a timeline is what computer programmers had already perfected over many decades : define a piece of code (score) that is to be reused, give it a tag and then use the tag wherever the tagged segment needs to be repeated. No ambiguities and the greatest freedom of repeats, also leading to compact/concise scores that are very easy to read and write.

Have you tried to use a jump to a Segno ahead of a repeat with multiple voltas? Result is very confusing. We need to simplify things, not complicate them.

Reply

• Mar 14, 2018 - 14:07

While I definitely agree that reusing tagged segments has its uses, it is imo not possible within the current codebase without introducing new elementtypes (both to mark the segment as for the replay of it).

As soon as #270332: multiple jumps with playRepeats gets merged you can however get pretty close using minimal timeconsuming jumpmeasures. The basic idea is to use a Segno for a start-of-segment marker and a ToCoda as an end-of-segment marker. The replay-segment is then performed by having an additional measure (your current MMrests) with the shortest possible duration (1/64th) which uses a DSalCoda for it's jump logic. Additional coda markers have been inserted to allow the continueAt setting of the jump to pick up again after the segment repeat was performed.
I've added a hidden unplayable note and lyric to the repeatSegment measures to ensure automatic spacing leaves enough room for the jumpmarkers. Also hidden tempo-markings were added speeding up the playback of those 1/64th measures to 400bpm resulting in a nearly inaudible pause between the end of a segment and the actual replay instruction.

Attachment Size
270303___replay_section_marker.mscz 11.96 KB

Reply

• Mar 14, 2018 - 14:12

To make it even closer to what is mentioned in the original post, as long as you use the jumps & repeats palette to enter the text, you can change the text to anything you like. This allows you to change the "D.S. al Coda" to "Play Section A" if you want and so forth.

Reply

• Mar 14, 2018 - 22:39

If you try to "nest" repeats with multiple jumps the score becomes utterly confusing for both composer and musician. It becomes impossible to distinguish between multiple Segnos and Codas. If you try to make jumped repeats with several endings things get even more confusing, In contrast, tagged segment repeats offers total freedom of repeats with no ambiguities and no confusions.

Once you wrote and tagged segments A and B and endings E1 E2 you can write a "playlist" A E1 A E2 A B E1 B E2 for example. This dramatically shortens the score and eliminates all timeline confusions.

Tagged segments can be highlighted so that it becomes obvious for musician what to do. Let's try to admit that it is 21st century....

Reply

• Mar 14, 2018 - 23:03

I'm not sure what triggered this response. No-one here argued that it wouldn't be useful, most even voiced their support for such a feature.

All I stated was that its not a trivial change to the codebase to make this happen, so don't expect it very soon unless some developer is passionate enough about it to contribute this.

Similarly I showed you a fairly doable workaround that'll function as you expected and you'll be able to use in the next release; which is expected in a matter of weeks. You're entirely free to use or not use this workaround as you see fit.

Reply

• Mar 15, 2018 - 06:08

Thank you for the upcoming workaround.
I still think that the existing repeat system is the most awkward and confusing part of the standard notation.

As a computer programmer since 1975 I suspect that the current repeat system creates many programming/communication headaches and involves lengthy debugging simply because the rules are confusing to begin with. A simple tagged repeat solution is a simplification from the programming point of view, not a complication. Just try to mention it to any software developer.

I apologise for any inadequacy of my responses... Tom

Reply

• Mar 15, 2018 - 06:20

As I stated before, I am in favor of musescore eventually being able to express repeats according to a tag-like system. (The tags could even just be rehearsal mark names). As that is how much communication is done in pop world (and even jazz) where musicians will express charts about playing particular sections a certain number of times and in a certain order, instead of communicating with DSes. But one of the difficulties will be making sure such a system works nicely with the legacy DS system. And also figuring out precise meanings of what consitutes a tagged section. Like if there are repeats in the tagged section, possibly even with voltas of their own, or if user puts tags in wierd places like inside of a volta, then things can get just a bit tricky.

Reply

• Mar 15, 2018 - 06:34

I suspect that when tagged repeats work - after a while people will likely avoid legacy system, because the tagged system conveniently replaces voltas and nested repeats by a simple "playlist".

If I programmed the User Interface, I would select a number of measures, right-click to define "properties" which offer a named tag, highlight options, marker options, colors etc... In the repeat menu I would have a "repeat tag" that can be inserted into the score with Inspector properties defining specific tag. In the score, repeat tag would display previously defined tag name and look like N-measure rest to keep the measure count.

Have a look at my attachment in my first post to see what I mean.

Reply

• Mar 15, 2018 - 08:39

> "select a number of measures, right-click to define "properties" which offer a named tag"

What you describe there is more of a "range" and not a "tag", in the most common used terminology. I still think just using rehearsal marks as the identifiers would suffice, then don't need a new system for "tagging". In most cases I experience, the space between rehearsal marks basically defines a recalled sections that gets called later. So I wouldn't invent a new tagging system...just let a rehearsal mark define the region between it and the next rehearsal mark (or the next repeat tag element). In fact, looking at your score, with the exception of D, all the sections last from one rehearsal mark until either the next section or an indicator to repeat an earlier section. For the rare occasions like your D section that don't go all the way, I could imagine the user could simply put an invisible rehearsal mark at the end of the section. Instead of making a new system.

> "In the repeat menu I would have a "repeat tag" that can be inserted into the score"

Ok. I can imagine that a repeat tag could either be a HBox or VBox for user to put text in. Or a repeat tag could simply be a text element that is placed at the end of a measure similar to the DS element.

> "N-measure repeat"

I can imagine some people might want to have the repeated section be displayed as a multi-measure repeat. But I can also imagine other people, myself included, who would just want a simple text without any staff or repeat measure rest (and I might not even want to have the repeated tags increase measure number count...although some might disagree...but whether or not measure count gets increased could be a simple checkbox flag).

Reply

• Mar 15, 2018 - 09:17

You can call the selection a "tagged range". It needs to have beginning and end and be somehow distinguishable, highlighted, framed, colored, shaded etc... You should be able to "name" this tagged range the way you like it. Then you can "recall" this tagged range anywhere in the score any number of times.

You can define as many "tagged ranges" as you like to make the score as brief as practicable, but enjoyable to read.

Reply

• Mar 16, 2018 - 14:20

In principle this seems like something that could be attached to the experimental "Timeline" feature that was developed last summer for Google Summer of Code. Currently I don't think there is anything there that would allow this directly, but it is probably the appropriate place to hook in a UI for it. Feel free to check out a nightly build of "master" branch, play with the timeline, and see if you make a concrete proposal for how this could be extended.

Reply

• Mar 16, 2018 - 22:42

My proposal is to extend existing features while simplifying things.

Musescore already supports "selection". Currently, Inspector offers Users a choice of colors and visibility of a selection.

The first step is to give a "selection" more properties via Inspector.

The most important extra property is the selection NAME - the name used to refer to the selection. Internally NAME should be associated with start and end notes (or rests) in the selection. Such association allows editing of the [NAME] selection content without need to redefine [NAME].

Once User enters NAME and exits the Inspector, start and end pointers are inserted in the score in the format [NAME...] for start and matching [...NAME] for end - above start and end notes (or measures) in a large bold font. (I used rehearsal marks and edited text inside)

Then User can then enter [NAME] as a text associated with empty measure(s) anywhere in the score.

Exploring [NAME] text properties should invoke Inspector with properties of the actual selection called [NAME].

That is the minimal required User Interface to satisfy composers and musicians.

Internally, when Musescore enounters empty measure(s) with [NAME] during playback (or audio export) - the playback is redirected to the actual selection and then redirected back to the score that follows [NAME] measure(s) after [NAME] playback finishes.

To keep the measure count correct, User can use a multi-bar rest of the same duration as [NAME]. Please see the attachment to my first post in this topic to see how it looks.

As you can see modifications are really simple... :)

Reply

• Mar 21, 2018 - 03:18

"SELECTION" is a fundamental existing feature of Musescore. Can't you see the simplicity of giving a selection NAME in the Inspector? This is ALL THAT IS REQUIRED for complete flexibility of repeats.

Why do you assume that some non-tested and non-published complex feature is more useful and needs to take precedence?

Let's try to simplify things and begin asking computer programmers what is easier to implement... Tom

Reply

• Mar 21, 2018 - 07:34

"SELECTION" is an essential functionality Each an every "editor" on Earth today, regardless whether the editor edits text, music scores, sound, photos, images, drawings or anything else . "Selection" facilitates many convenient operations such as cut-copy-paste for example. Without "selection" and operations that "selection" facilitates - any editor becomes next-to-useless.

For this reason "SELECTION" is a fundamental feature of Musescore even if you cannot yet see this.

Reply

• Mar 21, 2018 - 08:50

Let's try to simplify things and begin asking computer programmers what is easier to implement...
As a programmer I can definitely say that the thing that already exists and has been written is easier to implement.

Again as a functional programmer, allow me to skip right past the UX of how to define these regions and move straight on to how to implement them without breaking the current jump&repeats implementation (which is very much required and can't be ignored!)

Starting of from the example file I posted before, the only thing that should require a change to make this function work; is to replace the current workaround short-measure-with-jump-and-return-marker with an actual new 'replay region' element.
In my view the new element should be an inheritance of both MeasureBase (for rendering purposes and influencing measure count) and Jump (because that's what needs to happen) with an additional text property.

Actually I'm wondering whether such an approach couldn't also be used to implement #10220: Add a two and four measure (multi-measure) repeat sign with playback in one go. There you'd need two more things:
1. The ability to choose for using the x-measure-repeat symbol (auto-generated then) instead of a text
2. The ability to have the playback marker stay in this new MeasureBase element and show beatprogression there rather than have it actually jump back to the measure(s) it is repeating.

Reply

• Mar 21, 2018 - 09:00

I like your idea of having a "replay region" be based on measure base.

However it shouldn't handle multi-measure repeat. Because a multi-measure repeat only affects the particular staff it is on, so not all staves may be affected. Anyway I had implemented that a long time ago, but the PR got hung up because of some questions about how the MusicXML import and output should be done.

Reply

• Mar 21, 2018 - 12:05

Repeat x-measures is restricted to measures immediately preceding the repeat sign. Marking and naming region is more universal and offers repeat of marked regions anywhere in the score any number of times.

Current jumps have 3 parameters: jump to 1 , play until 2 and continue at 3. Named region identifies locations 1 and 2, so that they can act as pointers associated with the name of the region. Specifying continuation is not required because it can be assumed on the basis of the place where the named region is called.

Musescore offers "lines" that can identify regions just like voltas. But a line that spans half-a-page would unnecessarily clutter the score... Since some lines clearly identify start and end of a region, maybe we can use the volta-line concept but without actual line connecting start and end of selected region?

Reply

• Mar 21, 2018 - 20:33

I'm against using lines to identify regions, because there would not be a visible line drawn for the region, and I think a general rule of thumb is it better to have score elements be visible ink when possible. I'd much rather reuse the current element of "marker" (and "rehearsal marks" if rehearsal marks can be treated as makers) for defining regions, whereby the user can simply place a marker at start of section, and then a new marker at start of next section (or put an end marker if a section ends early before first measure of the next section). User is already going to be putting in a visible mark of some sort to identify each section for the human performer.

Then whenever a "replay region" element is encountered, it may playback that region, and optionally add the number of measures.

Still things get complicated when have jumps inside of a region...should they be taken? And repeats inside a region...I guess maybe have an option to "play repeats" just like is now available for jumps. And care would need to be taken if there are unbalanced repeats signs in a region, or even if there was a "replay region" element inside of a region.

Reply

• Mar 21, 2018 - 20:49

I would suggest using something like jumps from the jumps and repeats palette that can have a start and end position defined much like codas and segnos are defined. They can look like a rehearsal mark, and may even be used as one but they would have jump fields. I don't think it is unreasonable to allow the user to select a region and have an interactive dialog pop up to define the range with the end of the range resembling a line break in color that would mirror the looks of the start that is a visible item.

Reply

• Mar 21, 2018 - 21:04

I'm not against user selecting a range of notes, and then dropping something from the pallete onto that region which would place a marker at the start and end of the selection to define the region. I prefer to reuse the existing Marker (or Rehearsal mark) element instead of creating a new element.

Reply

• Mar 21, 2018 - 21:24

That's why I suggested using a jump that already has the ability to attach a label. I would expect the labels to be something like startA and endA rather than codab. There would need to be some code added to handle the end marker, but it's not that different an idea than a D.S. al Coda. The only thing I can see needing to be added is an End Section type that would (possibly) be non visible since the beginning of the section would definitely need a visible starting marker to make sense for the musician. The end marker could be added much like a coda rather than selecting a section of music, the selection area makes a lot of sense though. Making it interactive would make it easier to prevent duplicate marker labels. Part of my idea would be to assure that if the user calls it startA there is no other startA already defined. This is not checked for with the current jump system, but would be a nice bonus so add to the current system.

Reply

• Mar 21, 2018 - 22:02

I don't see why the End Section would need to be invisible. The human performer will need to see when the section ends.

I can imagine users wanting the end marker to be right justified at the end of the final measure (similar to how the marker element for "To Coda" is right justified). I could imagine that the end marker simply be another marker like "To Coda" that is right justified, maybe with default text along the lines of "Section [X] end" and would be internally named something like "endX".

I think can reuse the Jump element for replay region...maybe allow the jump element to be placed on an empty frame...and maybe just provide an option below "Play Repeats" in the inspector which is "Replay Region", which if clicked would grey out the "Continue at" textbox in the inspector and which might automatically set the "Play until" textbox to be endX where X is the marker of the start of the region. And maybe have one extra integer option for the number of times to replay that region before continuing on, and maybe have an checkbox option for "increase measure count". Maybe even have default text as "Replay X [N times]"

So basically I'm imagining extending the jump code, rather than creating a whole new construct.

Reply

• Mar 21, 2018 - 22:19

Jumps are super-confusing if there is more than one jump in the score. Also, all simple repeats along with all voltas get completely ignored after a jump. This is not only confusing for everyone, composers and performers, but there is actually no way to let the performer execute simple repeats and voltas after a jump...

My view is that we should introduce user-labelled segments as an "independent repeat system", in a sense that there cannot be any simple repeat symbols or jump markers/commands in the user-labelled region. This should get the "labelled-region repeat" system started while preserving the legacy repeat system. Later we can complicate things, but only if we really have to.

Music analysts, historians, composers and performers label structure of compositions ABACA etc.. for centuries. Perhaps it is time to formalise this commonly-used system for the benefit of everyone. Musescore is the best system that I have seen to lead the way...

Reply

• Mar 21, 2018 - 22:33

> "Also, all simple repeats along with all voltas get completely ignored after a jump."

Actually a checkbox for "Play Repeats" in inspector is available in upcoming MuseScore 2.2 release...have you tried out the latest nightly/release candidate?

Why can't replay region simply be a special enhanced type of jump? And how is a start marker + end marker not sufficient to define a "user-labelled segment".

I'd also consider maybe having a super special type of jump text whereby user could simply write out the "Form: ABACA" which could be automatically parsed and converted into a series of commands of "jump to...play until" defined by marker elements, thereby reusing most of the jump infrastructure, rather than a completely new "labelled-region repeat" system.

Reply

• Mar 21, 2018 - 23:13

FWIW, another thing to consider is that regions might want to be identified for annotation purposes - to highlight the region in color on the score, add textual notes not intended for printing, etc. All of these things -
repeat playback, annotations, the existing timeline, etc - need to be considered together or the interface will be hopelessly cluttered and confusing.

Reply

• Mar 22, 2018 - 02:46

Of course Marc. For this reason using Inspector to give "region" various properties is the most logical.
A single note has a dozen properties, so why cannot we more properties to the selected region? The first property we need to add is name such as "A" for example. We can of course add other properties to highlight the region.

I propose [A...] in the rehearsal mark format to be a start and [...A] the end of the region. Stave/system text [A...A] should "quote" the region in various places. Even if there is no playback, this system would be a great non-ambiguous way to communicate intention of the score to the performer.

Reply

• Mar 22, 2018 - 03:50

If defining regions as first class objects with properties set in Inspector is how the timeline feature works, great! If not, again, I'd like to focus instead on how to develop functionality that seems consistent with and compatible with existing functionality. Not saying the timeline can't be altered to work better with new functionality, but the two need to be considered together.

Sorry if I'm a broken record on this, but it hasn't ceased to be important.

Reply

• Sep 8, 2018 - 18:51

It's good to see that there is support for the idea to introduce some kind of playlist facility.
It is surely not a new idea, but one which I feel deserves more attention.

I have appointed myself to be the "devoted programmer" who will try to have a go at such a feature - at least for the time being. I know that if iget stuck I can scream for help.

I have filed a feature request for this - Add a playlist facility to control the sequence of playback

But before I start out let me share some of my thoughts.

What we are dealing with is really different languages that are used to define in which order the music has to be played.

First there is the traditional notation, which has evolved over decades to become a universally recognized
way of communicating between the composer and the musicians.
As such it is characterized by having a very limited vocabulary - repeats, endings, jumps and markers - and a very strict syntax.
This means that it can easily be translated - by means of a program - into instructions to the playback engine, which segments are to be played in which order.

On the other hand we have the unstructured and informal way used in contemporary music, where the composer, or arranger, will often use plain english language to instruct the musicians how to jump around in the score. While this can easily be presented in MuseScore to be read by the human performer - it is just plain text - the lack of formality and structure makes it impossible to translate it into playback engine instructions.
To perform that translation we need to rely on the user to do it. This should be done through some kind of easy to use and hopefully intuitive Ui.

Integrating the two languages, will call for a common language, so this naturally introduces the model-view concept.
The model in this case is conceptually quite simple. It consist of just two elements. One will be a list of score segments that define the starting point of each segment. The other is simply a "playlist" - a list of segments that specifY which segments are to be played, and in which order.

We should then see the traditional notation as just one view that can be used - with the aid of the computer - to populate the model.
Another view will be the Ui that the user will use to do the same kind of specification.

From the model it should then be reasonably easy to generate the instructions for the playback engine, and also to save the information to the score file, in a defined format.

Having this model in place we may then possibly think of extending it to also give the possibility to define, for each instance of a segment, which instruments have to be played and which to be muted. This may not be included in the first implementation, but it would be nice to - at least - define how this can be included in the model and in the file format, so that it may be added later.

Reply

• Mar 16, 2018 - 06:54

I'm with ya on parts a,b, and c.... if it helps, I color code the parts different colors when I compose so I can see more easily where/what part in the song I want to select to copy/ paste in another measure of the song...

Reply

• Apr 26, 2019 - 18:12

I'm absolutely in agreement with this cool idea!!!

As any other piece of software in the today world (as it had been since the 16 bit computers age), MuseScore should have a very easy to use SECTION SELECTION command with a lot of capabilites (not only cut, copy and paste).

MuseScore could use the today REHEARSAL MARKS adding new capabilities (such the repeats time line, different colours, etc.) and, even more, the most important thing, MuseScore should use those sections as they were independent music pieces inside an only one piece!!!

Please, this idea isn't new in the MIDI software world!!! I used it with the old Cakewalk Home Studio in MS-WIndows 3.11, centuries ago!!! If this characteristic worked so fine at that time... Why not today? ???

Reply

• Apr 26, 2019 - 19:26

Allow me to just pick in on one statement specifically, as I've seen you assume it repeatedly over your past posts.
MuseScore is not a MIDI-oriented program
It isn't a sequencer, nor a raw MIDI-editor. It's engraving software which just so happens to also allow playback review and leans on rendering its internal info into MIDI, as that is an industry standard for creating playback information.

While yes, it can borrow useful features from the MIDI sequencing/software world; MuseScore itself isn't quite fully part of that world, which is the most obvious answer to why it doesn't include most of the common MIDI-editor toolset.
MuseScore doesn't edit MIDI-data, it edits a score and exports/renders it to MIDI-data.

Reply

• Apr 26, 2019 - 19:40

jeetee... I know it very well!!!

What I'm saying is... If the old, commercial, industry, not open/free MIDI sequencers software world has some helpful tool to the today musicians... Why not to use it? ???

If MuseScore starts to use some of those tools (or all), it is not meaning that it will abandon its main target (the visual presentation of the music), NOT!!! One thing it isn't against the other.

That's all what I'm saying.

Reply

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