Guitar Laissez Vibrer -- playback interpreter --

• Mar 29, 2021 - 07:27

Many of those scoring guitar music want to employ simple rhythmic notation; additionally they want score playback to sound as if played on guitar. This means that many notes need durations far longer than indicated by their face value.

The sustain pedal is a likely candidate for the job BUT it easily adds too much sustain.

"Let Ring/Laissez Vibrer" is equivalent to sustain so it offers no solution.

So I'm requesting a "Guitar-specific Laissez Vibrer" function or articulation, as illustrated in the attached score. I'll provide further examples, as mentioned in the score, if there's sufficient interest.

Interpreting Guitar Arpeggio Durations.mscz

Scorster

Interpreting Guitar Arpeggio Durations 02.png


Comments

What the programmer has to do for "let-ring" is actually very visually obvious. // I do not know how it will be coded.
The code will look at each line in the TAB staff, and increasing the lengthening of the played notes until they see a new note (maybe a few ticks earlier). // It will do this (like sustain-pedal) without changing the actual duration of the note and on the fly.

By the way, it would be nice if let-ring can be used extensively (for example 32, 64 measures) up to size. In other words, instead of a line extending at the bottom, just a termination symbol at the end. Such as the "pedal-off" symbol used for the sustain pedal.
example: let-ring                                         _| .

Note: We can also do this from the Inspector by unchecking the "Line visible" box, But this makes the "off mark" at the end invisible. The "no-middle-line" option would also be nice.

In reply to by Ziya Mete Demircan

"The code will look at each line in the TAB staff, and increasing the lengthening of the played notes until they see a new note".

I've got this working in a plugout but there is a complication. Seeing a new note is not sufficient: detection of a fret being released to change chords is also needed. This is further comp!icated by the fact that some frets can be maintained during a chord change.

In reply to by Ziya Mete Demircan

Here's a couple of examples:

Ring2.png

Changing from Am to D7 with the fingering shown

The notes from Am will stop ringing at the D7 chord except for string 5. Open string 5 can ring to the C chord of the next measure because the D7 has nothing on string 5 to stop it.

Changing from C to D with the fingering shown

All the notes from C will stop at the D chord, including string 5.
String 5 cannot continue to ring since finger 3 has been lifted to make the D chord.

In reply to by yonah_ag

I think you are trying to define auto let-ring. In other words, since there is no specific let-ring line, it is not specified on the TAB when to lifted the fingers.

The thing is, TAB notation doesn't contain any finger numbers or information. Therefore, we cannot use information that does not exist.

If we don't see any numbers, markings or let-ring's end mark ( _| ) , it means that string is still ringing/sounding.

Everything would be clearer if there were Let-ring lines here:

0 - - 2 - - | 0 - - 2 - -
1 - - 1 - - | 1 - - 3 - - 
2 - - 2 - - | 0 - - 2 - -
2 - - 0 - - | 2 - - 0 - -
0 - - - - - | 3 - - - - -
LR_________| LR____|LR____| <== Those last two aren't really necessary but I assume there might be an arpeggio here.

In reply to by Ziya Mete Demircan

I am coding auto-let ring and it's almost fully working without any need for "Let Ring" lines. I guess that I could require them but this needs to be on a string-by-string basis and starts to get messy.

"If we don't see any numbers, markings or let-ring's end mark ( _| ) , it means that string is still ringing/sounding." – This is the final issue that I am addressing and your statement needs a small qualification.

In my example, looking at string 5 of the chord change from C to D there is no fret number nor _| but string 5 cannot continue to ring because the finger on fret 3 has been lifted to make the D chord. Should I stop the fret 3 ring or should it continue because the guitar soundboard is already resonating?

There is an implied "lift fingers" at the chord symbol – Harmony tag in the XML – so I do have information to work with.

(The finger numbers are irrelevant other than to help explain why string 5 fret 3 may have to stop ringing.)

In reply to by yonah_ag

yonah_ag wrote >> I am coding auto-let ring and it's almost fully working without any need for "Let Ring" lines.

I'm excited about your progress!

What is required to use the plug-out locally? Also, I'm glad to supply you with test scores.

yonah_ag wrote >>I guess that I could require ["Let Ring" lines] but this needs to be on a string-by-string basis and starts to get messy.

For my purposes I'd only want to see some indication at the beginning of the score, like FILR, which specifies the desired Let Ring. I would not want a Let Ring line for every instance of lengthened play duration.

scorster

In reply to by scorster

^

Plugout Requirements

MSCX TAB score and Microsoft Excel.

Current status

1) Score must be in a single voice.

2) Calculation is working and deals with notes, rests, ties, mutes, (string ghost notes), and ontimes.

3) Shortest note duration is 1/64th note but is easy to change if required - it could be a parameter for the plugout, (as could max ring and number of measures to look ahead), it's all about performance.

