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.
A pity, OSC isn’t backwards compatible to MIDI
Just to get the right term: Is this Feature Request about MIDI or OSC, @Troy?
When originally drafted, I requested midi. It would allow rapid mapping of physical dials to virtual ones. Over time the request has moved toward OSC. In general, musical DEVICES use midi, and SOFTWARE uses OSC. Many midi users have the ability to convert from midi to OSC already, as it is a common part of the workflow.
OSC is much closer to an appropriate type of API for a software like mimo, where parameters are passed as standard values. It would open up a huge range of control possibilities. Midi is perhaps less so, with notes and intensity as it’s communication language. Really, using midi to control mimo, would be a bit of a “hack” that way as well. (e.g. sending a C# to start a layer, for instance.)
But really, either midi, or OSC would probably make a lot of people happy.
I see.
The current API of mimoLive is processing JSON. A featured Web Controll (including sliders) is available. This discussion reminds me to the discussion about a streamdeck integration (real keyes). An open source plugin project was started, so a plugin is available, which works as a wrapper/mapper between mimoLive and the stream deck companion app: Releases · boinx/mimoLive-Stream-Deck-Plugin · GitHub - It’s a pity that it will never have the full functionality, WebControl has/the API offers. The realy interesting features will never be possible. But some. And the majority of users, need simply keys to press to activate or deactivate something.
Back to the topic:
Who knows, maybe there is a OSC2JSON bridge available, which is able to translate JSON to OSC and vice versa.
OSC output of the existing API is currently - in my opinion - more or less unrealistic, especially while Apples transition to ARM. It could require to code the full API again, so that it would be able to talk another “language” too.
On Android e.g., there is GitHub - Waboodoo/HTTP-Shortcuts: Android app to create home screen shortcuts that trigger arbitrary HTTP requests available. You’re able to create Buttons, sliders and even JavaScript programs to automate mimoLive. But: WebControl is opened quicker and mimoScript inside of Automation Layers is shorter to write. And features will be extended.
By the way: mimoLive’s API is a propper and standard conform json API which controls not only, but also audio. Audio is still a “sidecar” in mimoLive. But I’m sure, that some day mimoLive will also replace completely hardware mixers for audio. Within the last 2 years, amazing mix-minus features were introduced, multi channel spreading also. All Step by step. I’d never be able to do my current audio-setups/-mixes on real hardware mixers. 
honestly!
Who knows, maybe some day it will also be possible to controll sliders/wheels by a simple request to the AP,I similar to /cycleThroughVariants. Currently we have to build a wheel in Automation, wich is able to write the values to the layer, to aim this behaviour.
Anyway, it’s pretty simple to bridge OSC and MIDI. And it’s also possible to bridge OSC and the current mimoLive API. The only issue of the latter is that it is a long, complex process.
@Gabriele_LS thank you very much for showing this workaround.
If you’d set two points, related on the document How to create a wheel for external audio-control in mimoLive?
Would the wheel by using your mapping work as a kind of workaround? I’m sure that Automation will bring more easier ways of aiming a wheel in future. But currently.
It’s a pity, I do not have any MIDI / OSC equipment to test it. Thank you very much for your feedback.
For the test, you could use the API-Endpoints for <API-of-layer-variant-forward>/setLive and <API-of-layer-variant-backwards>/setLive
OSC would be the preferred integration if the Boinx team have time to implement it. I believe it was previously available with Boinx TV which was the precursor to mimoLive.
@Oliver_Boinx and @Achim_Boinx have talked about it previously on other threads, it’s really just a matter of time.
OSC has been very topical lately as a result of products like ZoomOSC from Liminal. It would be great to have the integrated but I suspect the transition to Apple Silicon is a higher priority for the development team.
And finally the usecase by certain users. Some kind of mapping is always included. I saw demos at the web, where apps try to auto-configure wheels/sliders and buttons. In apps with fixed content positions, this seems to be possible. In mimoLive this would be meaningless - no: impossible, because of all this dynamic positioning - or as requested above (what if, a dropshandow should be increased or decreased in its amount).
Dynamic wheels, sliders, toggles, dependent on sources, layers or even layer-variants and the content of it… So, the only person which could be able to decide, which mapping should be valid for what slider/wheel/toggle etc. can only be the person which wants to use it: (This means work to configure, however the integration might be.)
But, who knows:
Maybe it will be possible some day to create a Control Surface with WebControl and who knows, maybe this could be the basement of an additional output of the idea what individually should be available for mapping. Some kind of blueprint. Without (software or hardware) feedback on the OSC-hardware or -software, all workarounds / mappings, are nice to play, but not realy handy. Some kind of WebControl2OSC or OSC2WebControl.
Sure, this would lead to new Endpoints at the API, for e.g.
<API>/increase/<affected-API-Data-Key>
<API>/decrease/<affected-API-Data-Key>
<API+document-id>/surfaces/$SURFACE_ID/<language>
// <API+document-id>/surfaces/$SURFACE_ID/osc
// <API+document-id>/surfaces/$SURFACE_ID/midi
I always missed suggestions to find a solution, which is working and useful. So this was my suggestion to solve/integrate it when it will ever come.
Within 2 days, I was not able to find only one person to test 2 endpoints with the wheel-demo-document and writing feedback on it. Why should anyone use WebControl to configure a surface and connect it later with the OSC-mapper/-app/-wrapper by using a URL like // http://localhost:8989/v1/api/documents/24520986/surfaces/SDFS-SDFSDF-SDFSF-SFSF-SFSDFSF/osc? When copy+paste of two endpoints is too much work, then the best solution is wasted time. - But this is only my opinion, which does not count.
@hutchinson.james_boi , I was not able to find OSC in BoinxTVs archived online-documentation.
@Achim_Boinx , would something like this be possible if there is time to integrate it?
@JoPhi Testing your wheel-demo-document requires installing a beta version of mimoLive. Not everybody wants to install new beta software in a production environment to make a test. Moreover, on my Mac, that beta quits unexpectedly just after loading the UI.
Anyway, you wrote a scary note: “Unfortunately, you have to rebuild this for your document(s) from scratch.” That makes clear that this solution would require half day to be implemented on complex documents with more than 10 different audio sources.
I’ve nothing against proving that mimoLive functionalities work in hypothetical scenarios. But I’m skeptical about calling “solution” a workaround that requires hours to be implemented.
Yes, this was about the demo. For testing it with my document, you just have to copy 2 urls. As said: as long as nobody is ready to copy 2 urls for testing, why sould boinx consider an implementation.
A pity, the current Automation layer does not support a better way of scripting. In future versions this could be different. What should I do? /cycleThroughVariantsBackwards isn’t available before this beta. 
I hope you reported your crash-report to boinx.
Sorry, I do not understand what you are talking about. 2 urls for doing what?
For those of us who use OSC routinely, controlling similar software to Mimo, the case for OSC is extremely clear. Suddenly, all of our other hardware and software would be instantly compatible.
The automation API is a proprietary solution which doesn’t integrate well with any other professional tools. A simple value ramp requires stacks of layer variants. Like I said, that’s a clever solution, but not one that I want to rely on for my projects.
For calling the left cycling of your wheel and the right cycling of your wheel.
Suggest a solution, which is better than my suggestion.
