V2.0 - Note ontime/offtime missing?

• May 2, 2015 - 00:02

I'm finally putting 2.0 through its paces, and I have to say I'm really impressed. However I cannot find a way to control the ontime/offtime of notes, which is absolutely essential if Musescore isn't to become one of those applications that's perfect except for a single detail. I would hate to have to scrap such a beautiful piece of notation software because of an oversight.

There's some cryptic stuff in the forums about a chord articulation editor and a piano roll editor, neither of which I can find. Please--how do I control the ontime/offtime of notes?

Comments

• May 2, 2015 - 01:02

Pianoroll editor is accessed by right clicking a staff and selecting that option from the context menu.

In general, please keep in mind as always that MuseScore is a *notation* program, and focuses on being as "perfect" as it can be in that respect. While it is possible to do some fine tuning of MIDI playback using MuseScore as well, it is not the right tool for that job.

Reply

• May 2, 2015 - 12:22

I understand the "line" on this issue, and there is every reason to prioritize printed score over playback, but I put no stock in the argument "you can use some other tool to fine-tune the performance". Once you have transmitted your score to "some other tool", there is no going back; the score can no longer be altered lest all your "fine-tunings" be lost.

The beauty of MuseScore in the digital world is that the code-run-debug loop evolved by programming technology can now be applied to music; compose-play-enjoy, with pieces evolving as you find more ideas, areas for improvement, problems, etc.

To pretend that MuseScore doesn't really produce listenable output, when the truth is that it produces the most listenable and lifelike output I have ever coaxed from a computer program, isn't reality. As a matter of fact, as a musician, I find it a bit disturbing how good the output is without any possibility of articulation or phrasing. Other than genius composers writing didactic works (e.g., the Art of Fugue), the main purpose of writing music is for others to listen to: to pretend that that is not the main use of MuseScore doesn't seem realistic.

I understand the priorities, and (especially as the new Trill System is a-birthing) look forward to the day when these issues are addressed, and maybe even helping address them.

Reply

• May 2, 2015 - 19:38

I have to agree with BSG. Musescore is capable of producing good quality, musically nuanced output, as the big orchestral scores on my YouTube channel prove. And such a joy it is, too, to be able to notate my scores properly for printing, while at the same time generating musically-satisfactory digital performances to share with non-musicians. It's a dream come true for those of us who don't have a handy-dandy orchestra in our pocket to perform our works. Treating the midi side of Musescore as a second-class citizen flies in the face of actual usage, especially now that, with 2.0, there doesn't seem to be any notational idiosyncracy I can throw at the program that it doesn't handle sensibly and gracefully. I posit that with this level of notational sophistication having been achieved, it's time to reconsider the party line on midi.

Lest I forget, a HUGE thanks for 2.0! The Inspector is genius and is already saving me hundreds of hours of work tweaking my scores. Being able to change instruments in the same staff is fantastic. Positioning issues that plagued 1.x have vanished, again saving me untold amounts of time. The dark theme, which I prefer, is well realized. In truth, there's nothing I don't like about 2.0 (gate times for midi events notwithstanding). Bravo!

Reply

• May 2, 2015 - 19:27

For the record, I too was bothered by the decision not to expose the note timing properties in the same way as before - it's actually one of the *very* few regressions in 2.0 as compared to 1.3. However, the implementation of note playback has changed pretty significantly since 1.3, in ways that were needed in order to get the tremolo and ornament playback features to work. And with the new implementation - which allows for potentially multiple "events" for any given "note" - there was no completely straightforward way to expose this as a simple note property, because it *isn't* just a simple note property any more. Timing information is specific to the note *events* now.

That said, I do feel it *should* be possible in some way to alter note timing for multiple notes at once, even if it comes with a caveat that it won't work for notes with ornaments or tremolo. I had pushed at one time for exposing this via the plugin interface. See #23063: No way of controlling gateTime at present in nightlies and #25770: Expose gateTime parameters to plugin framework. That's still a possibility to consider, but it hasn't happened yet. Anyhow, do be assured that this wasn't a mere oversight nor was the decision taken lighty, and I am still hopeful to see improvement in this area. I probably should have been clearer about that in the first place :-)

Reply

• Jul 3, 2015 - 09:23

@Marc: I imagine you are more trying to convey a 'team' decision than your own ideas, but I definitely disagree (for once!) with your arguments.

A) The piano roll is cumbersome to use
So cumbersome to be unusable to most practical effects. Main reasons (in very approximate order of importance):

  1. The piano roll can edit only one part at a time; it is common (at least for me) to have to shorten the notes of all parts at a certain musical point (for instance, the third beat of a galliard or the third quaver of a 'triplet' in a gigue, or jig or however do you spell it); currently the user is required to re-open the piano roll for each part. In a 4- or 5- or 6-part piece, it takes forever.
  2. The piano roll representation has no musical meaning: trying to locate the examples quoted above in the piano roll is a Quest of the St. Graal. In the score, they are self-evident.
  3. The piano roll always opens at the beginning of the score; if you have to work at the 2nd beat of the 13th measure of the 5-th movement of your score, good luck!
  4. The piano roll can modify only one note at a time

