Copy Constructor for notes and chords in plugins

• Jun 27, 2012 - 16:19

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 by Nicolas

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 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 by Nicolas

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.

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 ?

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