Thanks for bringing this up!
Let me provide some context for this wish:
I’m working on a patch that simulates sidechain capabilities from a hardware compressor. The final stream of CC messages will be converted to control voltage to duck the VCA of an analog synth. (Edit: Or you could control CC7 Volume of a digital synth) I want this all to happen with as much “default/straightforward” midi data as possible, meaning we have note on, note off, note velocity and some CC parameters coming from the same MIDI channel to make it happen.
As I mentioned in another post, I only need the AD part of an ADSR curve. But as I look at my compressor this should probably be AR to stay consistent in compressor terminology.
So we have in a classic hardware compressor (Alesis 3630 and the likes):
Sidechain trigger/signal
Ratio
Threshold
Attack
Release
The “color/character” of the compressor
Bringing this to the Midihub:
Sidechain: a filtered pipeline to work with a dedicated channel and a stream of notes with the same note number, f.e. C1 which is the kick from a drum machine. Each incoming note restarts the process although a long Release can make this muddy in the real compressor world. We’re not after muddiness so a clean restart should do fine
Ratio: how deep the ducking goes, probably the final stage in the pipeline where we rescale the CC stream to make the effect more or less noticable/“pumping”. Let’s assume that the incoming note velocity determines the amount of ducking. The higher the C1 note velocity the deeper the ducking goes.
Threshold: this factor we probably can omit as this is the volume/energy the material has we want to treat. We are not aware of that so skip it.
Attack: “time based” factor in the process where we apply delay or not to the sidechain signal. So if we capture the note on event and turn this into a CC message with value 127 (the start of our curve), how long do we wait before doing this transform. Options: Free rate or BPM rate from an LFO, maybe sync delay
Release: the length of the CC stream/duration of the curve. Let’s assume we use the note length for this. When a note off occurs, this means the end of the duck and we bring everything to the initial state waiting for the next note trigger.
Color: here I see the different curves in action: logarithmic, exponential… the ease-in ease-out, ease-in-out equalizers
Sort of a Midihub exam in fact
So yes, I was studying the ADSR patch to see with what I can come up to make this happen. All tips and insights are highly appreciated.
There’s a number of aspects in your design brief which make the ADSR experiment –written for general use– overly complex for your needs
For example:
given you’re working with drum hits there’s likely no need to wait for a Note Off; a simple “A” then “D” will suffice
you might not need any of the complications having the patch handle interrupted envelopes (that needed some careful work to get it right!) – any given envelope will likely be all done before the next kick arrives.
I dunno whether you’ve spent much time delving into the patch, but you’ve likely seen that it’s got 180°phase Saw-Up LFOs with a Transform waiting after the Attack LFO to pick-up when it’s done it’s One-Shot.
Now, therein lies a little subtlety; the Range Low there is mapped to a CC which is derived from the LFO rate control
and it’s job is to get the last value in the LFO when the rate is less than 1Hz.
Upshot is, i think, the first tests to do are to see how quick you need the LFO to be cos it’s likely to get very jaggy if you want it fast (after all an Attack of 1/10 sec is going to leave you just 12 CC values of modulation…)
It might be best to start off with some simple experiments with a fixed rate “ease-in EQ’d” LFO to see how it sounds (I might even try a Triangle LFO accepting a symmetrical AR just for starting simplicity)
Footnotes
A Triangle LFO could be a nice expedient if linked with a “max” threshold mapping switch that changes the rate and maybe the EQ curve (then a “reset” switch back at the “min” threshold)
Another thing maybe worth looking at is millisec-rate Delay instead of one-shot; not looked into that strategy at depth but I think it might have several advantages over One-Shots for sub-1sec applications (pre-Delay via a threshold Transform, as fast as the MIDI queue will allow and modulating the feedback ammt could be fun for changing the exponential decay!)
the 1st value output is 5; that’s cos I wanted to keep the >100% feedback as low as poss but MH works with integers so 4 x 1.26 was the best lowest
the 3ms pic makes it fairly obvious that I’m slowing down the exponential increase once the values get high
(there’s also vm’s to reset the Attack delay. external maps can be ignored)
there’s a micro-delay between the Note onset and the first value.
A longer delay could be added by using Drop transform on some low threshold
I haven’t played around with making the Rescale slow down the Attack more – there might be some mileage in using a another Rescale on say 7-117 → 0-127 to “limit” the curve further
same 200ms Note in the DAW trace shows how much longer this approach needs
(A SawUp @30hz gives very few values: )
Notes:
In this trial, I used v-m’s to both change the rate and replace the CC# for the down slope
this allows us to use different EQs/Rescales should we choose to for each section
(they’re recombined via CC Remap at the end)
All this adds more pipework but avoids the end-triggering issues one needs to work-around with successive short One-shot Saws
Overall…
…I like the Delay approach as it allows a decent resolution in a very short period.
(I ran the 1ms and 3ms trials out via MIDI-DIN to a hardware sequencer for a proper test to be sure)
Delay, however, lends itself less to variables– much more a “fine-tune and leave” number. (having got the growth rates to work for a given set up, I’d only vary the delay time)
I quite like the modified exponential curves but the Pitch Shift property of Delay would also allow an EQ’d linear curve too. Gotta love MH for this sort of tinkering!
Nice work, @resonotter
Trying this out later as I don’t have enough time to explore this the coming days.
I did some experiments with converting note on and note off to CC for manual triggering a saw down and saw up LFO but that was not convincing.
I returned to just trigger a saw down LFO on note. LFO rate set to +/- 0.45Hz. Working at 170BPM at the moment meaning that’s a rate of +/- 1.5 bars. But I love working with Hz instead of synced to BPM as it sounds more refined. LFO is set to active mod and this gives a nice groovey feel which is important in the sidechain compressor world. For the project I’m working on it pumps like I want it to. Next step is making the Hz rate dynamically based on tempo probably…
The delay experiments look promising but I have to admit: With my sequencer I’m cheating on that aspect for now. In fact, I don’t use the “audible” kick as the sidechain signal but I take a copy of the kick track and use that as the trigger (which is a common tactic in the sidechain audio world: use another less boomy sound, f.e. a rim shot, as sidechain trigger). This way I can micro move the notes a few ticks back or forward until I have the response and groove I want.
So yes still baby steps on my side, with more time on my hands I’ll delve deeper.
not sure if I understand your figs but if you’re as slow as 0.45Hz no need for delay
if you’re in active mod what’s the source of main message?
“based on tempo” – is MH your Clock source and BPM modulated by CC?
reckon that puts it totally in the LFO field, then. (the Rate ↔ CC value relationship is not one I’ve really delved into apart from knowing 127 → 30Hz)
)