Plectrum sound sustaining

[sciurius]

When in Plectrum tracks a string is struck, it sounds until it is subsequently struck again, possibly on a different fret by a different chord.
However, the sustained sound is cut off when a groove command is encountered.

For example:

    Groove Foo
    1     C
    2     C
    3     C
    4     C

Notes of the C chord will sustain up to and including bar 4.

    Groove Foo
    1     C
    2     C
    Groove Foo
    3     C
    4     C

Now the sustained sound will be cut off after bar 2.

If there a way to avoid this? I.e., sustain strings across groove changes?

[bvdp]

I think that GROOVE sort of assumes we're starting over. However, the CORRECT way to handle this stuff does not involve many groove commands (ie, every few bars). Instead define a groove to handle multiple bar sequences. I think that "most" music is written/played this way and makes sense most of the time.

[sciurius]

So ideally one big groove that handles the whole song

[bvdp]

No, not at all Johan But, here's the catch ... if you let the sound sustain over a groove change, just what mechanism do you use to stop it? And, do you further permit selected strings to continue to sound or all? Yes, I know you'll say "well, just play another chord and that will take care of it". But, if the groove changes so that there is no longer a plectrum track being sounded ... then what? Right now, I agree we are using a big hand to transition between grooves, but not sure how it could be otherwise. At least now the strings are guaranteed to be off after a change ... is that not better?

I suppose we could have a special conditional "DONTCLEAR" and you could do something like:

    GROOVE MONTY DONTCLEAR=Plectrum   /// select a new groove, but don't stop strings.

and then have this checked for in pat.py. Just wrap line 1303 with "If not Plectrum not in DontClear self.doMidiClear()"

DontClear? DontStop? KeepRinging?

Have a go. And I'd vote to have it as a one-time shot.

[sciurius]