B) Impact of ornamentation

  1. Because of ornament realisation, notes are no longer single elements but lists of event. Ok, and so? One would assume that the list of events is constructed from the main note anyway; using always and only the full nominal 1000‰ length of the main note or adding the on- and off-offset beforehand should not change the algorithm that much. In the score, I may insert a rest taking away a little bit of the start or of the end of a note and the presence of an ornament does not prevent this, does it? So, why it is so different to add an on- or off-offset to that same note?
  2. Whichever properties are attached to a note (for instance, a list of MIDI events), the note is still an 'event' in itself and there is no reason to hide this basic fact or to forbid access to it.
  3. Anyway, the piano roll cannot modify the timing of 'ornamented' notes either (neither the 'real' note or the 'added' passing notes). This is presumably a side effect of having the ornamentation 'spelt out' in full in the piano roll; which is useless, as it cannot be modified. So, the piano roll would work exactly the same without the ornaments 'spelt out' and the main note would stand out as an object in itself and it would hopefully simpler to make it modifiable.
  4. In future, the piano roll will allow to modify the ornament realisation. This would be very welcome, as no automatic ornament realisation is ever going to be satisfactory (you know my ideas about this), but there is no hint that this will happen any soon and, anyway, we will cross that bridge when we get there.

For all these reasons (and possibly other, which do not come to my mind on the spot):

*) I find the piano roll practically unusable for timing (and I bet I am not alone in this)
*) I fail to see any reason why what is possible now in the piano roll (and possibly something more) should not be possible in the Inspector, in a much simpler, quicker and musically meaningful way.

Thanks,

M.

P.S.: I am seriously tempted to re-open the issue you refer to above and push for a re-assessment of the matter, but perhaps more discussion is in order.

Reply

• Jul 21, 2015 - 23:41

Well, I decided to "take the ox by the horns" as we say in Italian and try if it can be done, without sacrificing recent developments on piano roll, ornaments and the like.

This what I could arrive at so far:

NOT FOUND: 1

showing a sample score with 4 notes, two without and two with ornaments; the first of each pair has default offsets and the second has a 10% on offset and a -20% off offset. As the piano roll shows, events follow on and off offsets, as ornaments also do (each is realized within the time frame defined by the offsets). Details of ornament realisation are not changed at all (except for the time frame and for removing the 'time gating' of individual ornament events (see my post on dev mailing list ), which is probably incorrect).

Offsets are entered in percent of note duration via the Inspector, with two additional numeric boxes in the Note dlg box.

Scores remain back- and forward-compatible with 2.0.x (and probably back-compatible with 1.3 too, in the sense that the new code is -- or should be -- able to read correctly 1.3 offsets); of course, 2.0.x scores will not be able to manage time offsets but will not choke on them.

I still have to check multiple note setting via the Inspector, but I assume it should work, as the Inspector already has code for multiple element management.

I expect the current code to miss some points; in particular I have not full understood how trills are managed and I have not understood at all tremolo realisation. But the base seems a good start.

Comments and suggestions are welcome.

M.

Attachment Size
test_note_on_off_offsets.png 11.48 KB

Reply

• Jul 22, 2015 - 00:00

This sounds promising to me! I'm not clear on how you are doing this adjustment - via Inspector? EDIT - ooops, I see now that's exactly what you said. Great!

One thing I noticed is that the ornament-generated events show in the pianoroll but are not editable there. It seems that would be a very useful enhancement as well. Would anything about what you are doing make that easier / harder to do some day?

Reply

• Jul 22, 2015 - 06:50

"One thing I noticed is that the ornament-generated events show in the pianoroll but are not editable there. It seems that would be a very useful enhancement as well. Would anything about what you are doing make that easier / harder to do some day?"

As you know, ornament events are not editable through the piano roll since a long time (there were, once upon a time, but this has been disabled, perhaps to simplify "initial" release of the piano roll, I don't know); in fact, AFAIK, there is nothing in the framework making event editing impossible, I think it is mostly a matter of devising a reasonably powerful yet easy to use UI (I don't think that simply dragging event boundaries would be enough). Also it would be necessary to distinguish between editing the entire note time gate and editing the individual note events.

Once the piano roll would allow event editing, creation and deletion, it would be possible to customize the realisation of an ornament. From this, in principle, with a part of 'automagic' (to avoid calling it AI, as I firmly believe AI does not exist!), it might be possible to extract a pattern which the user could save and reuse for other, similar, ornaments, enlarging his "library of ornament styles".

Anyway, I am not changing anything in the whole piano roll at all and, in the ornament realisation, I am only changing the initial calculation of the total time available to a note to take time offsets into account (I am also removing the 'gate timing' of individual ornament events, as quoted above, but this is a detail). So, I would guess this is not making piano roll improvements any harder (but not any easier as well).

Reply

• Jul 22, 2015 - 12:45

I checked and with the Inspector it is indeed possible to set the on/off time offsets of several notes (of course from different score points and/or from different voices or parts) at the same time.

There is only one glitch: in 2.0.0, when multiple elements of the same type are selected and some setting is different between the elements, the Inspector did show those settings in a different way (in blue and with the [Reset] button enabled); now it shows those settings without any noticeable difference; not only the on/off time offsets (which may lack some code detail yet), but any setting: is this correct for current master or did I messed something up?

(OK, I could check master out and recompile, then check my branch out and recompile again, but perhaps someone knows this already...)

Except for this point, I think I am ready to push the PR for further testing.

Reply

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