Native American Flute plugin

• Mar 19, 2014 - 14:45

I am interested in perhaps extending the existing NAF plugin. Maybe even implementing a full-up Nakai tablature. Would appreciate some pointers as to how to start, do I join a group, a project, 'follow' somebody ...
Thanks,
pablocito

Comments

• Mar 20, 2014 - 14:36

Thanks for the reply. I hope you don't mind some dumb questions, like ...

There is no explicit way to subscribe to a forum, ie to get mailed every post to a forum? Perhaps that is too old school..

What are 'PR's? Are they different from 'Projects'? Is there posted somewhere a description of the development processes?

Reply

• Mar 20, 2014 - 14:47

I'm afraid you've fallen foul of the American obsession with reducing everything to acronyms!

PR stands for Pull Request - the means by which you get your own work merged with the mainstream application on GitHub.

NAF stands for Native American Flute - but has unfortunate connotations for anyone who lives in the UK (United Kingdom).

Reply

• Mar 20, 2014 - 00:18

Hi. I'm (ostensibly) the NAF plugin maintainer. But I have to confess I haven't been good at follow through - no changes have been checked in for more than a year.

As Jojo-Schmitz has pointed out, the plugin is currently maintained on Github. (Except that the font it uses is separate; the font is on Glint Goss's web sites, and he's the sole maintainer of that.) Pull requests may be the way to go, if what you are doing is enhancing or upgrading the existing plugin. If what you are thinking of doing diverges more from that, perhaps a different/separate plugin might be in order. (The owner on Github is lasconic; any of us would have to go through him to make checkins official. Lasconic is the owner because he was the first contributor.) If you have something truly new in mind, Github is an option but not the only one.

I'm very curious what you mean by "full-up Nakai tablature". Since Nakai TAB is, at its core, standard music notation on the treble clef, Musescore already really does what's needed, I believe.

There aren't too many people here (it seems) into NAF, so it's unclear to me that there's a "better" place to discuss this than right here. If the discussion moves along to font creation, or if the discussion goes deep into plugin ins-and-outs, perhaps a new topic could be opened somewhere else.

I'm very happy to discuss further, offer suggestions, merge our code, help with a new plugin idea, etc.

Reply

• Mar 20, 2014 - 14:51

Thanks for the reply.
Before I go too far off the deep end... How about a simple dialog box to be able to toggle between 'feet down' or 'feet up' fingering charts?
Now, I start tip toeing along the diving board...
Is the 'text' attribute really the only option to locate fingering charts? If so, how about some sanity checks, like, 'is there some existing text'? Or, maybe a way to clear all charts when it would not be convenient to use the backup button?

Reply

• Mar 20, 2014 - 21:35

I think you've brought up two different sub-topics, so I'm going to split this discussion into two threads.

Re. "foot up" and "foot down":

(For non flute folk, this means whether the mouthpiece is shown at the top or bottom in flute fingering glyphs, which show, pictorially, the open and closed finger holes. The "foot" is opposite the mouthpiece end [sometimes also called the "head"]. Different people prefer this shown one way on the top vs. the other way on top - and it's difficult to switch one's mind once one or the other is learned, so being able to pick between them is useful.)

So... personally, I don't think a dialog choice box is the way to go. In my own use of this plugin, it gets used over and over while editing a score, and having to make a choice every time it's used would be a useability burden. It represents an extra click, almost always useless to any given user, IMHO, since the same choice would be made every time.

I'd rather see the choice made in the Musescore GUI with two separate items in the Plugins menu, from which the user chooses one or the other. That would make making the choice just one click: selecting the preferred item from the menu.

That means having two ever-so-slightly-different copies of the plugin. This is simpler to implement (albeit maybe harder to maintain, it becoming two script files).

If you accept my view, there remains the question of whether the new plugin (your "foot up" version) should be released in its own right as a separate plugin, or released with the existing plugin making it a "package" or "bundle" of the two:

1. If bundled together, they'd both be installed together, and the resulting Musescore Plugins menu gets more cluttered. The majority of users don't really want both of these options. To clean up the menu, they have the choice of deleting (or renaming, to disable) the one they don't want, but this is kind of tech-geek level, and most users won't.

2. If released separately, there's a "findability" issue. Potential NAF-plugin users may not know the two versions have been made available without the plugins' download pages cross-referencing each other, or something.