I'm currently investigating how Plectrum mode could be improved to be more natural to plectrum instrument players.
Stay tuned (but don't hold your breath).

[bvdp]

I'm hoping for some time next week to look at the sustain idea. All this is hard!

[bvdp]

Just wondering about this plectrum stuff. Would it be better if we were to do some work on the solo tracks to make it easier to enter "multi-string" stuff. Solo tracks already do things like continuing over groove changes, etc (I think, he says ). I might be totally in a haze here since I don't play fretted instruments ... let me know what you think. My thought is that for chording the current setup is probably fine; for finger picking a solo (or solo like) track might be more appropriate. ??

[sciurius]

I'll surely investigate these suggestions.

In the mean time I found a couple of things that could improve the current Plectrum mode.

The 'strumming delay' is expressed in ticks. I find it more intuitive to express it in fraction of beats. For example, 0.667 with a 6 string strum would nicely fill a 4-beat measure.

This could go alongside the current implementation by allowing fractions instead of numbers:

    Sequence { 1.0 4/6 120 120 120 120 120 100 }

Another thing is to allow more flexible string definitions, and retain order. For example

    Sequence { 1.0 4/6 6:120 1-5:100 }

this would pluck string 6, 1, 2, 3, 4 and 5, in that order. A negative value for the fraction will reverse the order. (Note that this may be subject to the setting of Plectrum Strum to Start/End; I fail to see a suitable purpose for Plectrum Strum Center.)

You can make fancy patterns like:

    1 3/6 6:90 5,3,2,4,1:80

or

    1 3/6 6:90 1,1,1,1,1:80

Just some thoughts...

[bvdp]

Just wondering about this plectrum stuff. Would it be better if we were to do some work on the solo tracks to make it easier to enter "multi-string" stuff. Solo tracks already do things like continuing over groove changes, etc (I think, he says ). I might be totally in a haze here since I don't play fretted instruments ... let me know what you think. My thought is that for chording the current setup is probably fine; for finger picking a solo (or solo like) track might be more appropriate. ??

Maybe a Pizz[icacto] track? Mind you, do guitar players think in notes in terms of 'a', 'b', etc? Certainly other string players (violin, cello, etc) do. If we have a PIZZ track would this solve anything for guitar folk?

This afternoon I will look at my earlier suggestion of permitting a continued sustain over a groove change.

[sciurius]

I've played a bit with Solo tracks. They are nice but still not what I'm looking for.

An essential aspect of guitar playing is that strings sound until explicitly stopped. Since stopping a string is an explicit action, it doesn't happen often in (most) guitar music. Notes just sound until another note is played on the same string. Or the note is fingered and the finger needs to lift to take another position.

This way of playing notes is pretty much what Plectrum implements.

MMA grooves are basically playing instructions. Most songs use just a couple of grooves. For example, a typical AABA jazz song would use a groove for intro, one for the A-part, one for the B-part, and one for the coda.

A fingerpicking style of guitar playing could easily require different patterns for almost every chord. Sometimes this can be realized by using Plectrum Shapes (see the mandala example in egs/plectrum). Defining a lot of grooves and using them is doable. Writing a song takes time anyway. But, as we found out, switching grooves stops ringing strings and that is what we do not want -- strings should only stop ringing when another note is played on the same string, or the note is explicitly stopped.

The DONTCLEAR option (or whatever it will be named) seems like a good solution, but IMHO it should be default for Plectrum tracks.

[bvdp]

I need a 2nd set of eyes to look at the code!

1. So far, what I have figured out is that the muting (and calls are are local to the patPlectrum.py module. So, that is a good thing.

2. The strings are muted (stopped) in the function grooveFinish(). If you insert a simple 'return' at the top of the that function, the strings are never muted. Not quite what we want, but close. If we just do it that way the strings will NEVER stop sounding (well, the all-off midi code at the end does, but that is just gross).

3. There are only 3 calls to grooveFinish(). See bars (appx) 89, 95 and 246. Commenting out the call to grooveFinish() in any of those functions does NOT solve the problem. So, I have to assume that a combination is needed?

4. The grooveFinish() code just calls endVibration() and that seems fine.

So ... what is the problem?

[sciurius]

I think the culprit is doMidiClear, which is both generic (class PC) as specific in the Plectrum class. It is called for groove changes and for the final wrapup.

The attached patch adds a second argument 'final' (default: false) to doMidiClear. main.py calls this with final=true upon the final cleanup. The Plectrum version of doMidiClear will only silence strings when its the final call.

AFAICS this fixes the preliminary silencing and keeps the final silencing in tact.

Now we need a way to stop sounding strings on demand. Maybe it is a uncommon approach (i.e., dirty trick) but how about a track specific variable $_Plectrum_Sustain, with values 'On', 'Off' and 'Stop'? Setting it to On will enable the sounding strings behaviour (though I still think it should be default), setting it to Off silences sounding strings and disables the sounding strings behaviour and setting it to 'Stop' will silence sounding strings without affecting the on/off status.

[bvdp]

I'll look at the patch later, but see no problems.

To the 2nd half of the mail ... do you want to mute strings on demand? Instead of an all ON or OFF setting, why not add a Plectrum Mute command? So, for a track that is already sounding you might want to mute just one string (bass?) ... so a syntax for 6 strings might be might be "Plectrum Mute True 0 0 0 True 0" which would mute 1 and 5. And, to get fancy, you could "Plectrum Mute ALL"?

Stopping a string and NOT effecting its status is a bad idea

[sciurius]

The idea behind $_Plectrum_Sustain is to be able to switch the sustain behaviour on and off. The 'Stop' version of the command would stop the currently sounding strings (and, of course, change their sounding status accordingly) but not change the $_Plectrum_Sustain on/off status. So when $_Plectrum_Sustain is on, it will remain on after a Set $_Plectrum_Sustain stop.

The Plectrum Mute command is, of course, better and more flexible. I assume it takes the strings in guitar order (low to high).
It may not be a wise choice to use True and 0; True/False or 1/0 are more consistent. Also, I'd suggest Plectrum Mute without strings to be a shortcut for mute all.

Also, to me (and others) the word 'mute' means to silence and keep silent (cf. mute the sound of the computer -- it stays muted until unmuted). I'm not happy with 'stop' either but my knowledge of English fails to find a better word. See also https://en.wikibooks.org/wiki/Guitar/Muting_and_Raking.

[bvdp]

The idea behind $_Plectrum_Sustain is to be able to switch the sustain behaviour on and off. The 'Stop' version of the command would stop the currently sounding strings (and, of course, change their sounding status accordingly) but not change the $_Plectrum_Sustain on/off status. So when $_Plectrum_Sustain is on, it will remain on after a Set $_Plectrum_Sustain stop.

I'm still not seeing this. A plectrum track takes a sequence/pattern and "plucks" strings and leaves them ringing until they decay to silence due to the underlying MIDI controller, another pattern is invoked which plucks different strings, or the end of the track is reached. Right now the problem is that a change in the current groove stops all the ringing. The patches you suggest above fix the groove change issue.

So, now you're suggesting to switch the sustain behaviour on/off. Is the suggestion to instantly turn off strings when setting the variable ... or when the groove changes? I'm afraid that this might be getting too complex to understand and/or use

The Plectrum Mute command is, of course, better and more flexible. I assume it takes the strings in guitar order (low to high).
It may not be a wise choice to use True and 0; True/False or 1/0 are more consistent. Also, I'd suggest Plectrum Mute without strings to be a shortcut for mute all.

My thought on the MUTE command is to by-pass the current ringing/sustaining of the strings. So, if you have a pattern which will cause a certain string(s) to continue to ring (forever?), you can use MUTE to stop them. My suggestion was just setting up placeholders, but I'm thinking now that using '-' to mean 'continue' and 'True' or '1' to mean "Mute".  We're using '-' right now in the defining the pattern to mean "continue from the last pattern", so it might make some sense to let that mean "continue to ring" in the Mute command.

Also, to me (and others) the word 'mute' means to silence and keep silent (cf. mute the sound of the computer -- it stays muted until unmuted). I'm not happy with 'stop' either but my knowledge of English fails to find a better word. See also https://en.wikibooks.org/wiki/Guitar/Muting_and_Raking.

 Instead of MUTE ... we could use DAMPEN or SILENCE if it makes more sense.