Using a MIDI CC to control multiple sequentially selected variables
Hi all,
Have energetically returned to using Max after something like a four-year hiatus. I've been creating a control surface for my Edirol controller, and have lost track of some of my old archived sub-patches for handling MIDI data like MidiLearn etc. but while I've managed to solve a few old problems, there is one that still vexes me because I know I had a really elegant solution for it! It is as follows...
I'm using a single rotary control to control two or more different variables (for a filter plug-in for example) and when I hit a button, it will target the knob at each variable sequentially and the knob will set each one to a 0-127. When I toggle back to a previously stored variable and operate the control, the variable (naturally) jumps to whatever the rotary control wants to do next - causing erratic jumps. What it should do, is wait for the control to be returned to it's stored value for that variable, and only allow itself to be changed when that is true.
I've attached the patch that performs it's current undesired behaviour...
I hope someone here may be able to set me on the path to unlocking a nice compact solution for this!
Cheeky post to bump back to top... :)
If I understand properly what You describe, You need
to block midi reception untill it matches last stored value.
Depending on speed of incoming values, a few numbers under and above
last stored value must be used to open the gate and let midi values pass.
Let's say last value was 77, then only when incoming values reach between
75 and 79 gate opens, otherwise it remains closed.
As soon as Parameter looses focus, gate should close again.
I would use split object for that
hehe, i was just about to make an example which also uses 77 as default value for the == object. :) then max7 chrashed.
it need s alot of parts, there are 3 conditions which decide when the data should be passed and when not.
plus, like source audio suggested, you should use a range for matching, because you might not have exactly 77 as input when you scroll fast.
So simple. I didn’t even think of split. Huge thanks guys
I was a bit short of time yesterday, so my answer was also short.
As first, Midi matching is an option, but for me much better way
is using up/down mechanism, because one does not have to look where
that value was left when last time used.
That is a stress in Live situation, and if You need a fast change
You can't really pinch that small range with a dial precisely,
so there will allways be a jump in the values.
A perfect solution for me was dial like pitch bend wheel which auto returns
to middle position.
So 64 = Stop, above 65 - 126 = increase Value and adjust speed depending on
wheel value, 127 = jump to max value immediatelly.
Oposite on the lower side = 63 - 1 = scroll down with scaled speed,
0 = hit Value minimum.
--
Another advantage is that receiving parameters can have any range,
and one does not have to keep an eye on the current value, where the pot is etc...
--------
Even a normal pot could do with a bit of range in the middle reserved for stop.
If You are interested, I could post a patch doing so.
----------
@ Roman - that misterious coincidences ...
I had crashes all day long yesterday, while testing the buffet external,
I hope that today it gets more smooth for both of us.
@Source - nice technique using rotaries as inc/dec rather than absolute value - I think I've used this method in a project once before! I like it as it allows float values and therefore much greater resolution on the MIDI CCs than the standard 0-127. I'll definitely be implementing this some time soon.
Here is my solution using [split] with a tolerance of +/-10 which still causes a slight jump when the value is in range, but this was a trade off with response time and quickly jumping out of range.