3. If released separately, there would maybe have to be two different download pages on musescore.org. (This is maybe just a variant of point 2 above). But this makes initial release of the additional plugin more involved, and ongoing maintenance more difficult. (My reason for believing ongoing maintenance is an issue, is that I believe in a best world, any changes made in one plugin should be simultaneously made in the other, in concert with each other.)

I'm almost of an evenly-split mind about whether to bundle the proposed new plugin, or have users download it separately. But, to me, points 2 and 3 above are more significant than point 1. In other words, I lean toward bundling. This infers the slightly "cluttered" Plugins menu. But I think most NAF people would understand, and put up with the additional menu item.

A few issues would remain:

1. As I recollect, doing "foot up" requires loading a different NAF font from Clint Goss. This would require changing the install instructions, which currently are under lasconic's control. So you/me/we would have to get his help getting install instructions changed.

2. I'm a novice with Git. I've used other Revision Control Systems, however, so my gut feeling is that it's easy to take an existing source file and change it and check it into Github, but adding a new file to a repository isn't so straightforward. I'm guessing it would have to be emailed to lasconic for its initial checkin - but I'm not sure.

3. Finally, there's what the Plugins menu should show. I certainly understand "foot up", but I think that's kind of colloquial and may not represent the best terminology. I kind of think it's more correct (in a formal sense) to talk about in terms of mouthpiece, rather than foot. There's also the question of whether and how the menu text on the two plugins should change in concert with each other.

I'm unsure what I personally fell about that last item. In any case, I've seen the issue of "foot up" versus "foot down" discussed before in some online email forums to which I subscribe. I'd be happy to search through their history, if you'd like, to see what the "best" menu terminology might be, if you like.

Reply

• Mar 21, 2014 - 15:09

Cool! You have given me a lot to think about.

You make a very valid point concerning increasing the burden on the user. But the mod I have in mind would not make the user select a font each time fingering charts are placed. I like the idea of storing the font selection somewhere in the UI. Storing in the main MuseScore Preferences would be counter intuitive in my opinion. How about adding two sub selections to the "NA Flute fingering' selection from the Plugin menu; one labeled 'Execute', another 'Preferences'? This would make the increased burden only a slightly longer mouse traverse. Another approach would be a stay-resident dialog box similar to the one used for playback volume and tempo.

Two slightly different copies of the plugin would not be needed. The font selection process would either directly pass the font name to the fingering placement function, or place it in some global location where the function could read it.

I am not too attached to the terminology used in the dialog to name the fonts. I used the 'feet'
terms because that is more neutral than Goss' naming convention - calling one 'inverted' (implying - in my opinion - one is 'wrong').

Regarding documentation: The big thing is being allowed to mod the plugin, if that is permitted then providing updated doc should be trivial (I would think).

Reply

• Mar 22, 2014 - 01:22

Well... plugins cannot access Musescore's settings, let alone extend the settings (nor any of the user interface). There is a one-to-one correspondence between plugin scripts (individual files) and items in the Plugins menu; and the scripts are isolated (there is no global general-purpose storage for plugins, nor ability of one to call into another). I really doubt a stay-resident dialog could be done either.

However...

You triggered a new idea for me: specifically, while there is no way to have general-purpose global state across separate plugins, it might be possible to have persistent (state) variables exist within the scope of a single plugin, which keep their values across multiple invocations of the plugin. So, I just tested this, and yep, this seems to work.

So you could have the user pick a preference via a dialog box that appears once per Musescore session, the first time the plugin is invoked.

As you point out, picking between two Plugins menu items is just a little extra mouse driving. And I totally agree that if new NAF items are added to the Plugins menu, they should go into a sub-menu.

Which gives us two implementation ideas (so far) to pick between: Either two NAF menu items, one for foot-up and the other for foot-down; or a single menu item, from which the user makes a choice via a dialog, once per Musescore session. My right-off feeling? It's almost a draw. (But, I have thought of a - very rare? - use case where someone might want to switch between the two fonts rapidly, without wanting to exit and restart Musescore to do it.)

Another approach is to consider the developer's (your) point of view. Dialogs are a little more complex to do (documented here: http://musescore.org/en/plugin-development/how-plugin-development#Creat…). As you'll see there, you're asked to install a dialog development environment/tool ("Qt Creator"). But you should know it's also possible to bypass Qt Creator by downloading an existing plugin which has a similar dialog, then reverse-engineer and manually hack the dialog's description (which is what I've done, albeit this way is very limited - I've only done radio buttons, in a single column). When released along with the plugin's JavaScript file, a dialog is described by an additional file having the extension ".UI", containing editable text structured kind of like XML.

