@JoPhi You don’t know what MIDI/OSC are, and you are making meaningless statements about them. If you knew MIDI/OSC you would have known there is no need for any other endpoint to make them interact with mimoLive.
I don’t really understand why you are trying to cover a topic you are not familiar with.
OSC is communicating over headers, these are not created by air.
This is done using OSC: https://youtu.be/anaImmNwfgQ.
Of course, it required me to write a custom script to translate OSC commands into mimoLive readable commands.
And I’m discussing a way, where no one has to write scripts, so that mimoLive is able to reply properly without the need of aditional scripting.
It could - maybe - work like this:
The user is rebuilding the hardware switcher in Web Control Surfaces, with all actions/slides that should be done. (similar to the already existing x-key integration)
Afterwards, a URL is available to connect with the OSC companion/processing OSC device (a starting point).
Then, the hardware switcher is doing whatever is configured. (Edit: and in return, mimo is chatting, what settings are active/current valid.)
Additional advantage: if the hardware switcher fails, a backup in Control Surfaces is available, which could be opened in any webbrowser.
On my system right now…
Unity, Unreal engine, Max, Resolume, Millumin, Wirecast, VDMX, Vezer, Coge, Vuo, MadMapper, QLab, Traktor, Live, Lemur, DMXis, TouchOSC and more. All support some combination of midi, OSC, and DMX. They are all from different companies. Except for a couple of them, they are not music software. They are designed to intercommunicate with unknown collaborators. They all talk to each other easily. Most of them can not only receive, but also send commands to each other. So for instance if you use a hardware controller to mute an audio channel, you can easily indicate that channel as muted on the hardware, and in different software, or ALL the other software, for that matter.
But none of them have a proprietary web API because that would serve little purpose. The point is to be standardly compatible and to speak the same language as other, similar tools. That lets people build systems that are bigger than one piece of software.
The web API is cool, but it is not providing compatibility to… anything but itself, really. Trying to make it a bridge to standards-based communication is not a good idea, and will just result in a really difficult to maintain codebase–without even providing the benefits of rapid communication setup like we enjoy with tools which have these communications integrated. Users should not have to awkwardly design and maintain a web control solution just so that they can then integrate the controls they actually need. Debugging such communications would be a huge pain as well as there would be multiple socket connections and multiple data translations involved–for no good reason.
Using only a proprietary API makes mimoLive an island. It is forced to work alone, and has to try to provide its own approach to user-designed controls. If it supported standards, all of that development work would not be required as we really could implement our own control solutions and tie-in other tools easily.
In case Boinx is reviewing this thread:
Just to be clear, all the proposed “solutions” or remedies in this thread, while the intent is appreciated, are not desirable, and likely would not achieve the goal in an acceptable way. Ultimately, they are a distraction from the actual request. This is not a functionality that is lacking a “clever” solution that can be designed by someone who is not a Boinx engineer.
Standards-based control communication is a core functionality that would raise mimoLive to a more professional level.
If you do not want to discuss your feature request, please do not post it public. You could write by mail to Boinx. Other opinions are not some kind of distraction. I understood that you want to configure pathes and you do not like what-you-see-is-what-you-get solutions. You made clear, that you’re not interested in what’s happening under the hood. I wonder that you judge now about. Ok. 
And nobody was saying that it would be a bad idea to implement MIDI/OSC. You could edit the title of your request (before someone could come to the idea to complaint because of your off topic text.).
Hand on heart: I do not believe that Boinx will change the API to OSC. But I can imagine that with a (huge) bit of fiddeling or tweaking, it might be integrated somehow somewhen. With a bit of luck not only by configuring pathes (by hand), but also a WYSIWYG-solution, with an automatic backup solution, which can be switched - in case of a fail - alternatively by other solutions.
Hi @Troy, I’m reading your comments and I do acknowledge the point that a more direct support of OSC, MIDI and so on is desirable. It is on our road map but other thing currently have priority, so I’m grateful of all the workarounds suggested in the forum.
@Oliver_Boinx is there any chance to have mimoLive doing something (calling a macro, pinging an url, or whatever) when a change in some parameter happens? Any workaround works when the flow goes from an external something to mimoLive. But I did not find any effective way to collect information from mimoLive and send them to an external something (other than querying the API every n milliseconds, which requires a lot of CPU power).
Right now, this is possible in an Automation Layer with the command httpRequest. So, you could use an Automation Layer to trigger something in mimoLive and notify an external URL of the change.
Can you give me a specific use case I could use to formulate the feature request?
@Oliver_Boinx I’m trying to build an OSC <> mimoLive bridge. Everything works fine when I send the commands to mimoLive. But if I change something in mimoLive, I cannot get the change to be reflected in the software sending the OSC commands.
Example: I have a TouchOSC layout controlling the volume of some mimoLive layers (see https://youtu.be/anaImmNwfgQ). But if I change that volume interacting with the mimoLive interface, my TouchOSC layout does not receive anything. Currently, if I want my TouchOSC layout to be updated, I need to query the mimoLive API every 10 ms, detect what values are changed, send the updates to TouchOSC. That’s pretty inconvenient because it consumes a lot of CPU. Do you see any way mimoLive to send out some signal when some parameter is changed?
Apparently, that’s already working with the web control interface. The user can change a layer volume both in the browser and in the mimoLive interface, and they are synced.
Thanks.
I’d suggest to write a wrapper for “Web Control Surfaces”, by catching the html and JavaScript/JSON-Objects, if you want to do it dynamically and if you want to avoid more requests than necessary. All Feedback is available there. But this would be a - dynamic - WYSIWYG-solution, nobody wanted, except of me.
Just to prove the immense value of having MIDI/OSC integration. Today RØDE released a new beta version of its RØDECaster Pro firmware. Guess what is the main new feature included in that firmware?
See for yourself: https://www.youtube.com/watch?v=M1vgPayQiTg
Amazing, and I’d like to press, slide and wheel me through a bunch of Layer Settings (of several Layers the same Time) by using one slider / and if the control supports also wheels, with spinning images and extra fancy transitions, which are just possible by using mimoLive. But I think we have to wait for under-the-hood-magic, which supports 360°-wheels and sliding processes on the first hand and on the other hand block-processing.
Hi @Gabriele_LS This is awesome! It would be great if you get it to work.
To be honest, I don’t know the technical details, but I think if the magical word is websockets to get the updates to the states. If you know your way around JavaScript, you can look at the Stream Deck plugin to see how this is done. The Stream Deck plugin also updates the state of the button according to the state of the layer.
Just to prove the immense value of having MIDI/OSC integration.
You don’t have to prove that.
I will investigate that. But I guess websockets are out of my league.
You should write every single line of code from scratch. So, if you are not familiar with programming, I would answer “no”. Otherwise, I would say it can be done, but it requires a day of code writing and testing.
ok… Well, thank you… 
Any update about this? I really miss MIDI mapping feature.