Still to do, in order of priority

1) Set the calculated ring back into the XML Events-Event.len tag, (or create these tags if not already present for a note). This will give a useable beta version for testing/debugging with real scores.

2) Deal with implied fret releases due to chord changes, (see above discussion with Ziya Mete Demircan). I'm not sure of the best way forward with these. Chord symbols are seen as Harmony tags in the XML.

3) Deal with repeats and jumps since there will be a break in the flow of measures.

4) Consideration of 2 voice scores.

In reply to by Ziya Mete Demircan

This is a very simplistic example of what often is done on a guitar which is worth being noted down as TAB. Your example is better transcribed as chord markers with a fretboard display above the other scores ;-)

In a more realistic example single strings have independent ringing spans, some get voluntarily muted to avoid dissonances, others we let ring either because they fit the next chord or because we like the dissonance.

A single "let ring" below all strings just isn't up to the task.

Just in case you missed it I attached a (slightly) more complex example (the intro to Under The Bridge by the Red Hot Chili Peppers) in which I manually drew out the length of the notes to what a human player would do using the PRE.

In reply to by Alexander Fetke

It is deliberately a simplistic example for the sake of clarity because I'm in two minds on how to deal with chord changes. In this simple example how do you think I should handle the C to D change regarding string 5? On a real guitar the C note on string 5 stops ringing as soon as the finger is lifted from fret 3. Should I try to detect this, ignore it or make a parameter for users to configure the plugout to suit their needs?

I have the independent string ringing working and it handles rests, ties and mutes.

I will use your example to test the code but I will need a version that doesn't already have PRE tweaks to achieve the ring – otherwise I won't be able to see what my code does.

In reply to by yonah_ag

You can (kind of) reset the lengths in the PRE by first selecting all notes (drag a rectangle across the whole PRE score) and then swipe across the lower UI field with a pressed mouse button in the height of the 1000-length.
It's not precise because this "drawing" way of doing things is only as accurate as your mouse movement but maybe that's enough.

I found no better way to reset the manually changed lengths to exactly 1000 than either do it again manually for each note separately or recreate the whole score without touching the PRE for its notes.

In reply to by Alexander Fetke

Hi Alexander,

I've dropped in late on this comment, and I'm not sure I follow.

Sounds like you're saying there's no mechanism in Musescore's PRE to reset play durations that one has edited them in the PRE? Is that correct?

In a similar vein, I'm wondering if there's a Musescore function in (in the PRE or elsewhere) to set the play duration of a note to 100% of the note's face value ... or to x% of the note's face value. Do you know if that's possible?

Thanks!

scorster

In reply to by scorster