This Qt thing won't be used when Musescore 2.0 comes out. Musescore 2.0's dialog-dev stuff for plugins will be built in, no separate tool needed.

(There is one more way to do a dialog without the Qt tool: a simple "message box" can be done without it. You can't have radio buttons nor choice boxes this way, so a user choice would have to be done by picking among common message box buttons [which you get to specify for the box, i.e., from among your picks of "Yes", "No", "OK", "Cancel", etc.]. While this is easier to develop, it's less user-intuitive. But this is a possibility.)

Reply

• Mar 22, 2014 - 01:37

I may have put the wrong spin, giving you the idea that it's better to not use "Qt Creator" to make plugin dialogs and instead work around it. I may in fact feel that way - but that's about me, and my history with this, and my situation.

If you think about it, the official documentation about that here on musescore.org recommends you do use "Qt Creator".

So please look at this as my simply having provided alternatives in this regard. You might see that I care about the finished result (or at least some parts of it, such as terminology). But the steps to achieving the result - not so much. Whether or not to use or bypass "Qt Creator"? I'm sure you can make your own informed decision. Please, rather, consider me agnostic about that and accept my apology for what seems like it was unclear communication.

Reply

• Mar 21, 2014 - 12:52

Here's my reply to your second set of question/suggestions....

My interpretation of your questions makes me believe you've found that if the plugin is re-used, it over-writes the finger diagrams already there, but doesn't automate the preparing of a clean slate by getting rid of them first. Hence your idea of using Undo (what I think you meant by "backup button"), or alternately by "select all" of the finger diagrams and deleting them prior to running the plugin again. (To do that, the selection is as text, which is what they are: Unicode numbers, letters, etc., rendered visually as finger diagrams via Clint Goss' font.)

(If I didn't get the right idea of your questions/suggestions, please let me know.)

The above action is really commonly repeated over and over while editing a score, but unfortunately, deleting the previous fingerings has to be done manually by the user, since the plugin API doesn't support what you (and I) would like in this situation, for the plugin to automate it.

So what you or I really need to do is address this as an enhancement request to Musescore itself - after which the plugin(s) could be improved. But....

The current version of Musescore (1.3) is nearly at its end. The three developers who work on Musescore itself are doing a major re-write, generally talked about as "version 2.0", and predicted to come out some time this year (they've said summer; I haven't been following whether it's on schedule or not). No release updates to the 1.3 code are planned (unless I'm out of touch about this).

For 2.0, the plugin API is undergoing a major revision. All plugins for Musescore 1.3 will not work with Musescore 2.0. They will all have to be rewritten and re-released. The new plugin API is undocumented (at least, it was undocumented when I asked about it 3-4 months ago), and I have no idea how to change the existing NAF plugin(s) to work with 2.0. Last I communicated with lasconic about any of this, he indicated to me that the underlying plugins' capabilities re. score editing is unlikely to change much between 1.3 and 2.0.

Version 1.3 is kind of frayed for some users so an update (which will be version 2.0) is really needed; thus I've not been inclined to rock the boat with change requests which could delay 2.0. And I'm thinking no advance work on 2.0 plugins will happen anyway (lack of documentation and all that), but rather 2.0 plugin development will happen mostly only after 2.0 hits the streets. Some time after that, enhancement requests make sense, once everyone is playing in the same ball park.

IN THE MEANTIME:

Version 1.3 is alive and kicking, and releasing new or improved plugins for it is a fine thing to do. Only, the 1.3 plugin API won't be enhanced. And version 1.3 plugins will have a kind of short useful lifetime. But certainly worth the effort, if you're into it.

(As I implied in my first post here, I've been remiss in finishing and releasing NAF plugin enhancements I've nearly done. Stupid procrastinator, am I. Oh, my,... ouch.)

Reply

• Mar 21, 2014 - 15:25

I have looked at the Native American Flute plugin, and modified my copy slightly to use a different font.
I was very impressed. Very clean, elegant, easy to follow, straight forward coding. I assume the rest of MuseScore is of the same quality. That being the case, making the changes I am thinking of would not be all that hard. The big questions in my mind are those of 'style', in other words, how the MuseScore authorities feel about what functionality is allowed and what it's form and feel should look like.
And so, I can't imagine changing this sort of plugin for 2.0 down the line would be that big a deal.

Reply

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