MIDI lag question

I'm adding this onto the post as it's all related to the work I'm doing.

It seems the Macro Knobs in Unify are either handled prior to any MIDI Effect or are unaffected by MIDI Effects. Do you know if that's true? I tested with MIDI Mapper, mapping the MW to another CC, but moving the MW still moved the Macro 1 knob. I was hoping to lag the Unify Macro Knobs with the effect, but I don't think it will work

My main goal was to get the lag working on VSTs outside of Guru Sampler, and that piece is working.  I ran into this unexpected twist.

I have answered my own question.  I realized it won't make sense for the Macro Knobs to listen to MIDI Effects.  A MIDI Effect is per layer and the Macro Knobs are global across the patch and the entire system.

@ssquared

Unify does indeed run incoming MIDI past the macro knobs before sending what remains through the layers (including MIDI effect layers). Hence, macro knobs won't be affected by MIDI effects in the same instance.

However, MIDI passed to an embedded Unify instance will be processed by any MIDI effects which precede it, so you can certainly use MIDI effects to control macro knobs. This was used in several patches (an example is BPM ORG - Pulsation TD from the Standard Library) to create knob movement before the addition of knob LFOs in Unify 2.

@getdunne

Thank you so much for the reply.  That worked!  I really appreciate it.  This is so cool.

I was also wondering about the time value on the lag knob in Guru Sampler.  With the knob at the maximum of 2.5 seconds, I get around 6 seconds of lag time.  I am trying to mimic the lag behavior in Unify and noticed this.  It's easiest to verify when modifying pitch as it is much easier to tell when the note stops gliding up.  I'm interested to know if there is a reason why it was handled this way.  I did go back to Unify 1.0, and it seemed to work that way as well.

Thank you for any insight you can provide.

@ssquared I wasn't involved in the development of Guru Sampler 2.

@Wavesequencer can you answer this question about lag times?

I have to admit that I just copied the lag calculation functionality from Unify1/Gurusampler 1 pitch and mod-wheel lag calculations code, and I didn't think to check if the times were accurate as it seemed to work as expected.

To my ears the pitch bend time at full lag in GS1 and GS2 are about the same (the one second setting seems more like 1.5 to 2 seconds).

I applied the same simple lag processing to the aftertouch smoothing, LFO fade-in and LFO smoothing controls.

For the aftertouch and modwheel lag in GS2 I increased the knob max setting to 2.5 seconds.. but it's probably more like 5 given the pitch bend lag appears to be slower than the knob indicates.

If it's of interest, here is an example of the code:

double deltaT = (self.mChunkSize / self.sampleRateHz);
// filter pitch bend
float lagF = float(deltaT / (deltaT + globalVoiceParams.pitchBendLagTimeConstant));
float lagC = 1.0f - lagF;
globalVoiceParams.filteredBendFraction = lagC * globalVoiceParams.filteredBendFraction + lagF * globalVoiceParams.pitchBendFraction;

(One pole filter)

@wavesequencer

This is absolutely fantastic.  I am learning so much.  I appreciate the input from both of you.  This is brand-new territory for me.

Yeah.  I never thought twice about verifying the time in Unify unti now.  Now I understand the difference and why the lag time in Unify does not match the input value.  I am using a duration-based lag.  The lag is set to last for the length defined by the user.  Unify is using a time-constant-based lag.  The time-constant is defined in globalVoiceParams.pitchBendLagTimeConstant.  This doesn't define length of time, but how long it takes to reach 63% of the requested value.  And because it's exponential, it will take longer than the requested time to reach the peak.  I'm probably repeating stuff you already know.  I did not know about this until tonight.

Now I understand the time differences which helps me better think through the UI.  I currently have options for "Precise" and "Musical" (which simulated Unify).  I simulated the Unify behavior by warping the length of time to last longer, but maybe I will actually implement the true calculation.  Although, at this point, I may remove the options all together and leave it duration-based only.

Waking up this morning it all make sense now.  The Unify version uses the one pole filter to.provide a more natural shape to changes.  I am using a special curve to produce that.

Again.  This was all super enlightening.  I am going to stick with duration-based lag for now.  Especially since I might add a note length/BPM option if I decide on updating this and that will require exact timing.