Copy Constructor for notes and chords in plugins
If you want to move a note from one chord to another or from one voice to the other you have the natural workflow:
1. Detach the note from the old chord /voice, i.e. make a copy of it and remove it from the old place
2. Add the copy, or detached note, to the new place.
In MuseScore you have to construct a new note (with default properties) and manually copy over the properties exhibited. With this you loose most musical properties of the origin, e.g. velocity type and velocity, on/off time offsets, ties and slurs.
It would be of much help to extend the plugin surface:
A new Note can be created with:
note = new Note();
or
note = new Note(score);
where score is a Score object
>extension>or
>extension>my_note = new Note(existing_note);
>extension>where existing_note is an object retrieved (by Chord.note(index) for instance).
>extension>The newly created object my_note has exactly the same properties as existing_note.
Sorry for the cross post with Issue tracker. But there I got no response. Perhaps this is the better place to discuss what plugin framework is intended for without that feature (or access to the whole set of properties).
Comments
Here is definitely a better place. As you may have seen, the current nightlies don't have any plugin framework. The Qt bindings has been removed and we are evaluating a totally new way of handling plugins. A way that can give access to more objects in the core of MuseScore, more properties of these objects, and that let plugin developers create UIs without relying on the huge and painful to compile Qt bindings.
We'll take this feature request into consideration while evaluating it.
If you want to be at the cutting edge of this evaluation, you can check this git repo https://github.com/wschweer/MuseScore/tree/qml
In reply to Here is definitely a better by [DELETED] 5
not as much cutting edge as I'd like it to be, I'd rather see it in the nightlies ;-) and would like to be able to start playing with it.
In reply to not as much cutting edge as by Jojo-Schmitz
And you'll be disapointed if we had to change it again ;) Nothing more cutting edge than compile it yourself :)
In reply to And you'll be disapointed if by [DELETED] 5
No, I won't be disappointemend (well, to be honest, maybe slighlty ;-)), this is expected of the nightlies. And still far better than no plugin framework at all. And building it myself is currently beond my capabilities...
In reply to Here is definitely a better by [DELETED] 5
I'll just add my moral support to the basic idea you are describing for the new plugin subsystem. As you know, I really like having the ability to create effective plugins, and would love to see it become more powerful. Seeing the already somewhat crippled framework go away completely because of the Qt bindings issue would be extremely disappointing. If there is any way to make this new and seemingly improved framework happen - even if it require complete rewrites of existing plugins, even if it introduces a delay into 2.0 - I'm for it. Otherwise, I fear 2.0 will seem a step backwards in some significant ways (I really rely on a few plugins right now, and I'm sure some others do as well).
That said, I would like to call attention again to this thread:
http://musescore.org/en/node/14638
If for some reason plugins just cannot continue to be supported, I would urge developers to consider this idea as a way for programmers to add features in a relatively risk-free way. I still think it has value as a way of structuring the implementation of some generally useful functionality, but I can certainly see that we wouldn't the core program to get too bloated with random special purpose features. That's one reason I like plugins so much.
In reply to I'll just add my moral by Marc Sabatella
100% agree. That qml stuff Werner is working on looks promising though.
In reply to I'll just add my moral by Marc Sabatella
I value plugins too. Don't be afraid, there will be plugins in MuseScore 2.0. Actually, I should post in another post but let's try something here. This is not the approach we are investigating currently
MuseScore 1.1 added the connect panel. The connect panel is a full fledge browser, with a javascipt engine. We have a way to know the current score from the javascript loaded in the current page. What if, if you are online, you could load an HTML page, possibly with a normal HTML form to ie choose a color, change some parameters and execute some javascript that could have access to the content of this form and to the score, measure, notes etc... Distribution and update of plugins could then be easily done. Only problem, you need to be online to execute plugins. We could imagine mixing local HTML pages and online ones but it looks like a mess.
About the approach we are investigating. It's similar to the previous approach except that the plugin developer will not have access to the Qt Widgets and Core. The developer will have to code plugin and plugin interface in QML. The core score elements would become QObjects and then would be accessible in QML
In reply to Web plugins by [DELETED] 5
Sounds intriguing, but of course the devil is in the details. I don't know if the part about having to be online in order to run plugins is part of the approach you investigating or not. I'm not a big fan of the idea on general principles, but realistically, I'm pretty unlikely to be running MuseScore for any extended periods in locations where I am not or could not be online.
If/when someone puts together a build with a prototype of any of this worth trying, let me know and I'll give it a spin.
BTW, I am getting closer to the point of wanting/needing to replace my current laptop. If/when that happens, it will become much more feasible for me to install a build environment for myself.
In reply to Sounds intriguing, but of by Marc Sabatella
2 cents: Personally I would like MuseScore be able to run the plugins without being connected to the net. I often use it when not connected.
Best,
In reply to 2 cents: Personally I would by xavierjazz
Agreed. It is not a bad idea as such, but needs be an addition rather then a replacement.
As soon as you offer something to the public - and some people try it and like it - you put something to life that cannot die anymore. At least in discussions.
I am not in the position to judge which approach is better. The qml approach is completely unknown; don't know how somebody can find it promising. But supposedly, the new approach is not "upwards" compatible with the existing one. So, my conclusion is not to invest any time anymore in plugins of the 1.2 style and to be patient.
If no compatibility is guaranteed, a warning in the actual docs for the normal user would be good practice.
When it comes to alternate approaches I can imagine that old fashioned Macro technique can also be of some help. Some text editors (like emacs) allow to record a series of key strokes (commands) as a macro, assign it to a key and execute it (by pressing this key) multiple times at the current cursor position. Nothing for MuseScore ?
In reply to Alternate approaches by ManfredHerr
Anything is interesting. If you can code, try it. If you can't, wait for it, patiently.