I think for single notes setting the length value to 1000 in the widget in the PRE is possible. But for more than one note selected, the widget was grayed out for me (probably indicating that the value isn't the same for all selected notes). It would have been extremely tedious to do this for each note again.

In reply to by yonah_ag

String 5 (A) when changing from the C to the D chord changes from being pressed in fret 3 to being not played. Being not played should be denoted (ideally) by a muting, i.e. an X on the string or similar. At least that'what I would find most intuitive.

Alternatively one can play the open A string along the D chord (D/A i.e. with A in the bass), then a 0 should be denoted on that string.

In reply to by yonah_ag

This "which is not correct" is based on your special knowledge about the involved chords and that the 2-3-2-0 looks like a D major. based on your world-knowledge you assume then that the 3 on the A string is supposed to stop (so you infer the chord to be 2-3-2-0-×-×).

That using of world-knowledge was what I was referring to earlier in the discussion. I propose to not use it. Without using such additional information, the denoted 2-3-2-0 could as well be interpreted as a 2-3-2-0-3 (if the A string was pressed on 3 before).

Why not use it? For one, it's not easy to implement and also a little harder to understand for the user. (Computers trying to be clever are always a PITA.) Second, it's complicated. What if the D chord doesn't pop up right away but is played as an arpeggio of sixteenth notes, maybe in a complex pattern? What if the 3 really is supposed to keep ringing because a D7 was intended? I just don't see that we can automate a proper distinction between these edge cases.

In reply to by Alexander Fetke

My plugout has no pretensions whatsoever about being 'clever'. There is no knowledge of chords being used at all. I do not look at the 2-3-2-0 pattern: I only look at the data in the MSCX file. In this instance the file has chord symbols as shown which present themselves as Harmony tags in the XML. At a chord change it is most common to release the fret fingers and thereby stop the ring.

So, I have programmed an option into the plugout called Ring through chord changes to give the user control of what action to take with Harmony tags. A value of Yes simply continues the ring and relies on the user to provide explicit string mutes if required, whilst a value of No stops the ring.

LetRingUI.png

In reply to by yonah_ag

There is another option called Ring through rests which gives the user control over the action taken at rest symbols. Yes rings through rests as if they were not there and No mutes all strings.

I may also add a yes/no for Ring through final barline.

In reply to by yonah_ag

Oh! I get it: A bunch of notes started at the same time is handled differently than the same bunch of notes started in sequence (but still played together on a fretboard typically).

Yes, if this distinction is made in MuseScore anyway, I think your option (play-through-...) are a good solution 🙂

In reply to by yonah_ag

@yonah_ag...
I am following this topic and applaud your efforts.

From what I'm reading, this example (from a popular classical guitar piece) seems like it is suited for your playback interpreter:
Romance.mscz

In performing, any competent guitarist would let the "melody" notes vibrate (along with the arpeggio) to prevent any "choppy" sounding playback.
I have included the TAB in this file so you can clearly visualize the "chord forms" using TAB frets -- rather than needing to visualize finger/fret/string positions from the (treble clef) standard notation.

Is something like the file attached above what you intend to interpret?

Regards.

In reply to by Jm6stringer

Thanks for your feedback.

The plugout does exactly what you say: it allows notes to ring as would a competent guitarist. The plugout only works with TAB. So do I.

I will start a new thread this week as this one is getting a bit fragmented and I am almost ready with a beta version for user feedback. I will include your score for early testing as it looks like a good example.

In reply to by yonah_ag

I sitll don't understand what's wrong with the exact notation shown above. Nothing here seems even slightly remotely difficult. Enter the notes exactly as shown, using unive3rsl centuries-old music notation practice. Then if you need some note to play longer, just adjust its playback length. Why invent a whole new notation for something standard notation already handles perfectly?

In reply to by Marc Sabatella

I have a custom version of the plugin for this 'hack', based on the articulation plugin but it is this and PRE editing which I refer to as hacks.

This current thread summarises very well the "let ring" and Temporal Onset Beaming which would improve scores for guitar and similar instruments.

In reply to by Marc Sabatella

I would be very interested in which plugin you propose concretely. Maybe there is one which does what all guitarists want? And that would be: let ring until this string is used again or explicitly muted.

Using the PRE (my current workaround) means adjusting the length of each note in a picking pattern. That's clearly not a good way to handle this. It works, yes, but one feels like the computer isn't helping but putting stones in your way to a proper playback.

In reply to by yonah_ag

I'm not so sure about the necessity of an implicit muting based on a chord change at all.
This is how I understand what you mean: I first grip an E chord, play all strings, then I change the grip to a G chord, so the D string should be muted as the finger in fret 2 is lifted.
But there are many cases where a kept-ringing string is part of a piece and intended. In such a case an implicit muting wouldn't be wanted. See my added example of a simple chord change from D to G and back. In my case I want the high e string to keep ringing across the chord change.
I think the X in the tab to mute the string explicitly is a better solution.

In reply to by Alexander Fetke

I mean the opposite. On changing from G-major, (320003), to D-major, (xx0232), the open strings should continue to ring but the fretted 6th, 5th and 1st strings would be released. Your picture shows the first string ringing but there has to be a moment when you release fret 3 to change the chord. This moment is the gap that I am talking about.

X is not sufficient as a mute because it contains no string information in the saved file.

In reply to by yonah_ag

The score I posted might look like a change of chord from D to G after the fourth note but actually it isn't. It is a change to G7+, but I guess I normally wouldn't notate that. I only would notate the score. For musescore, I could well live with having to notate Xs on some strings together with the fifth note.
Anyway, some weird automatic detection of chord change after the fourth note (what I understood you consider) which would mute the high e string isn't going to be a perfect solution.
The X needs to specify which string is supposed to be muted of course. Otherwise it is not up to the task.

In reply to by Alexander Fetke

How would you specify the string with a text "X"? Why not use a silent "ghost" note?

If a string is open or fretting is maintained between chords then ring can continue. If fret fingers are lifted from certain strings then, on those strings, ring has to stop. I'm just trying to guage how short this stop can be. Maybe 1/10th of a second?

In reply to by yonah_ag

Converting the length value to another unit such as seconds or ticks will be cumbersome. Because this is an imaginary value and no matter what value the note is, the full note length is always given as 1000.
Instead, a percentage value can be given over the value of total-duration: 99%, for example. Because these changes should be made as quickly as possible. // Yes, this approach is not ideal, but it's useful as a quick and average solution.

In reply to by Ziya Mete Demircan

It's because the note value is 1000 ‰ that I am thinking of an absolute value. This 1000 ‰ is a different absolute length for each note type so a 99% duration gap would be variable. The further complication is scaling to the tempo. A score marked 60 bpm sets crotchets to have a 1000 ‰ duration of 1 second.

However, I think that I am making this detail over-complicated and I prefer your suggestion. Thanks!

In reply to by yonah_ag

I don't speak about a text "x", I just state that the x for muting (however implemented) needs to be specific to a string, I don't care how this is done (a ghost note seems to be a viable way).

I tried to tell you that in an apparent chord change not always all fingers are lifted. In my example one might think that after the first four notes the chord is changed and thus the high e string is supposed to be muted. But in fact a (not notated) finger stays on that string (the one on the high e string), resulting in a more complicated chord (G7+) which would I not notate, but play. I would rather notate that the strings b, g, and d are to be muted explicitly.

This I propose because I think it is way easier than automatically figuring out which strings are to be muted at a chord change and then running into the problem that the composer might want such a string to stay ringing. Doing all mutes explicitly is surely simpler for the implementer of the plugin :)

