So, you suggest a mapper for the mapper?
Well, what Boinx has done is basically to recreate OSC without all the benefits of simplicity, readability, and parameter handling.
If the API had readily adjustable parameters it would be workable, but the idea of copying a bunch of “endpoints” and then cycling through them to simulate a smooth ramp of values doesn’t exactly seem efficient. Doing this for each item you’d want to adjust is a pretty undesirable process.
We really didn’t need a new way to do this. We needed Mimo to adopt one of the ways of doing it that everything else uses. OSC being (arguably) the most useful.
Here is an example mimo endpoint that adjusts shadow distance to 3px:
In OSC, it would look like:
127.0.0.1:8000/layer/3/shadow_distance/3
Note how easy it would be to adjust those parameters to different values.without needing to return to mimo to capture an updated endpoint.
A mapper needs an endpoint. 
If you want to change more simultaneously, I’d recommend to bundle the changes with scripts.
httpRequest(...)
Instead of ... copy the Endpoint between the brackets.
Seperate each command by a new line.
Then you’re also able to change multiple values from different layers. Certainly, you’re also able to switch on/off whatever you want (through one MIDI-Signal). At the mapper call the Endpoint of the script, or the bundled scripts from a LayerSet.
This flexibility is only available through automation. (Even using X-Keys).
I think that Achim was refering on this, when posting that:
And with this you could also activate the changes onKeypress. (mapper to keyboard key).Amazing!
Is there a way to change the layer volume?
Sure. Do you want to map onKeypress? Simply give your Automation-variants different Keys, which you let press your mapper.
Here you are:
I mean, midi potentiometer control…
When you map it… Between 0% and 100% … If you’re able to find 100 key Combinations? Baybe 20 are enough? … I’d try to use Variants.
Just kidding.
Variants +
/cycleThroughVariantsBackwards and
/cycleThroughVariants
You’d need a first and a last variant, which prevents the wheel from cycling from 100 to 0 or from 0 to 100.
That could bring the solution.
C’mon, really?? Dozens and dozens and more dozens–maybe hundreds?– of layer variants? That is somehow an acceptable control solution? I’m thinking you’re joking with April Fool’s Day. That would be a nightmare.
Don’t get me wrong, I love mimo as much as anyone. But why create a unique approach to interoperability? That seems like an oxymoron to me. The point in interoperability is to be compatible.
This wheel really did not need to be reinvented, and mimo could have been much more compatible with other systems with probably less development work by integrating an existing standard.
As long as there is no calc() Option in Automation, you need a variant for each value which should be set. Who knows, maybe this will change soon. Besides: Currently, Automation is in the status “proof of concept”. You could place a Feature Request to the automation-section. As long there is no beep, why should something get better, especially for your use-case?
But: Your wheel would look like this:
The first STOP refers to 0% and the final STOP refers to 100%. These are preventing the wheel from cycling over the border.
“forward” (which is activated by control+a) is cycling forward and “backwards” is cycling backwards (control+s) . After this, both variants are switching to “pending”. The mapper is referencing to increase and decrease. So, you could map to control+a / control+s.
However, this is - for real - a tiny script. You could do more derivates of it to use other wheels too.
The thing is: Nobody else than you is able to tell mimoLive what it should do for you, when you circle your wheel.
Sure. Sure.
And why not create a Keyboard Maestro macro that clicks the mouse a whole bunch of times at a specific screen location?
Get crazy and combine both. Make all those variants and then a KM macro which clicks them all live in order with delays between. I’m sure it would be a fun, and creative experiment that would feel so good to get working after all the effort it took.
People could certainly do that that kind of stuff. It is quite awkward, primitive, and limited, but it can work as a technology hack. If anyone needs that functionality that desperately, I’d suggest they go for it. I would, if I were backed into a corner.
Personally, I’ll get by without it and lobby for OSC support. Which would make it clean, and reliable.
You call it hack. I don’t need MIDI to switch my show. With Automation I controll my Shows 95% automatically, with planned break-points.
It’s a way, and if you really need it now, I’d suggest to try it by the help of your mapper. If you have to wait for another solution, maybe you have to wait forever. That would be a pity. Get in touch with Automation. Automation is the way to make things happen that do not work in any other way. (And maybe won’t ever work in any other way.)
The variant-cycling thing is a hack if I ever saw one.
Hacks aren’t inherently “bad”. Hacks just aren’t generally “pretty”, or efficient. Nor are they maintainable in a practical way. As an example, what if you decided that the variant stack wasn’t granular enough and instead of 20 steps, you needed 30. Would you say the changes required represent a practical maintenance workflow?
Of course, sometime’s you have to do that kind of stuff. I’ve been hacking stuff professionally for 30 years. I’m pretty proud of some of the “hacks” I’ve done to accomplish some goal.
But other times, you want stuff to be well-designed, integrated, and compatible. I have at least 6 pieces of professional media software on my computer that can talk to each other easily by OSC. They all share a common language, even though they have no idea of each other’s purpose. They make Mimo’s API look very limited and extremely rigid.
Defend it further if you feel you must. I’m just saying it could be a lot better than it is.
// EOF
I do not Fight against your Feature Request. I regret that I tried to help.
Can you export and upload the volume layer, please?
I got 10 minutes. Hope you can test your mapping with it: How to create a wheel for external audio-control in mimoLive?
I second Troy’s feature request. Currently, it isn’t easy to properly handle audio levels. OSC implementation would make mimoLive usage much simpler and more efficient.
1 Like