Request: Mono ST with next-note velocity NOT tied to 1st note.

[MegsDC02]

Hello. I just came upon this thing: Surge XT is not able to control portamento time through velocity in single-trigger mono mode. Now, I have a feature request to make the single-trigger mono mode have separate velocity messages for each and every succeeding note so, for example, if the portamento time is mapped to velocity, then the velocity of each succeeding note in a legato line controls the portamento time rather than the portamento time being tied to the velocity of the first note in the legato line. I hope this feature gets considered and added into a future Surge XT release, thanks in advance!

[Andreya-Autumn]

Hello! Interesting request, thanks! I like the idea of velocity-controlled portamento. For sure this is not a change we'll make for XT1... too breaking. XT2 is the earliest it would make sense.

There's a conversation we've been having now and then about whether Mono and Mono ST (which would be called Legato in XT2) should even be a global setting, or if there should just be Mono plus Legato switches in the relevant modulators so you can mix and match.

Both ideas have their pros and cons, and it's too early to say which design we'll go for in the end. But if we do go for the more configurable option, the velocity modulator should indeed get the choice of retrig or legato.

For now, I think you'll have to use the regular Mono mode for this.

[baconpaul]

Ahh my answer on the subway didn’t go through

the primary problem here is on release of a note like a mono trill. The key map we keep of held notes by time doesn’t include velocity so if you do c e e release what velocity do you set? We just need to decide thst if we add this feature, it if we decide it’s the velocity of the resumed c we need to preserve that velocity too (which is just 128*16 floats it’s not impossible but we need to do it)

[mkruselj]

In that case it should actually be release velocity of the released note IMO.

[baconpaul]

Yeah i was thinking of that.
but so few devices have accurate release velocity
we should of course reset release velocity when you release

[MegsDC02]

Hello. For example: I play C-E-G in a legato phrase and the velocities are C:127, E:68, and G:92, then the portamento time if mapped to velocity currently still stays on its length at velocity 127 — but I wish that the velocity of the succeeding note, in this case the E's 68 and the G's 92, controls the portamento instead (and that there should be an option to have no portamento for any first detached note).

I recently made an attempt to model the brass family — including a handful of mutes — inside Surge XT (thanks to Audio Modeling's SWAM Trumpet when I demoed it, and Eric Bowing's Vital tutorial: https://youtu.be/HWAAtk6GpfM?si=X2pvFBpVHh1jvEGA), and was honestly disappointed by the fact that Surge XT doesn't have the features as I wish above, which Audio Modeling's SWAM series has (velocity controlling the attack loudness of the first note and the portamento/legato time of any succeeding note). Thanks in advance!

[baconpaul]

Yeah we get it! But it is also a breaking change and has complexities for the release - that’s what we are discussing here

[MegsDC02]

To be clear, it's the attack or note-on velocity which SWAM uses for that attack (again, for the first note) and portamento (again, for any succeeding note) control in a legato line, not the release or note-off velocity I'm talking about in this topic so far; the velocities 127, 68, and 92 I mentioned earlier are attack or note-on velocities, not release or note-off velocities. And no, it's not the release velocity I'd use for the portamento modulation in this case. TIA

[baconpaul]

Yes. We would want to set up both modulators properly if we made this change thought.

the problem is, in mono legato mode if you press c, press e, then release e, c sounds. What happens to velocity in that case..

[MegsDC02]

I'm fine setting the modulators separately for the velocity and the mono/legato, so that the legato phrase flows and the notes change smoothly with no breaks, in this case's example C-E-G without breaks, but the velocity of the succeeding notes control the portamento time as per the description above and portamento only triggers with notes after the first note in a legato phrase.

Oh, and one weakness SWAM Trumpet has that Surge XT doesn't: portamento goes only up to ~300 ms for SWAM Trumpet but Surge XT's up to four seconds, which is already quite long for a real brass portamento/glissando!

Edit: Also, I wish for legato too to have a crossfade time for note transitions!

I honestly hope my feature request (just like SWAM does) gets implemented at least in XT2, if not the next update! Thanks in advance...

[mkruselj]

Edit: Also, I wish for legato too to have a crossfade time for note transitions!

Surge is not a sample library so it doesn't need this.

[MegsDC02]

Edit: Also, I wish for legato too to have a crossfade time for note transitions!

Surge is not a sample library so it doesn't need this.

OK... But still, I'd personally think that my feature request concerning velocity modulation in legato passages would prove very useful for modeling ANY bowed and blown instrument with Surge XT!

[baconpaul]

yeah i agree having a mode where velocity adjusts via legato is a useful request.

[blancoberg]

Couldnt we add access to legato velocities via formula modulator to start with? cause that wouldnt brake anything at least.

It would be really useful for modeling for sure

[mkruselj]

The issue is the same: we don't save the velocity of the legatoed note in the voice manager. So it cannot even reach the formula modulator without that plumbing.

[baconpaul]

Yeah

so basically in the modes we call "reclaimVoiceFor" when we have legato (and in some other circumstances).

surge/src/common/SurgeSynthesizer.cpp

Line 1116 in 86c8ec7

if (recycleThis)

for legato playing

That actually does call resetVelocity

surge/src/common/SurgeSynthesizer.cpp

Line 5542 in 86c8ec7

void SurgeSynthesizer::reclaimVoiceFor(SurgeVoice *v, char key, char channel, char velocity,

with then resets the source

surge/src/common/dsp/SurgeVoice.h

Line 201 in 86c8ec7

void resetVelocity(int midiVelocity)

so the very first thing we should do is find out why that doesn't work. That code path is tricky and the only way i ever change it is by writing more regtests first.

And then what we would need to do - you can see the channel state object which gets updated when we don't need to create voices. That would need to get a velocity state map similarly which stored the data.

You could probably do it as a switch - this check would only need to happen at voice on. But step one would be a good midi keyboard and a bucket of print statements near the lines i highlighted.