Can a plugin access on-time/off-time?

Okay, then maybe you have to do "make -f Makefile.osx clean" after all.

Doing that now. I managed to force it to the right Qt by renaming the old 5.12 subdir, but the built app couldn't find the Qt import files from the plugins. I unrenamed the directory, uninstalled 5.12, same thing. Rebuilding now after make clean.

OK now; make clean was necessary.

Success on the Xcode front; what other neat MS-specific features do I get besides the "Debugger" note context window and the Debug menu? The instructions should note that there are three nonfatal red "issues" about the autogen script ("no classes found", but tool did not return nonzero, so build succeeds). Worked for me without env var adjustments. The "About" box should note that this is a debug build.

Those errors are from MOC (Qt's Meta-Object-Compiler) and basically warnings. Haven't been able to get them removed so far, those files it complains about claim to be/contain Q_OBJECTs, but really don't, MOC is just to stupid to detect that all that code is #ifdefd out.
Debug builds do mention this in the about box "Unstable Prerelease for Version:", at least they do for me.
Edit: actually no, prereleases do that, the way to tell debug builds from others is to check whether the Debug menu is present.

Repeat, it oughtta say in the "about", including in the copy-string...

Why? Those (practically) never are publicly visible, no development build is actually a devug build.

Anyway, there you have a potential candidate for your first PR ;-)

Where is the c++ header file that defines Note? XCode isn't helping me. What is the field of Note that gets me back to its containing chord?

libmscore/{note.h,chordrest.h}?

We truly need Note.Chord to be accessible via QML, (and segment from chord) or you can't get context (including grace notes) from a clicked-on note. I know that if I understood the well code enough I could do that myself, but Dale could do it faster ... I can search the whole score for the containing chord for now ...

As far as I remember Dale exposed Element.parent property as a part of another pull request, https://github.com/musescore/MuseScore/pull/5209. That should be exactly what you are looking for.

deleted

(deleted)

I did a make clean and now both make release and make xcode fail with this (I cannot build at all).
Unknown CMake command "QT5_ADD_RESOURCES".

-- Configuring incomplete, errors occurred!
See also "/Users/bsg/MuseScore/build.release/CMakeFiles/CMakeOutput.log".
xcodebuild: error: 'mscore.xcodeproj' does not exist.
xcodebuild: error: 'mscore.xcodeproj' does not exist.
make: *** [release] Error 66
[(chord-add-remove)]$

Is Qt still in your PATH?

Duh. Superannuated console window. Thanks.

How do I merge that other branch (chord-add-remove) with what I have? I fear switching to it will ignore the other changes.

There are multiple ways to do this, but I would do the following:
git fetch DLLarson chord-add-remove
git cherry-pick DLLarson/chord-add-remove

(sorry, wrong directory).

(comment no longer applicable)

$ git cherry-pick DLLarson/chord-add-remove
error: could not apply c3151b8... Restore Chord.remove() and Chord.add() methods. + collect_artifacts
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

Looks like there are conflicts between the two PRs. You can try to resolve them on your end if you want, or you can wait.

How do I get the whole @#$@#$#$ tree back into a consistent state? I'm trying to restore yesterday's branch, but getting
$ git checkout DLLarson/qml-pr5224-pr5243-playevent-selection
mscore/plugin/api/elements.h: needs merge
error: you need to resolve your current index first

Dale: Please create a consistent branch with all the changes, including element.parent, which I truly need, thanks. Right now I don't have a buildable tree and I forgot the git magic to restore it to workingness (I knew years ago). I wish there were a channel for discussing this without posting on the forum.

How do I get the whole @#$@#$#$ tree back into a consistent state?
git cherry-pick --abort

(deleted)

Is there any problem with deleting the whole MuseScore tree, re-cloning, and re-fetch/checkout Dale's branch?
Seems like overkill, but knock yourself out. Did you at least try git cherry-pick --abort ?

Yes, cherry-pick --abort resolved the problem, and I built the older branch.

Über-kuhl. I've "checked it out", as git users and others differently say, and it's building. .selections is now very reasonably to be called .elements ....

Here's another request. Shouldn't chords have .parent's, too (segment, so you can find all other chords which sound with it?) (Yes, they should...). no?

