unify and tripleplay are a great combination for a midi guitarist. the midi curve '88 note weighted' '88 grand' seems to liven up many patches.
i've built a control surface with pitchbend, modulation, patch blending, triggers and more using the opendeck firmware which is just about stage-ready. here's me noodling around with a few patches, blending 'real' guitar in with that best of class wurli (i love that thing, sounds pretty neat being bent):
it's super nice to have modulation and other controls right there at your fingertips. one thing i haven't solved is how to assign cc2, cc11, & cc67 to either encoders or sliders, they work, but it's essentially impossible to return them to their original positions and especially with the cutoff that basically kills the patch.
there wasn't much tweaking required to get the tripleplay and unify to play nice together. however, tweaking patches for performance is likely to eat up a ton of time, simply because there are so many options.
unify = the best $80 i have ever spent, thanks. and the hive patches are great too.
Excellent video @kimyo, and thank you for your kind words about Unify. It's great to see it used in such innovative ways.
MIDI velocity curves certainly can "liven up" many patches, and can be super-important to get just the right dynamic response. Often, a synth will have too great a velocity range, and you can tame it by making a custom curve that doesn't go all the way to zero at the left, or all the way to 100% at the right.
Please explain a bit more about what you're trying to do with CCs and encoders/sliders. I think you're asking about more than one issue, and I'd like to understand better, in order to be able to give you helpful answers.
i haven't fully tested things out yet, but the problem goes away if i take the fsr's (round pressure sensitive dots) out of the picture.
when assigned to cc#2 and when cc#2 is controlling cutoff, the fsr's default behavior (return to zero once released) can kill the patch's output.
the problem doesn't occur if i assign cc#2 to a slider or encoder on its own. sliders are probably the best bet here, the encoders require far too many spins to move across the knob's range.
when assigned to cc#2 and when cc#2 is controlling cutoff, the fsr's default behavior (return to zero once released) can kill the patch's output.
This is why we have a response-curve for every parameter link on Unify's macro knobs. Some parameters should not go all the way to zero.
If a low-pass filter only passes frequencies below a given cutoff frequency FC, then if FC is set at zero, nothing gets through at all, and so you hear no sound. That's what I suspect is happening here.
One nice thing about Unify's parameter links is that when you drag the curve control-points with the mouse, the linked parameter changes in real-time, so you can hear the effect of setting it to that value. For a filter-cutoff, try selecting the parameter-link curve and dragging the leftmost control-point up and down. Drag it to the point where you still hear some sound, but it's as muffled as you think you want it to ever be. As long as that's the lowest point on the curve, you won't have the problem of the sound cutting off completely.
For filter cutoff parameters (and many others), you'll also usually want to change the curvature of the line. Do this while adjusting the connected knob through its full travel, so that the sound develops the way you want.
For details about editing parameter response-curves, see https://pluginguru.net/unify/manual/doku.php?id=realtime-params#adjusting_response_curves