No way of controlling gateTime at present in nightlies

I'd add that exposing this in the plugin framework would seem to be equally important. If there is truly to be no "swing" playback option for 2.0, then I'd really hope to be able to implement a plugin for it, and this is what I would imagine needing to set. Not sure of the current status of the plugin framework.

MuseScore 2.0 can map one note to several midi note on/off events. This should allow to edit arbitrary articulations (trills, grace notes etc.). This means there is no (single) gate time anymore implementation wise.

The "chord articulation" can be edited in a pianoroll style editor. It lacks some functionality but editing the gate time of a single midi note event should be possible.

I would still like to see this exposed for plugins, specifically to make it possible to write a Swing plugin to replace the one bit of 1.3 functionality that will not otherwise be in 2.0.

But no reason to leave the issue open, I would agree. Maybe we can have a separate discussion of the best way to expose this to plugins.

In fact, I find the current piano-roll-based implementation of time gate very cumbersome to use:

1) The piano roll shows only one instrument at a time
2) It is possible to select only one 'note' at a time.

This makes the task very time consuming. Some common uses (common at least for me), which are unnecessarily complex:

1) a 'chord' of several instruments which one want to shorten (for phrasing): the chord of each instrument has to be shortened separately, closing and re-opening the piano roll to change part, selecting the relevant note in the roll (not always easy to understand what is what) and re-entering the numeric value!

2) several similar points which should be articulated in a similar way: again each point has to be edited separately.

The 'old' implementation was HUGELY easier and faster to use!

I understand that the piano roll allows (will allow?) more flexibility, but for this aspect, I find it a serious backward step. In fact, I gave up using this feature at all.

So, I think a different implementation is needed for human beings too, not only for plug-ins.

(All of this assumes some oddities of the piano roll will be fixed; for instance, the fact that, when re-opening the piano roll, the score is always shown at the beginning, no matter which chord is selected.)

Thanks,

M.

On the other hand, the old implementation was more cumbersome if you *wanted* to work with a single instrument and then move through it one note at a time making adjustments. You had to keep opening and closing the Note Properties dialog. So it's a trade-off, I think.

Although I realize it's a lie in that these are no longer simple properties now that notes can have multiple events, we all knows notes still have a basic note on and note off event in addition to whatever else. So I think exposing these two specific event as if they were simple properties in the Inspector makes sense. They could be greyed out for notes that have additional events defined via the piano roll.

But one other thought: plugins can be used by humans too, though :-). So while I was thinking specifically of a plugin to automate the particular adjustments needed for swing playback, someone else could write a plugin to basically replace the Inspector for these two properties. Select a group of notes - whether on one instrument or spread across several - then run the plugin. A dialog pops up where you can enter ontime and offtime offset, it applies them to the note on/off events for all notes in the selection. Again, perhaps skipping notes with additional on/off events.

@Marc: you are correct when you say that the 'old old' implementation (the one in ver. 1.x) required opening the note prop. dlg more times than strictly necessary. Still you could set the time gate of several notes at a time, if they all followed the same gate time pattern (which at least for me is a rather common occurrence).

It was even possible to *modify* a custom time gate previously set for several notes, a thing which the current implementation of the Inspector cannot do (if you selected multiple elements and one of them has a customized property, this property become disabled in the Inspector, even if *all* the selected elements have the same customization).

I was referring to the intermediate implementation, the one using the Inspector, which appeared for some time in ver. 2.0. I do not remember if in that case it was possible to modify several notes at a time, possibly not, but with the present Inspector, it would be possible (with the limitation described above).

So, as ornament realization (<= multiple MIDI event for chord) is one thing while swing or articulation (<= time gate) is another and the piano roll might be suitable for the former but, I maintain, is hard to use for the latter, I agree with Marc that exposing the basic on / off offset properties for notes (also) in the Inspector would be very useful and could speed up the work considerably. It would not be the first occasion in MuseScore of a task which could be achieved following two different paths.

The plugin idea might be a work-around, but no more than that: starting a plugin requires several steps, while the Inspector may be left open and be immediately accessible.

Finally, I do not agree that the issue is "fixed": I would find "postponed" or "won't fix" more appropriate.

Thanks,

M.

I do still like the idea of exposing the "ontime" and "len" (which replaces the former "offtime") for the default NoteEvent directly in the Inspector. Most notes will have only this single NoteEvent; why not allow it to be manipulated directly in Inspector in this way? For notes with multiple events, as I mentioned, we could grey out the control in the Inspector, and perhaps instead provide a button to bring up the piano roll.

However, I would note that now that plugins can have keyboard shortcuts, I don't know that the plugin solution is that bad either. After selecting a group of notes, a single keystroke could pop up a dialog, so it's not that much more work than using the Inspector. Especially if this particular plugin were provided as part of the standard distribution.

Automatically closed -- issue fixed for 2 weeks with no activity.

Requests for this feature continue to appear, a recent one is //musescore.org/en/node/58556 .

I believe it could be wise to re-assess this decision and see if what it is possible now from the piano roll, and perhaps even more, really would not be possible from the inspector (this comment explains why it would be better, if possible).

Thanks,

M.

Pull Request with proposed fix pushed on github: https://github.com/musescore/MuseScore/pull/2132

Currenrly Travis tests are failing and some points might be missing, but it should be enough for trying and initial testing.

The fix is now ready (failing tests have been corrected).

More checks and 'field tests' from anyone interested in his feature would be welcome, though!

Travis tests are fixed since long and the code itself re-based more than once. Anyone interested in testing it?

The fix has been rejected by the PTB. So, presumably the issue should be marked as "Open" again?

Fixed in branch master, commit 9f52257ce8

Fix #23063: (import) MusicXML alter element not exported

Fixed in branch master, commit 3d73b53d5f

_Merge pull request #25024 from pacebes/23063-importMusicXMLAlterElementNotExported

Fix #23063: (import) MusicXML alter element not exported_

That fix is entirely unrelated