Up and running and in resonance with the elements...super-cool...

Couldn't be better. Thanks. Busy plugin-coding....

Upgraded rednote plugin attached ("elements" instead of "selections", "enote" typo fixed).

After my new plugin changes 3 values in playEvents it has located, it logs
Debug: no active command, UndoStack
Debug: no active command, UndoStack
Debug: no active command, UndoStack
when exiting. And sure enough, the changes, which are correctly made, are not undoable. Do you have any idea why this may be happening? The plugin is of the dialog-type, and the changes are made by a button handler.

Duh[2]. That was easy. Thanks, works great.

Here's what I have (test score and plugin).

Maybe we have to call that strange function you have that forces play events. I bet that's it. try that.

The initializations of those variables are not needed. I put them there for syntax. They are set by the onRun and used by the Apply handler.

onRun is called when the plugin is loaded, in every case. If it doesn't find a selection it likes, it exits, and QML never puts up the dialog. If it finds one, it saves the note pointers in those 2 vars (know a better way?) for the Apply handler when the Apply button is pressed. Only then is system data changed.

I have a much better and more capable version with a much, much better demo. Here. Lemme look at the code you sent.

It works for me (in Qt 5.9) whether I select a "good" note or not; if I don't select a good note, the dialog is never seen.

Dale, any luck figuring what's going on? I removed the initialization of the global var, but it never fails for me. Are you using my score or some other test case?

Can you think of another place to stash that value? I'm going to try to stick a closure into the dialog ....

It will not let me assign the readOnly on-clicked.

Try changing
property var the_note: null
to
property var the_note
(i.e.,remove the intiialization)

I know. We can re-get the selected note. Let's try that.

OK, here's a version that does not use global variables, but recomputes the relevant note from the selection at apply time (in faith that it exists).

It looks like you didn't actually ask it to change anything (both old and new are 333).

No, I do it twice. The value in the box is not the "default value", but the current value of the selected note. I do it once when invoked, and quit immediately if none is found, and again when Apply is pressed.

Look at the code. find_usable_note is called twice, once in onRun and once in ApplyChanges.

The seeming inability to have a global variable, passing anything at all from onRun to UI handlers, is very, very bad.

(superseded by next).

See this https://musescore.org/en/node/292664 (minimal test case and detail for categorical dialog-plugin initialization problem)

Do you understand what's going on with my test dialog and initialization? What do I tell git to receive your latest changes?

$ git clone --depth 1 -b DLLarson/qml-pr5224-pr5243-playevent-selection
You must specify a repository to clone.