In reply to by Alexander Fetke

I'm taking a simple approach based on what actually is notated on a measure-by-measure, string-by-string basis. I will not attempt any processing of implied, but not notated, information. There will not be any intelligent chord change processing. Sorry for any confusion.

Yes, muting clearly needs to be string specific – unlike rests which are voice specific. In practise I don't actually see many mutes in the TABs that I play so I might ignore them to start with and concentrate on getting the basic "let ring" working.

There won't be any more progress until the weekend.

Regarding (b)

How many milliseconds would be realistic for the ring to stop before the pluck.

Presumably ring should also stop on encountering a rest, otherwise there is no way to stop the ring short.

In reply to by yonah_ag

No, a rest is not specific enough since it covers all notes in a voice. There needs to be a way of applying a mute to an individual string. Maybe there is already something in MS for this.

Regarding (a) stop ring on pitch change: this would include chord changes where fingers are removed from the fretboard, e.g. G to D would release all frets. This would include the open D string even though there is no actual pitch change because the string will get plucked. Therefore pitch change is not quite the rule for stopping ring.

The rule needs cover: a subsequent fret number is encountered on the same string; a fret is released for a chord change; a fret is muted; the natural sustain of the note is reached.

I've got the basic processing working in terms of building a note map of the measures and calculating the ring duration. I'm using ghost notes for explicit string mutes but have had a rethink about rests. Since the initial plugout is only working in 1 voice it seems to me that rests in the score are almost Irrelevant, since a string will sustain thru rests, so I plan to use them as a way to mute all strings at the same time.

Any feedback on whether this makes sense, or not, is most welcome.

I now have to write or update the event tags with the calculated durations and the prototype will be ready to test.

First Trial

Score:
Ring3a.png

Before plugout:
Ring3b.png

After plugout:
Ring3c.png

Clearly there is too much ring as the notes have gone beyond legato but this is where a 99% factor will be applied next.
Chord fret release has been ignored pending suggestions.

In reply to by scorster

Will do when I finish work. Do you think that the final measure should ring through the end of score barline, (as shown), or stop at this barline?

I'm having an issue with ties as something has thrown a spanner in the works and they don't want to extend like other notes, even in PRE.

In reply to by yonah_ag

I know how ties work now, so I need to process these differently to regular notes. The ring time belongs with the first spanner and the duration base is the total tie length. I'll start a new thread once ties are managed properly and then invite some test snippets/scores.

RingTie.png

In reply to by yonah_ag

Ringing past the end is the more typical usecase I'd say, so I would prefer this.

I could well live with the let-ring feature working arbitrarily (undefined behavior) for any tied notes. If I make a new score using the new feature, I don't see any reason for tied notes whatsoever anymore.

In reply to by yonah_ag

Quite impressive Yonah. Sounds just like the sustains imparted by a skilled guitarist! In other words, this is more accurate than anything I've heard, Including Guitar Pro 7!

Once you've completed the Musescore plugout users can have realistic guitar playback without a ridiculous amount of effort and time spent tediously tweaking play durations in the Piano Roll Editor.

Kudo's!

Only thing better would be:

a)  when this is available in Musescore, processed on-the-fly, and does not necessarily change the play durations in the score so play durations needn't be explicitly extended in score.

b)  if there would also be the option—as your plugout provides—to implant the durations into the score, perhaps when preparing to export MIDI for another application.

The only problem I'm wondering about relates to copy/paste. For instance, when the user:

• copies an individual note with increased play duration
• pastes atop an existing note of lessor duration
• Result: The play duration resets to the face value of the paste destination note— i.e. the extended play duration is discarded. (My initial concern was that the each individually pasted note would carry the play duration of the source, but that does not appear to be the case.)

Fortunately we can copy/paste full and partial measures without loss of extended play intentionally extended durations.

Thanks for all this ... and carry on!

scorster

In reply to by scorster

 
On the fly would be ideal. Not sure what happens with MIDI event data on copy/paste but I will check. In any case I will most likely use the plugout as the final touch to finished scores. I think that my durations should appear in any mp3, MIDI or MusicXML export already.

The UI currently looks like this but I might add a means of selecting a range measures to apply it to:

LetRingUI.png

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