How to create a dll plugin
I am currently attempting to produce a plugin for BLIND MUSICIANS. As they cannot read sheet music, I am trying to generate a textual descriptive version.
I have attempted to use qml but most of the builtin help within the Plugin Creator appear to refer to C++ classes and the properties and methods listed are not available. Using existing qml plugins have shown me how to commence browsing my way through the linked objects, but some the the linkages do not appear within the help system, such as gracenotes. What data fields that are available such as element.clef and TimeSig, KeySig only return undefined. I have been able to work out what each value refers to.
My other thought was to use a DLL plugin, but I cannot find any documentation on how to link such a plugin into musescore. Is it possible? How would I go about constructing the interface to access curScore? Where do I locate the necessary include files required by C++?
I would appreciate any assistance you may be able to give.
Geoff Baker.
Comments
Why do it as a plugin? Become a code contributor and integrate it directly into MuseScore. There are very few people who are not volunteers contributing to MuseScore.
See https://musescore.org/en/development for further information.
In reply to Why do it as a plugin?… by mike320
Thanks. I have already started down that tack.
Geoff Baker
In reply to Thanks. I have already… by geoff.baker
Also, reach out to Marc Sabatella: One of our contributors who has mentored around accessibility during this year's Google Summer of Code. He likely has the best view on what (and how) the existing stuff works as well as ideas on how to approach some of the missing items.
See https://musescore.org/en/handbook/accessibility, what you are looking for is available already, at least to some extent
Wow, great timing! I actually was just composing a message to another forum regarding accessibility of notated music in general, and indeed this is one of my areas of interest with respect to MuseScore specifically.
What I will suggest you do first is download a nightly build of the "master" branch - basically, the work in progress towards an eventual MuseScore 3 release. You may or may not be aware that even the current release (MuseScore 2.1) incorporates some accessibility features, reading aloud (via the screenreader NVDA) score elements as you navigate them. MuseScore 3 will expand on this by providing additional navigation commands to allow finer control of the navigation and the information read, and some of this work is already available in the nightly builds. Eventually we also hope to provide keyboard access to palettes and otherwise make MuseScore fully accessible, allowing blind users to create scores using the full capabilities of the program. Much of this work is actually completed already as well although not merged yet. A good deal of it was sponsored by Google as part of the recently complete Summer of Code - see https://musescore.org/en/user/930801/blog for more information on the work performed by Divya Raghunathan.
Anyhow, right now is an especially good time to be getting involved with this, as there is quite some momentum already and also much awareness of the work left to be done!
In reply to Wow, great timing! I… by Marc Sabatella
Thanks all for your quick responses.
I have already downloaded the current stable version (not nightly build) and have compiled it to verify I have got the environment right.
It is great that hear that the Blind are being catered for or will be.
My immediate goal is to assist my wife who is learning recorder and flute. She is totally Blind and has never seen what a sheet of music looks like let alone learned how to read it. My current idea would also cater for those sighted musicians who only play by ear and struggle to learn new pieces.
The idea is to provide an additional entry within the "File" menu called say "By Ear Export", which would export a textual file describing/defining everything shown on a piece of music.
1. Would that be the best place to hook in?
2. As I have not yet got a handle on how you organize your code structures, but I would expect that any new subject would be put into a source file of its own and using minimal interfacing into existing source to link it. To minimize any interference and/or corruption to the existing application.
3. Who should I be working with and how do I go about setting that up? Or do I wait until I have generated this new feature before having other's input (probably not the best)?
After that I would then would start to tackle other areas. I have been a programmer since 1973 and am very slowly learning somethings about sheet music. So I see this a challenge to keep my mind active and extend my community activities into differing areas other than Lions.
Geoff
In reply to Thanks all for your quick… by geoff.baker
Welcome aboard!
To answer your questions:
You don't need a separate menu item for a new export format, simply add it to the list of formats available from the existing File > Export dialog. However, it may be more appropriate for conversion to your descriptive format to be done via a plugin, possibly as a web service (more details on this below).
Quite right! Have a look in the mscore folder at the files with names that begin with "export".
Marc is most familiar with MuseScore's accessibility features and Nicholas (lasconic) is most familiar with MuseScore's code. These are the people you need to speak to. Nicholas in particular will need to decide whether your feature should be added to MuseScore's code or instead made available as an optional plugin/web service. You shouldn't work on anything major until you have heard from Nicholas, but feel free to experiment on your own.
As it happens, I myself am also working on developing MuseScore's accessibility features in partnership with RNIB, so I take a keen interest in what you are doing, and can offer feedback, advice and support from the music accessibility experts at RNIB.
When you actually come to start coding, the best place to get help and advice is via MuseScore's IRC channel #musescore on Freenode.
Descriptive score format
Here are some likely candidates:
Web service
Should the powers that be decide your exporter/converter is best offered as a web service then the task would be to create a MusicXML to Format X converter (where Format X is the chosen descriptive format), or to improve the existing talkingbooks.org converter. The next job would be to write a simple plugin that allows MuseScore users to convert their scores into descriptive scores in one click.
In reply to Thanks all for your quick… by geoff.baker
As shoogIe says, if you do want to export to a new format, might as well just from the File / Export menu. However, I would start by stepping back and looking at a couple of the assumptions you seem to be making here.
One assumption I would question is that exporting to a text format is a better way to read a score than to simply use (and improve as needed) the navigation features within MuseScore. I would be fairly certain that at least in principle, reading a score from MsueScore would be far superior in any number of ways to any text-based solution. Consider, because MsueScore knows the structure of music, you can browse by note, by measure, jump quickly to specific locations, easily navigate up and down from staff to staff within a score. potentially configure which symbols are important enough to read, etc. A plain text file is going to be much more difficult to navigate. So I have to believe a blind user would get far more out of navigation within MuseScore. The question then becomes, what issues are preventing this from seeming viable to you at the moment, and can we instead work on addressing those issues? Do check out the nightly build which has greatly improved navigation (you will need to customize shortcuts for "Accessibility: next element" and "Accessibility: previous element".
Second, to the extent that exporting to a text file makes sense, I would question whether inventing a new one makes more sense than leveraging an existing one like ABC, TinyNotation, etc. Here, I would be inclined to agree that any format that was not specifically designed with the thought of making it screenreader-friendly is probably not going to be ideal, and there is definitely room for improvement in this respect with the existing text-based formats I know. But if one is to develop a new text-based format, it seems it would make sense to make it one that a blind user can easily write as well as read. And rather than lock this into MuseScore, it seems it would benefit the world at large more if there were converters to and from MusicXML, so that users of any notation program could potentially use this.
To me, the simplest approach might be to start with ABC but to replace the cryptic punctuation symbols with keywords and develop a very simply pair of converters to and from standard ABC, thus opening the doors to the well-established and very powerful tools that already exist for dealing with that format. But the idea of developing a new format from scratch and produce a whole new set of tools isn't out of the question, either. it's just that if we go to that extreme, it would definitely be good to take our time and involve input from others and really do it right.
As for who to collaborate with, I think you've found two of the right people here :-). Divya - the student who worked on accessibility features for GSoC - is another. But to address some of the larger issues I addressed, I do think that involving people from RNIB as well as NEVI and perhaps other organizations makes sense too.
Of course, there is also Braille to consider. Right now we can export to MusicXML and there are a number of converters to get from there to Braille, but this technology is still far from polished and can use work. Getting involved in the music21 project does seem to me to be the best way forward, as it is the most active open source project dealing with this.
Finally, there is the question of textbooks, which shoogle also mentions. I only recently became aware of DAISY and am now quite interested in seeing what can be done to make this format/system work with music.
So right now, I see quite a few mostly separate issues to address:
1) continuing to improve the navigation within MuseScore so that blind users are not forced to resort to text-based formats just to read a score
2) recognizing that text-based formats do have a place as well, coming to some consensus on an appropriate language and developing / enhancing / integrating the tools needed for blind users to be able to use this and exchange music with sighted users
3) improving the tools needed to generate Braille
4) investigating the idea of DAISY support for music