Rhythmic Slash Notation Horizontal Spacing
I'm using a recent build of v3.0
Currently the slashes line up with the quarter notes in the rest of the staves, which might have irregularly spaced quarter notes due to any number of factors. So if the rest of the quarter notes are irregularly spaced, the slashes are irregularly spaced too.
Is this correct? I think that the slashes should always be evenly spaced within the measure. I have never seen a fake book with irregularly spaced slashes under the chord changes. I like the feature a lot, but the spacing looks wrong to me and I dread eyeballing each measure and manually adjusting all the slashes.
See the attached file for a visual example. Lyrics really stretch things out.
| Attachment | Size |
|---|---|
| slash_test.mscz | 7.26 KB |
Comments
"Correct" is somewhat subjective here; there really are no specific rules for this case. But most other software I've used does things the same as MuseScore, and published music I have seen also does it similarly. You say you've never seen a fakebook with irregularly spaced staves, but fakebooks generally have only a single staff, so you don't get to see how they would handle this case if they did have content in other staves very often.
But FWIW, I went looking through my fakebooks, and the first example I found - "Beautiful Love" in "The New Real Book" from Sher Music (which was engraved by hand, not via software) - does it exactly the same as MuseScore. But I had to look at over a hundred tunes before I found any examples of charts with slashes in one staff and notes in the other - this simply is not normally done in fakebooks. It would be more common in arrangements for multiple instruments. Here, I see older handwritten scores typically using more or less equal spacing for slashes even when the measure does not otherwise align that way, but couldn't find any exaqmples of professionally engraved scores following that practice. Not that don't exist, I'm just saying, I think you are probably haven't seen this as much as you might think.
In reply to "Correct" is somewhat by Marc Sabatella
Marc, thanks for your expansive knowledge. I do not think I have seen that much, which is why I ask the question here. It just looks funny to me with the slashes irregularly spaced. I would prefer to see them spaced evenly. I was hoping others were in agreement...
In reply to Marc, thanks for your by sideways
Normally they *are* spaced evenly, because they are normally not used in situations like what you show, where there is also a melody in the same chart. Why are you using slashes at all here? Normally it's one or the other - melody *or* slashes.
In reply to Normally they *are* spaced by Marc Sabatella
I was wondering if someone was going to ask that question. I have created an svg-based sheet music viewer/animator, with various options. Users can separately show/hide each staff, as well as show/hide lyrics and chord changes. If no actual staff is visible, only lyrics and/or chords, then I display an otherwise hidden staff filled with slashes. Because it's all one score, the bar lines must line up across staves, but the slashes can still be evenly spaced within each bar.
Yes, it's an odd situation, not your standard score. And you can manually re-align the slashes, but that is a real pain in the butt, especially for songs, where there are lyrics that cause spacing irregularities in most every measure. I haven't looked at the code to see what it would take to redistribute these slashes horizontally, provide an evenly spaced alternative, a user option like the current Fill With Slashes menu item. I have bigger priorities at the moment. But even when I'm editing the full score in MuseScore, I do prefer seeing the slashes evenly spaced, even if they don't align with the quarter notes in the other staves.
In reply to I was wondering if someone by sideways
If no other staff is visible, then the slashes *will* be equally spaced, assuming you let MuseScore hide the staves rather than trying to hide them in your separate app. If you need to do it in your app for some reason, then I geuss it would be your app's responsibility to respace the slashes. But really, that's not nearly enough. You'll also have differening measure widths for no reason, other spacing anomalies.
In reply to If no other staff is visible, by Marc Sabatella
The measure widths are what they are, and if you're displaying lyrics or notes, they make sense. It's when you display only chords that it might seem "without reason". But the whole thing is in the context of the entire score. And these particular scores are continuously horizontally scrolling, one system for the whole score. This allows users to see only what they need to and to even reorder the staves vertically for different views. It can appear at the bottom of the screen, underneath a video for example, running like karaoke in sync with the audiovisuals. Vertical space is at a premium in the widescreen world. Hiding staves assists with that in a split screen situation. Many, many music fans only care about the lyrics, and most of the musicians out there are hobbyist guitarists who only care about the chords. Sad, but true.
As for where the slashes get positioned, it's MuseScore all around. I simply export what's in MuseScore. The showing/hiding is all done in javascript that's wrapped around the SVG.
To add some perspective: MuseScore.exe (v2) is approximately 26MB in size. My current javascript, which does way more than just reorder staves, and which is not yet compressed, is 177KB in size. Once it's in .min format it will be substantially smaller, possibly as small as 26KB, which is 1,000 times smaller than MuseScore.exe. But it's just a viewer/player, not an editor, so it has limitations like not resetting to perfectly even measure widths when you're only displaying chords.
In reply to The measure widths are what by sideways
I think one of us is not understanding the other. Of course often one doesn't care about anything but lyrics. What I am saying is if you want to display a score liuke that, then *let MuseScore generate the score like that*. Don't take a correctly spaced multi-staff score and then expect that same spacing to work if your app hides on of the staves. It won't be correct. Not sure how else to explain that. if you let MuseScore export the score with slashes only, they *will* be correctly spaced.
In reply to I think one of us is not by Marc Sabatella
1) Lyrics require alignment with their notes in a staff. They are often the primary reason for different measure widths. Plus the slashes staff would need to have a copy of the lyrics from the notation staff, and that would not work if the melody is not all quarter notes, would it? You'd have to completely recreate the lyrics with multiple syllables/words per quarter note. From an animation perspective, it's even worse, as you're forcing the grouping of syllables at a quarter note level. That's way worse than varying measure widths, IMO, and it won't even solve the uneven spacing of slashes unless you're using syllables of exactly the same width, which is unlikely even if you use a monospace font.
The measure widths issue only applies to a chords-only view.
2) If I want to export such a chords-only view, then I must also copy the chord symbols to this slashes-only staff from the top staff in the score. Or I need an entirely separate score for this chords only view that provides me the sole benefit of the measures all being the same size (assuming they're all the same time signature).
3) You're misunderstanding how my code works. I export SVG from MuseScore. I then use javascript in a browser to show/hide, reorder, and animate the staves. I use one .svg file, and one .mscz file to provide all of these views via javascript. I only export the score once, with all the staves visible except the slashes stave, which is visible, but below the bottom of the page.
I could add baggage to the javascript and the publishing process if I exported a separate SVG file for chords-only viewing. From my code's point of view, that's is the option that you're suggesting to me. I don't think the measure widths are that big a deal in the context of the full viewer/player. We'll see how that turns out. It would not be that hard to do in the code. It would require caching this additional chords-only .svg file, and all of its animation cues. As I said, baggage. But if it turns out that it's just plain ugly or weird, then it might become a requirement.
On the other hand, if the horizontal spacing of the slashes becomes a manual adjustment nightmare, then I might be forced to create a lyrics+chords+slashes-only score and deal with that in javascript. But as I mentioned above, I don't see a way to make that work properly and achieve the evenly spaced slashes. Either I compromise the lyric's rhythm (all 1/4 notes), or I don't get even spacing (if I keep the notation staff for the melody, but make the staff lines invisible, etc.)
So I don't have a real solution at this point, beyond manual adjustments to the slash positions. Unless you can show me how to produce a chords+lyrics+slashes-only score with evenly spaced slashes and properly spaced (and timed) lyrics.
In summary: For me, the horizontal spacing of the slashes is a much bigger issue than the measure widths.
In reply to 1) Lyrics require alignment by sideways
Yes, if you for whatever want a score that has slashes and chord symbols, then you need to create a score that has slashes and chord symbols. Seems a no-brainer to me. Just like if you want it to have notes and lyrics, it needs to have notes and lyrics, etc. I don't get why you'd even consider not doing that?
Might help me understand if you stepped back and explained what you are actually trying to do in a "big picture" sort of way - assume I know nothing about your application or what its intended audience is or how you envision it being used.
I'm assuming, you have an app that, for reaosns known only to you right now, takes an SVG generated by MuseScore but then tries to change things about it that rewquire knowledge of music layout to change so that it looks differently than MuseScore intended it to look. So you are basically writing your own music layout program, except it uses SVG as input instead of a score. Seems way harder than just generating the score you want in the first place. Presumably there is something about your particular intended use case that makes simnply generating the score you want in the first place not seem like the obvious solution, and that is what I am trying to understand here.
In reply to Yes, if you for whatever want by Marc Sabatella
FIrst: I just tried what you suggested, hiding all the staves except the grid staff (using the Edit Instruments window and the Visible checkbox for each staff in the right-hand list). The slash spacing does not change, and neither does the layout of the bar lines.
The problem with a separate slash-staff-only score is that the bar lines don't line up with the other staves in the score, and thus don't line up with the lyrics. There is no way to make a score with a slash-only staff that has evenly spaced slashes and reasonable lyrics. Show me how if I'm wrong. The only way I see is to manually adjust each individual slash that is uneven.
Second: Everything I need is embedded in the SVG that I export from MuseScore. It's not your built-in SVG Export, I've added animation cues and layout data such as staff height. That's how I can re-order and show/hide the staves. But each staff looks as it does in MuseScore. And again, I see no automatic way to create a slashes+lyrics only staff where the slashes are evenly spaced, much less formatted properly and connected to the correct MIDI tick inside MuseScore. I am stuck with oddly spaced slashes or manual adjustments, or writing code to create an option so that this happens, the calculating of horizontal offsets for each slash, by measure.
As for why I'm using SVG: it's the universal graphical language for the web. This is a web-based, streaming media player. Media includes audio, video and SVG.
Sorry for all the edits, but it's taking me longer than I thought to respond to everything you're asking. I want to give the user options for viewing the score. Creating a separate score for every possible combination of staves in a 12 staff score is not plausible. So I use a single, full score, and show/hide/reorder/scroll/etc.
Maybe this needs to be clarified too: If I display lyrics without notation, it has no context. It really needs a "grid" staff, which is what a staff full of slashes is. The words are just scrolling on by. They need a bouncing ball, which is essentially what the slash staff is.
...and let me end by saying that I don't want to blow this out of proportion. This started as an inquiry possibly leading to posting an issue or feature request. It's a pretty minor point in the scheme of things, and adding lyrics to the mix complicates things dramatically. As I said, I haven't looked at the code yet, maybe it's a simple calculation and application of an offset. I am pretty sure that this is not be a priority for any developers or users but me, so I don't expect anyone else to put their time or energy into developing this at this time.
In reply to FIrst: I just tried what you by sideways
Hmm, spacing for slashes should definitely revert to equal if the other staves are hidden. Looks like you've found a bug - could you report it? It has nothing to do with slashes - the same is true for ordinary notes: the spacing is affected by notes on invisible staves. Seems a related issue was reported recently, but I'm not seeing it at the moment.
It works to generate parts, though, which accomplishes the same thing.
I don't understand what you mean about barlines not lining up with "other barlines in the score". The whole point of what I am talking about is that I thought you wanted to display a score that didn't *have* other staves. Again, it would really help if you tepped back and explained in plain English what you are actually trying to do.
Here's how it looks to me. Either:
1) You want to display a score that has two staves, one with notes & lyrics and the other with slashes. In this case, it is absolutely standard & correct for the slashes to align with the other staff, and that's what people who are familiar with this style of notation will be expecting; deviating from the standard will just make the music harder to read. So, I suggest you don't do it. But if you must for some reason, maybe you can generate the slashes yourself in your program.
*OR*
2) You want to display a score with one staff, slashes only. In this case, for now I guess use the parts facility to generate the staff, but do file the bug report.
Again, if you are saying you want to start with a full score but then give the user options to o things that might change the layout, then you're going to have to implement a full scale music layout program - a pretty tall order. Consider, what is a system in the full score for two isntruments has only two measures because the first staff is full of 32nd notes in the first measure - also making that first measure much wider than the second. If you then hide the first staff, the second will look ridiculous - the first measure will be a ton wider for no obvious reason whatsoever. You'd need to be able to compeltely relayout the based on the staves that are visible - which is exactly what MuseScore is already doing (except for the aforementioned bug, which I'm rather surprised to only just now notice).
In reply to Hmm, spacing for slashes by Marc Sabatella
#2 + Lyrics and/or Chord Symbols
I've been trying to explain it in the plainest English I know. I'll have a demo you can see hopefully some time this year. It's a lot better seen than explained in words.
If this bug is fixed, will it redraw the barlines so that the bars are all the same width? If so, then those barlines will not align with the lyrics when I display them together. Think about Karaoke. With words alone and no sense of when they are about to start, singers are disoriented. If you give them a grid or a countdown, then they know when to start singing. A slash staff fits that bill.
As for your last comment about strange looking measure widths, you're leaving out the context that the user is viewing the entire score. The user is the one deciding which staves to show/hide and what order they are in vertically. As a musician you should know the reason that a whole note has a wide measure when you're not displaying all the staves.
I do not need to implement a complete layout program like MuseScore. That's why it's a plausible, lightweight player. SVG and the SVG Export facility in Qt + MuseScore make it all possible. It really is pretty cool, which is why I've been spending a lot of time developing it and refining it. And this is not the only score view available. I animate vertically scrolling parts where the measures are aligned just for that instrument, a standard-looking page of music for one instrument. This flexible view is for full scores in a horizontal frame. It's a useful view.
In reply to #2 + Lyrics and/or Chord by sideways
An invisible staff is not supposed to affect spacing or anything visible at all, so yes, if what is left is only slashes, then all slashes and all bars for a given system would be equally spaced. And, unless you have fixed the system layout using breaks, the number of measures per system should also reflow correctly. This is what happens when generating parts - and the number of bars per system is also automatically done correctly.
As for what the viewer is viewing, remember, I still don't understand the context at all. I was talking about how the music looks when only one staff is visible. And in these case, it is absolutely wrong for two measures on the same system to have different widths if they have the same context, and yet this is exeactly what your system will produce if you try to simply hide one staff of a score. The layout will be wrong, and that's something would wouldn't happen if you simply generated the proper score in the first place. So that is why I keep saying it would help if you explained what you are actually doing and why you seem to be trying so hard to avoid the seemingly obvious solution.
In reply to An invisible staff is not by Marc Sabatella
The only thing I can think to add to my verbal explanation is to repeat what I said initially: This is a piano roll style of score, one very wide page with one system. The browser has a view port into the score document, and scrolls horizontally. As a plausible example, the view port might be 4-8 measures of a 100 measure score. The score scrolls automatically as the audio (recorded audio, not MIDI generated sounds) or video plays. There are additional navigation features. The user also has the ability to show/hide the staves of their choice and to reorder the staves vertically. It's one score. The measure widths are what they are. You simply have flexibility in viewing it, and it has a particular design and scrolling axis.
If I want to display a part, with multiple systems, I have a way to do that. This flexible score view is simply analogous to the MuseScore player for a full score, but with a bunch of additional features, many of which involve allowing the user to control the presentation. Because it's SVG it can all be styled by CSS, for example. And this is just one view of various views into the music. For example with the MuseScore player, if I am viewing the score for a 4-part chorale, and all I really care about in the moment are the outer voices, S and B then I have to open an alternate score. In my app you don't, and neither do you have to publish one. The user can simply hide the inner voices and continue listening to the music. They can do it during playback. This is a viewer designed to be pure web technology, pure text data (SVG, CSS, and VTT) and javascript in HTML. The focus is publishing scores so that users can view them however they like.
I don't know how to explain it any better without demonstrating it, and I'm not ready to do that yet. There are limitations. If you are so offended by the lack of measure resizing in this particular view, then you won't be a user of the player or at least not of that view. I don't think others who are interested in exploring a piece of music will be that picky. Instead they'll be pleased they can group the staves they want together and listen to the mix of parts that they choose on the fly. And they're listening to real performances, not MIDI generated tones. And if they want to see an individual part, then they can see that too, in a different view. And yes, that requires a separate svg export.
That really is all I can say about it without repeating myself. We've gotten off the original subject. I have explained what it is that I am doing in great detail. I am not avoiding anything. If you still don't understand, then you'll have to wait until you see it in action.
In reply to The only thing I can think to by sideways
Just wondering and very much depending on what effort you consider valuable for this but: slashes have always the same shape.
You should be able to parse the paths with class="Note" to find out if they match the path a slash should have. Indexing polyline class="BarLine" elements should allow you to find out which measure they belong to, after which you should be able to displace them into even distribution.
But if I read back correctly you have a custom MuseScore build for your custom svg-export? If so, adding a data-attribute to identify slashes is probably way easier than doing path detection; you could even consider data-attributing the beat of the slash and measure position/width to it. That way redistribution becomes lots easier for your viewer.
In reply to Just wondering and very much by jeetee
That's a nice idea, but manipulating the internals of the SVG at run-time at that level of detail is prohibitively messy. It would be better to simply align all the slashes within MuseScore prior to exporting the SVG. And yes, the constant size of the slash characters does make that easier.
The other piece you're missing is that I will have to determine if there is a clef, keysig, or timesig change in the measure. Those items take up space at the left of the measure, and you don't want the slashes overlapping them. A slash-filled staff won't have clefs or keysig, but it will have timesigs, and regardless, I think you'd want to distribute the slashes only across the "available" space in the bar, starting where the clef/keysig/timesig in the other staves ends.
I would not need a custom attribute because my version of SVG Export exports character codes, not paths or polylines. It assumes the Emmentaler (or Gootville or Bravura) font is present. So I could search for the XML entity  for the slash character.
In the future, using the font vs drawing all the paths/lines could be an option in MuseScore SVG Export. 1.0 exported that way. 2.0 exports w/o the font so that the resulting .svg file has zero dependencies. I can live with the font dependencies in a web page, and this method makes the .svg files much smaller and allows the user to change the music font from Emmentaler to Gootville or Bravura (or whatever) on the fly in the viewer.
In reply to That's a nice idea, but by sideways
I understand very well what sideways is doing. So let me clear some things.
1. In most of the case, I believe it's a bad idea to space slashes evenly in a measure if the other staves of the system contain different rhythm. Just like it would be a bad idea to space quarters evenly.
2. Sideways' approach might be neat but it's basically just an SVG and some CSS to hide/show/color stuff. A large part of the work is done by MuseScore where the layout engine is. So I'm afraid the SVG approach will have to live with its limitation or do some layouting itself.
3. Most of you know how I don't like options... But I believe it would be valuable enough to have an option to export fonts or not in SVG. Also, it would be great if sideways, you could consider making your version of SVG export part of MuseScore. It would make your maintenance work a lot easier in the future and we could help you without making speculations.
In reply to That's a nice idea, but by sideways
Oooh.. exporting to fonts! I like that idea quite a lot; although probably a lesser used function, having that as an export option would be nice imo. Any chance you'd find some time to create a PR for that?
Although I have quite a good grasp of how it could benefit your usage, spacing the slashes evenly in a score where for every other staff the beats are not feels .. awkard.. to me. It makes perfect sense within the context of your player, but less so within MuseScore.
I'm wondering if a plugin could take up the task of respacing, but it would probably have to be re-ran every time the score layout changes. And it has the same calculations to do as mentioned above and limitations with regards to key/time signature detection and whatever else might 'mess' with available distribution speed (good thinking about those; things are often more complex than their first glance shows).
[EDIT: so kind of what was just posted above.. blame me for not refreshing before starting my response]
In reply to Oooh.. exporting to fonts! I by jeetee
I would love to make my stuff part of MuseScore. It only adds options to the drop-down list of file formats, nothing more in the UI. But first my stuff needs to be fully ready, and when its ready it does require the Pixels/Points changes that I've been trying to make part of MuseScore already. (@lasconic knows what I'm talking about). Soon I'll be ready with demos and all that, and you can decide if you really want everything I've coded.
If you really want to preview the code itself, it's all on GitHub. My userid is sidewayss and the latest branch is called SMAWS22c. SMAWS stands for Sheet Music Animation With Sound.
As for exporting SVG that relies on the music font, again, give me some time. Right now my version of MuseScore only exports relying on the music font. I would need to make it yet another option inside the SVG Export file type drop-down. If/when it's plausible to integrate everything else we can decide how to handle that.
And yes, I agree with @lasconic and @jeetee that this respacing of slashes would be something done purely for these special exports, something done each time prior to exporting, via a plugin, or in the export code itself. Also, as I said previously, this is a minor issue in the scheme of things, even for me. I have yet to prioritize writing any such code.
In reply to I would love to make my stuff by sideways
FYI - regarding an option to export SVG using character codes instead of paths/lines:
It will require creating an alternate sub-class of SvgPaintEngine inside SvgGenerator. The reason for this is that Qt makes all the decisions about how to draw elements based on the available set of pre-defined functions exposed by SvgPaintEngine. So to draw as much as possilble using character codes, all I did was add a drawTextItem() function to SvgPaintEngine. You must remove that function entirely, AFAIK, to get Qt to draw everything using raw graphics elements like <path>.
In reply to The only thing I can think to by sideways
What I am still missing is an understand of the actual use case for your app. I'm assuming the user creates a score in MuseScore, exports it to SVG, then loads it into your app. With that assumption, I don't understand why the user would not simply generate the SVG of the score *as well as all parts*, so he can view the correct SVG of the score or the part he actually wants. If the rules of music engraving were such that correct results could be had by simply hiding staves in a score to yield individual parts, then the approach you seem to be describing would be great, but as it is, it suffers the flaw you are now seeing - layout that is compeltely correct for a score will be wrong for the parts. That's just how music notation works; it's not some quirk of MuseScore.
Anyhow, I'm not "offended" by the fact that the layout will be incorrect if you try hiding staves without laying out the remaining staves anew - I'm simply stating a fact. The fact that the slashes are no longer equally spaced is but one of *many* things that will be wrong. If you want correct layout, then you need to either have MuseScore lay out the score for you, or you need to implement your own layout algorithms - there really are no two ways around it. Without a relayout, the modified score will have incorrect layout. You can choose how much to care about that, but it won't change the fact of the matter. If you are saying the user of your app won't care, that's fine - in which case, there is no special problem with slashes. They are but one of the many things that will be wrong if you hide some staves without relaying out the remaining ones. Either the user cares or he does not.
Looking forward to seeing the app in action some day!
In reply to What I am still missing is an by Marc Sabatella
I will export parts too, for the instruments that merit it (at least for my own music). Lots of my music is electronic, so the notion of parts doesn't really make sense, as there are no human performers. This same thing applies to lots of popular music today. Each instrument might be better seen as part of a pattern within a group of instruments than on its own (see the Drum Machine / Sequencer grid concept at the bottom of this post )
If you are browsing a score, you might want to see and/or listen to a combination of parts, like the "outer voices of a chorale" example I gave before. A single part doesn't give you that. And without this code I'd have to pre-export all the different combinations of staves in advance - ouch! And that's not even taking into account that a viewer might want to reorder the staves and put the melody at the bottom and the bass on top or something odd like that. I do move the staves up and down to fill the empty vertical space created by hiding a staff, so the measure widths is the only "incorrect" thing in this view. I treat chord changes, measure numbers, rehearsal marks and other top-staff markings as a separate "system" staff that can also be shown/hidden, and remains at the top of the score regardless of which staves are displayed. I don't see anything "incorrect" except the measure widths being static and the slashes being oddly spaced.
As an aside, I even have a feature now where I publish the score with both notation and tablature staves for guitars, and there is an attribute that tells the javascript the "type" of staff, so that you can show hide the tabs/notation staves for the whole score as a separate radio button option. These are the kinds of features I'm creating: show Tabs, Notes, or Both - for the whole score. This is great for rock music where the bass is a guitar too, and lots of people use tabs instead of notation, and some of the tabs users want to learn to read notation. Thanks to MuseScore for having all the tablature features!
As another aside, and a show of how oriented towards electronic music and MIDI-based production I am, I have an entirely different style of notation that I can export that is a graphical grid like a Drum Machine or Sequencer. That's where the animation gets fun! Drum Machine or Sequencer grids are a de facto style of notation used by thousands of composers worldwide. It's great for viewing rhythmic patterns. I use the same show/hide staff code for that graphical view, so you can show/hide/reorder rows in the grid.
In reply to I will export parts too, for by sideways
Very interesting, I do look forward to someday seeing this in action!
However, unless I am still misunderstanding something basic, I think you are still underestimating some very fundamental errors in layout that will be quite apparent to suers in practice. For instance, in the example you posted, if instead of four slashes in the measure, there had been four regular quarter notes, you'd have *exactly* the same issue.
Basically, any time there is a score with multiple staves and those staves can have different rhythms, the spacing of any given staff is pretty much guaranteed to be wrong a lot of the time if you hide the other staves. That's just the way it is with music spacing - what is correct for a score is not usually correct for the individual parts. Eg, say this is your original score:
This is totally correct spacing for the score, but if you try hiding either staff, the remaining staff will look very obviously wrong. If you hide the Flute staff, the extra space between the first two notes of the Oboe staff will be wrong; if you hide the Oboe staff, the extra space between the last two notes of the Flute staff will be wrong.
Which is fine if you are thinking your users won't care, but to me this is a pretty obvious error. Which is to say, it's not at all accurate to say measure widths would be the only problem. That's really just the tip of the iceberg.
As mentioned, if you actually just mark one staff or the other invisible in MuseScore, a bug causes the spacing to still be a bit wonky, although not as bad as it would be if you simply did it graphically from the SVG file. So we're clearly allocating some space for elements on the invisible staff that we shouldnt be. As I mentioned, if you actually generate partsm, however, the spacing is correct in both cases.
In reply to Very interesting, I do look by Marc Sabatella
I see what you're saying. Let me simultaneously expand and consolidate what I said in the last post:
The only issue is horizontal spacing.
For me this issue comes up often, though not necessarily as nakedly extreme as in your example. I find that lyrics are the worst offenders because they can amplify this uneven spacing unpredictably. Add lyrics to the Flute staff in your example and it gets far worse.
As I said, there are limitations. The alternative, pre-exporting all the possible staff combinations and orders, is unacceptable, as is trying to write a layout engine in javascript with SVG. But you have to admit it provides great utility despite this *ONE* visually awkward feature that appears whenever it appears (it's not a constant). What other lightweight, web-based player lets you do all this synchronized to multi-track audio, video and interactive, animated sheet music/graphics? (re: multi-track audio, I use the Web Audio API, which is now in all the major browsers for over a year). It's like a 360 view of a piece of music, and takes features that have existed in DAW software for over 2 decades and brings them into the realm of the web browser (DAW = Digital Audio Workstation, e.g. Pro Tools). All via sheet music scores in MuseScore, which can be created via MIDI imports and even imports from other sheet music software, thankfully :-)
Maybe someday, someone will write the necessary code to realign these SVG notes/beams/etc. in SMAWS, but it's not going to be me this year. It's not impossible, and since it's limited to horizontal alignment it's not absolutely horrific in scope. But it's not on the menu today.
So you're probably thinking: "If he has a general horizontal spacing issue, what's the big deal with the slashes?" The constant size/shape of the slashes and the fact that they only appear alone, without any other staves, makes it stand out from the other situations. Plus I imagine that the karaoke-style lyrics+slashes-only view will be far more popular than mixing groups of instrument staves in unusual ways.
In reply to I see what you're saying. by sideways
For better or worse, Marc has gotten me thinking about the details of respacing notes/etc. in javascript + SVG. I already do a small amount of this, with clefs, keysigs, timesigs, instrument names/changes and tempos, it would take a while to explain why. But I do most of the numerical work (x-coordinate = horizontal location) on the C++ MuseScore export side, not in javascript.
Some thoughts:
1) It occurs to me that a combination of data in the SVG and javascript manipulation might make the whole thing more plausible.
2) Resizing measure widths makes the whole thing more complex on more than one front - it also means reloading a bunch of animation cue values for scrolling, which means more churn at run-time.
3) The first thing is to group the notehead with any stem, beam, lyric, and/or accidental. That is much better done inside MuseScore export and with attributes in the SVG. I totally forgot that for these elements (minus stems and beams) I already do this via the animation cue id. This part is easy for one-to-one relationships, so stems = easy, beams = not so much
4) Rests, note heads, stems, hooks (flags) and accidentals are relatively easy, as they simply move together horizontally. Beams must be resized, which means completely redrawn (beams are paths that draw the outline of a rhombus. vertical sides, but angled lines top/bottom). This full redraw/resize applies to other element types too, like glissandi. Both beams and glissandi are also attached to more than one note head, which adds a layer of complexity.
5) The other challenging top-priority requirement for this code is that when multiple staves are displayed, they must align in time vertically. As we have discussed in this thread, you cannot evenly space the quarter notes. I also totally forgot that the animation cue_ids are made up of MIDI ticks, which MuseScore sets at 480ppq (parts per quarter, 480 ticks = 1 quarter note). So I already have musical note duration for each note head in SVG (as opposed to timed note duration in min:sec or milliseconds). That's the first step to achieving this vertical alignment goal
In reply to I see what you're saying. by sideways
Regarding the last point, here again, understand your use case would help. In my experience, mixing ordinary staves like I showed in my example is about 100 times more common than mixing slash notation and standard notation. Slash notation tends to be used for lead sheets *without* other staves being present. And in the cases where it is mixed with other staves, it will be mixed with *multiple* other staves most of the time (eg, a jazz big band) and so you will also see the issue I showed above. There essentially exists almost no cases I can think of where there would literally be only a single other staff aside from the slashes and hence the slashes would be be the only visible issue. In the exaqmple you posted, I don't anyone who would bother including a separate staff full of slashes - that just takes unnecessary extra space. Most of the time lead sheets include the notes, lyrics, and chord symbols on a single staff.
In reply to Regarding the last point, by Marc Sabatella
As I tried to explain initially, the slashes staff only displays when the other staves are hidden and only chord changes and/or lyrics are displayed. In this flexible, full score view, users can show/hide lyrics and chords globally as well as showing/hiding individual staves or all the staves. A user can hide all sheet music staves, yet still display chords and/or lyrics, and those will animate and scroll just like the music. They'll appear at the bottom of the main window while other graphic or video fill the rest of the window.
I could create a separate export for this, but it complicates the implementation dramatically. I'll have to see how it goes with various pieces of music to see how ugly it is and/or how painful it is to manually nudge the slashes in MuseScore. A separate export might end up being the only solution for certain scores.
In reply to As I tried to explain by sideways
What I'm saying is, I can't imagine why anyone would ever create a score that looks like the one you posted. It's not the type of thing anyone would normally ever have reason to create. Which is why, again, I struggle to understand the use case. I get that *if* a user ever created a scoire like that, and *if* he then tried to hide the top staff leaving only the second, it would look weird. I simply don't understand why anyone would ever do *either* of those things. It's a strange score to create, and a strange thing to then do with a score that has only two staves. Lead sheets are almost invariably just a single staff, or two staves as needed to show a particular bass line or other accompaniment figure. A second staff throughout just for slashes is essentially unheard of. So unless you have some very unique type of user in mind, the example you seem so concerned about would essentially *never* come up in real life. Whereas the example I showed would come up 1000 times a day (assuming you had at least 1000 users - well, we'll say 1001, since surely not *everyone* creates music like that, just the vast majority of people).
In reply to What I'm saying is, I can't by Marc Sabatella
None of my scores have only two staves. But many have vocal staves with lyrics, often more than one. A user is browsing the score online, in a web browser. They can view it any way they want to. They can view a part for a particular instrument, or a multi-system lead sheet, which is essentially another part. They can also view the whole score and dynamically show/hide/reorder things to focus on whatever they want to focus on, even if other media is playing at the same time. All the media is in sync to the music.
A user might want to see: a rhythm guitar part + chord changes + lyrics (lyrics help a lot of people in bands orient themselves in the song). This is lyrics without the voice staves and notation. The only MuseScore staff is the guitar. Then they might want to add the bass guitar staff and listen to the song again. They might want to view the whole score. They might want to see tablature, they might want to see notation. Et cetera.
The notion of doing each of these possible views as a separate export from MuseScore is simply implausible. If I can provide all these views with a single .mscz file, a single SVG export, it makes the publishing process plausible, especially as something that people other than me might actually do. The single SVG file also makes the run-time code and performance more plausible. The interface might have some room to improve, but hopefully it will get the time and energy necessary to make improvements. That takes time. MuseScore is a perfect example of that.
Again, I keep explaining these concepts in alternate verbiage, but I've been saying the same thing since my first posts, in terms of the use cases and interface of this flex-view score. I don't know how to explain it any better than this without actually demonstrating it.
In reply to None of my scores have only by sideways
What I don't understand is who your intended user is. you act like I am supposed to know that your intended user works with lyrics and guitar and bass in scores of multiple staves - this is far from obvious to me. I thought we were talking about people creating lead sheets. Is your app intended specifically for rock bands? That might help me understand why you are assuming most of your users would have scores that look a little like the one you posted and why you seem unconcerned about scores that look like the one I posted.
In reply to What I don't understand is by Marc Sabatella
The rock band is just an example that's easy to imagine, as is the outer voices of a chorale example I gave earlier. It's intended to be as universal and as flexible as possible. Think of Stravinsky's Wind Octet, if you know the piece, if not you can imagine the orchestration. I would love to have access to a multi-track audio version of that (one track per instrument) and explore that piece voice by voice, and pairs of voices by pairs of voices, etc, listening to various permutations of voices/instruments as I watch the sheet music scroll by. It's intended to be a universal, integrated way to publish scores/audio/media in a way that allows users to interactively explore the piece of music in a whole host of ways, all in sync.
If you have lyrics or chord changes, and you want to display them independently of the staves they are attached to in MuseScore, all of this SVG manipulation comes in handy. Remember also that this flex view is a virtual horizontal piano roll. It can fill the window or run like sub-titles at the bottom of the window while a video of the performance plays, or while other things are animating.
Maybe it's because I have spent so much time as a programmer that it all makes sense to me as being a generic, universal thing, while still maintaining it musicality. Programmers aspire to generic universality and reusability. But your difficulty understanding my posts is also exactly why I am taking great care to make a great demo. It's not something that can be condensed into an elevator pitch, high concept. It has a lot of features to get into, and a paradigm that is a bit untraditional musically, but that fits the internet and web browsing perfectly. Seeing only one piece of it might be disorienting, you have to see the whole thing in action. I'm working on it. The fact that I'm addressing issues like the slash alignment in this one view is a sign that I'm close to an initial release. The functionality is there, I'm in the process of integrating it all into one interface and making sure it looks/performs well.
In reply to The rock band is just an by sideways
OK, if you envision it being that universal, I'll just reiterate my previous argument: in the grand scheme of things, looking at all possible users and all possible scores, problems with spacing of slashes are going to be insignificant compared to other spacing issues, because scores that combine staves of slash notation with staves of standard notation are but a small fraction of the possible scores, and the spacing problems are exactly the same with slash notation as with anything else. If you can live with it for everything else, you should be able to live with it for slashes, because it's the same problem, and the case you seem concerned about will be but a tiny fraction of all cases in the world.
But FWIW, if I were you and for some reaosn really decided it was worth the effort of solving the spacing issue for slash staves only without doing anything about the same problem for all the other cases, I'd probably provide an option in the app to hide all regular content and implement my own facility for adding equally spaced slashes instead.
In reply to OK, if you envision it being by Marc Sabatella
Midway through this discussion I came to the same conclusion about priority/importance. Especially since no one but me has even seen this thing yet. Best to get user feedback before embarking on such a project as realigning notes/bars or even just slashes.
I had accepted the basic spacing issue a while back, but in the process of displaying lyrics/chords only, without any other staves, I was compelled to add the slashes staff. And the slashes, all alone up there, with invisible staff lines because that looks better, it's as naked and obvious as the two staff example I posted at the top of this thread. I display the slashes purely as a visual metronome in this one special case. If they are unevenly spaced it's distracting from the chord symbols and lyrics, which is what you're trying to focus on.
I made this initial post hoping (unrealistically) that there might be some long established, universally accepted rule that slashes should be evenly spaced regardless of other staves. If I was able at this time to be super-precise I would also get fussy about aligning lyrics with the slashes, which is sketchy in MuseScore as it is. Evenly spacing the slashes is perfect for chords, which sit above the slashes staff, but lyrics alignment can screw it all up. I think (hope) that the timing with which they light up (animate) is more important than their precise alignment with the lyrics.
There are limitations, and if you want to get truly precise it can be a longer list than you initially expected. I think quality demands attention to detail and every nit must be picked, so I appreciate your criticisms. I'm simply not at the point of being able to implement them, and I feel that the current application requirements (which do not include respacing horizontally) provide a great first release with a ton of functionality and utility. Programming, especially in the corporate world, has made me extremely pragmatic about accepting today's limitations when the required functionality is available in one way or another. Programmers are all too used to "workarounds" to get the job done. And hope springs eternal for future features :-)
So I will manually adjust slashes in my demo scores just to see if its worth it to get them all evenly spaced, and to make the demo prettier. We'll see how it all plays out.
In reply to Midway through this by sideways
Marc (and others),
I finally submitted that issue you asked me to submit:
https://musescore.org/en/node/124826
I just wanted to link it up here and close that loop.