usage: git clone [options] [--] [

(with or without DLLarson/ ).

Yup, figured it out. It's fetching now, as it were.

I found a foolish workaround to the plugin initialization problem, a "press me!" button. In this version, if you're not satisfied with grey "334", you can press "See Current", and violà, as the mis-say, it re-finds the note, computes the summa and puts it in the slot, at dialog-button time. Pretty silly, other people say. Try it. I'm using your branch, all builds and works with my code (haven't tried your code). I used this plugin in actual work to customize dozens of appoggiature in this actual score, which came out pretty well (I bound a key to it): https://musescore.com/bsg/erbarme_dich .

Thanks, but Bach gets all the credit here. But see how important it is to tinker with the appoggiatura playEvents?

When I use your message dialog technique to report errors, if the error is shown and accepted, plugin accelerators no longer work unless I switch to a different application and back to MuseScore. There is something broken in re-selecting the MuseScore window with respect to those accelerators after such a message-box closes. I don't know if it's mac specific. My "onAccepted" calls Qt.quit() like yours. If my "dialog-plugin" dialog closes normally, there is no problem. Do you get this effect?

Unable to find a workaround, I removed the error-complaint feature. Error indication is now "doesn't do anything", but the accelerators work properly. It is crazy that I cannot pass info to the dialog (it could put up an error message if I could), or run any code before it is exposed.

I added that declaration to my own message-dialog, and observe no difference in behavior. I tried several combinations of quit() or lack thereof after the open() call and in the button handler. I think it has to do with the fact that the plugin is a dialog-type plugin, which, given that it has to accept input, is mandatory. Yeah, when you reload plugins, bye-bye bindings. MS QML is witchcraft.

I created a minimal test case (selection problem) that does not fail (attached). Must be pilot error -- later.

Dmitrios has identified the no-init bug as known since 2013, has references, a fix in the works, and an easy workaround (use Component.onCompleted instead of onRun until the fix) and that house is now all in order. This surely will fix the the_note problem, too, See the other thread.

I've found the accelerator problem (but not the core code bug causing it): https://musescore.org/en/node/292732 . With that in mind, and this morning's writearound, attached is a fully operative version of the Appoggiatura plugin.

Here's an even cooler plugin using the new capabilities , the one I've been waiting for for years. From the source,
/* This plugin replaces the Piano Roll Editor as the most convenient means of
adjusting the on-times and off-times (not "len"s) of notes on a one-by-one
basis. This allows you to phrase without the yellow bar jungle (which is
always there for hard cases). This even works on appoggiature, but does
not work on notes with real "ornaments" (not well-defined how to edit).

Extensions to impose duple- and triple- phrasing patterns are under
consideration.

Just click on any note, and invoke this (maybe via a shortcut), and
edit away the on and off times. Return and ESC are accepted as
Apply and Cancel.
*/

Here's a dialogue-driven Baroque trill generator based upon your unique ornamenter, and demo (just play it through).

By the way, destructuring assignment [a, b] = [1, 2] is an ECMAScript 6 feature which is thus not in Qt 5.9. Dale, could you private-mail me an email address so we can take this conversation out of the forum? Thanks.

In the hands of musicians, professional or amateur, who know what they're doing, these capabilities and tools will accelerate the process of score-preparation for quality performance (by whatever sound resources) immeasurably, and allow the Piano Roll Editor to be thrown off the roof....

I agree it's beautiful and entertaining, but only showing one staff at a time, it is less valuable as a visualization tool. As a performance-editing tool, it is far better than it was in version 2, where the usual outcome was crashing the program, and is a huge boon, but has nothing to offer over these new tools.

Fixed in branch master, commit 216188f7ed

_Fix #291708: Expose Score.selection object to access to GUI selected elements.

This commit exposes the Score.selection.elements list
enabling QML scripts to manipulate on user selected score elements.
The expectation is that additional selection information will be
provided on this object in the future._

Fixed in branch master, commit 366ccb0628

_Merge pull request #5243 from DLLarson/expose-score-selection

Fix #291708 Plugin: Expose Score.selection object to access to GUI selected elements._

That was still not the main PR about note events, I return the status back for now.

Fixed in branch master, commit b05c823912

_Fix #291708: Expose PlayEvent's via QML Plugin Note interface.

Adds capablity to examine and modify PlayEvent's and a Note's
playEvents list. Adds access to Chord.playEventType. Also
supports UNDO for these operations._

Fixed in branch master, commit c25a17e919

_Merge pull request #5224 from DLLarson/qml-expose-noteevents

Fix #291708 Plugin: Expose NoteEvent's via QML Note interface._

This, like the Piano Roll Editor, is "beautiful and entertaining", but a terrific development. Looking forward to checking out the nightly! Thanks, Dmitrios!

Probably no one's reading this except myself, Dale, and Matt, but this is what a 5-minute Bach motet movement sounds like when every single note is deliberately phrased, by use of the new tools facilitated by these improvements, to match the text, line shape, slurs/phrasing marked by the composer, and other architectural considerations (i.e., "choral director dharma"): https://musescore.com/bsg/scores/1697186 . This opens a new chapter in MuseScore realism.

Not quite. I just learned that "nightly" isn't really 'nightly', it happens as soon as a merge succeeds! Now for the bad news! The mac build times out, and the previous build (0734 this morning, Europe time) doesn't have the OnRun fix, which I now need. Hopefully Dmitrios or Anatoly will fix the build problem. I so do not want to have to back out the onRun fix code.

Habemus appam.

It is all well now! MuseScoreNightly-2019-07-30-1306-master-ec7d9a8.dmg

I was referring to the fix that executes onRun in the correct instance. It all seems to work now!

Here ya go, y'all (announcement/plugin posting) https://musescore.org/en/node/292789 Thanks Dale, Matt, Dmitrio, Jojo, and Jeetee.

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