Suggestion for improving guitar expression rendering

• Sep 7, 2020 - 03:13

Here is a pdf document containing a few suggestions for improving MuseScore notation, properties edition and rendering of glissando, slur, hammer-on and pull-off, mainly for guitar but also applicable to other instruments. Comments and additional suggestions are welcome.


Comments

Nice ideas put together. I wonder what guitar (and guitar software) users think about this. I believe @cadiz1 is a Guitar Pro user so maybe he could bring some feedback.
Have you looked at the code already? I haven't explored the playback code at all so I can't imagine where this would start being implemented.
I know that a VST interface is being worked on for 4.0 so it's good to take that into consideration, since there are many VST plugins that handle this.
Particularly, I like the free Spicy Guitar https://vst4free.com/plugin/1065/
and it has some implementation on slurred playback and other 'idiomatic effects', decided by rules on how notes overlap. Maybe this brings some additional ideas that can be worked for soundfonts too.

In reply to by elerouxx

Thanks. I worked on the document some more. I will post a "Revision 1" soon with more implementation details.

I did look at the code. It doesn't look complicated. I first started by following a PR about bends. And looking for "Bend" in the code also helps figuring the relevant pieces of code.

This said, I'm not too much into the actual implementation right now. Rather I'm collecting past discussions about the articulations I'm most interested in from the Musescore forum so I have a larger view of the issues and how they have been solved (when they were solved). So far, I have collected a 130 pages word document.

Thanks for the reference to the VST guitar plugin. I'll go take a look at this.

In reply to by ypoissant2

I am not an experienced user of Guitar Pro. But I am a guitarist, so I have/have had to use this program from time to time, and I have found that regarding playback for effects such as glissando, bends, and other automatic input of hammers on and pulls off, GP is way ahead of MuseScore, indeed.
However, there are many other good reasons why we/I prefer to use MuseScore! 😂

To take stock of the issues raised.

This being said, it is not wrong to notice that, for lack of a better solution for the moment, the workaround is not that complicated: a simple text (H and P.O., eg) that you place in a custom palette for reuse, and once the symbols are in place, you move all them via the Inspector, for centering over the slurs, via the feature/selection of all similar elements.

In reply to by ypoissant2

A very interesting document. Most effects can be notated in MS but playback rendering could certainly be improved. e.g. hammer-on and pull-off can be added to a palette but change to playback, (less attack, fret noise), has to be modelled manually.

Have you had a look at left hand vibrato at all? (Classical guitar)

Guitar Pro certainly has a large set of well implemented effects which automatically affect playback – but they are as a company, of course, guitar focused so they can concentrate their effort.

GPFx.png

In reply to by yonah_ag

Regarding left hand vibrato. In itself, that shouldn't be too difficult to implement. However, the more I collect information about those kind of articulations, the more I become inclined to see all this as requiring some kind of infrastructure, that once in place would make it easier to add further articulation rendering. This is what is being taking shape in my head at least.

In reply to by yonah_ag

I'm dreaming out loud here, but as I gather information about the articulations and as I plot those articulation functions, I see more and more similar patterns that come over and over. Patterns that are assembled into articulations. The concept of pitch bend with ease-in, ease-out, hold, for example. Bend with parameterable ease-in and ease-out is quite powerful.

So the idea that is starting to take form is a sort of language for describing the assembly of patterns contained in an articulation. The terms in the language would be parameterable according to pitch over time. Rendering the language would be different for MIDI 1 than for MIDI 2.

While it may be realistic, at least partially, it may turn out to be a too big undertaking. I just hope that something useful is going to come out of this.

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