Tap into your brain
Hi guys,
I cleared up the developers' handbook outline so it makes more sense now, couldn't edit this one though. All new Plugins doc gathering wisdom I learnt from the forum, feel free to check and fix anything wrong, and share your trade secret as you see fit.
Cheers
Comments
Added the more complete Qt.Quit explanation and issues in MS3
In reply to Added the more complete Qt… by jeetee
Thanks, haven't any idea why my wip type="dialog" plugin behaves weird all the time until I see your post.
In reply to Added the more complete Qt… by jeetee
The negative effect of
Qt.quitis that it stops all the active plugins. This is bothering especially with docked plugins that I'd like to stay docked during my work in MS. I've been searching for another nice way to stop a plugin without stopping all the plugins.In reply to The negative effect of Qt… by parkingb
Then see https://musescore.org/en/handbook/developers-handbook/plugins-3x#The_Pl… and the 2 links there
Esp. this:
Dialog plugins
import QtQuick.Window 2.2pluginId.parent.Window.window.close();...
Dockable plugins
In my opinion, these simply shouldn't attempt to close themselves at all.
Moreover, the used workaround from above doesn't work for these. You can reach the QQuickView from the plugin, but calling close on it has no effect. Instead it should be called on the wrapping QDockWidget which is unreachable from within the QML itself.
In reply to Then see https://musescore… by Jojo-Schmitz
Absolutely. Self closing trick is buggy too, QtQuick.Window won't stay on top. I'm not able to understand why QQuickView onClosing Event is not triggerable or signal receivable, seems right now we can only ignore the issue. Moving forward maybe divide plugins into two: background component and view? like chrome extension did in the past?
@parkingb
https://musescore.org/en/node/325368#comment-1100227
>>We should definitely compile all these tricks in some doc.
I'm collecting seashells here
In reply to Absolutely. Self closing… by msfp
Bookmarked !
BTW, I've been reading the Use Case: Changing an Existing Note's Pitch. I don't understand the need of your "NAN" for the G#. I've never encountered such issue in my own processing of the pitch/tpc1/tpc2. But I haven't worked with a 2D array.
My library for managing this value is to be find here. How I work is with a 1D array with the following info:
'tpc': 33, 'name': 'B♯♯', 'accidental': 'SHARP2',
For a certain pitch, depending if I'm looking for a SHARP-range note or a FLAT-range note, I will work only with one or another subset of this 1D array. To be discussed off-topic.
In reply to Bookmarked ! BTW, I've been… by parkingb
I'm still working out the pitch value too, that page is written by @rocchio https://musescore.org/en/node/320499/revisions
Without using your plugin, is assigning all 5 values a must? or is it only required for Guitar TAB?
In reply to I'm still working out the… by msfp
pitch, tpc1 and tpc2 are the must. I guess string is also needed for guitar tabs (I've got less experience with guitar tabs) The relation between tpc1 and tpc2 might be tricky but is fundamental when dealing with transposing instruments.
See this discussion .
It has the same value for non transposing instruments.