Feature request: gradations of palm muting

[zuzute]

Hello.

As we all know, TG uses very hard PM (25% of note duration):

It was fine in the 80s when you pressed your palm hard directly above the bridge pickup but now is a different situation. Many bands use lighter PM and/or different PM methods in one song. I think Darkspace is a good example.

So what I propose: at least 2 (better if 3) PM gradations. 33% and 66% or 25%-50%-75%. Even better if percents were configurable (maybe in the future?). To differentiate, P.M. can be used for hard, P.m. for medium, and p.m. for light PM.

Thoughts?

[guiv42]

Thoughts?

It makes sense. Adding a dialog to define effect's parameters is clearly possible (already implemented for harmonics, bends...) A difficult point though: currently pm effect is attached to note, not to beat. So you could define in the same beat 1 "hard-pm" note and 1 "light-pm" note. What to display then? So it seems to me we should forbid this, and attach pm effect to beat first.

Note: implementation of this feature would break file format compatibility (additional data to store)

[zuzute]

It makes sense. Adding a dialog to define effect's parameters is clearly possible (already implemented for harmonics, bends...) A difficult point though: currently pm effect is attached to note, not to beat. So you could define in the same beat 1 "hard-pm" note and 1 "light-pm" note. What to display then? So it seems to me we should forbid this, and attach pm effect to beat first.

That can be a valid technique too when you use a "diagonal" PM: use lighter for thicker strings and harder for thinner strings, to get a less bright sound. Sometimes even some strings are muted, and others are not. So attaching PM to a beat would be a serious limitation. I can see 2 solutions: 1) display the PM type of the lower string with some mark that shows that PM levels are different, i.e. P.M.+ or P.M.*. But it'll make the printed score (I still do that sometimes!) more cryptic. 2) just print all PM types vertically, usually it's 2-3 notes and should be fine in most cases.

See, the 3 effects printed under the note just fine. It may look a little ugly with 3 PMs, but I don't have a better idea right now.

Note: implementation of this feature would break file format compatibility (additional data to store)

That's the problem. It's not good to break compatibility when many people still thinking about what to do: switch to a new fork or use the old one where all issues are known. Maybe mark the proposal as a low priority and schedule it for, say 2.0? Your choice, of course.

[guiv42]

Thanks for your feedback.

attaching PM to a beat would be a serious limitation

OK, clear. Simpler to keep existing data structure so.

About graphical layout, I would be in favor of one single symbol to show there are heterogeneous PM effects on the same beat. Multiplying the symbols increases complexity of vertical spacing definition (not even talking about mobile app where space is limited).

It's not good to break compatibility when many people still thinking about what to do: switch to a new fork or use the old one where all issues are known

That's the point. This question is currently open (see this discussion). It'll need to be done one day, as several new feature requests require this evolution. So we'll postpone them for now, and try to integrate all of them together in a future release to take maximum benefit out of this compatibility break.

[zuzute]

About graphical layout, I would be in favor of one single symbol to show there are heterogeneous PM effects on the same beat. Multiplying the symbols increases complexity of vertical spacing definition (not even talking about mobile app where space is limited).

Seems reasonable. 5-6 symbols above/below the score can be too much even for a desktop version (it may increase the track's height and therefore reduce visible tracks etc). Something like: "P.M:hml" where hml are heavy, medium, light? Kind of ugly. But we still have time to think about it.

That's the point. This question is currently open (see this discussion). It'll need to be done one day, as several new feature requests require this evolution. So we'll postpone them for now, and try to integrate all of them together in a future release to take maximum benefit out of this compatibility break.

Yup. That's the right way. Will check that discussion now, thanks.