Feature Request: Midi Mapping

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.

I HAVE suggested a solution which is better: OSC integration.

You did not read my suggestion:

@Troy I tried to develop a solution for the layers volume fade in/out. You can find it here: Fade in/out mimoLive layers volume using Keyboard Maestro. If you have time to test it, I would be happy to have your feedback.

For a lot of control translation, I use Cycling74 Max. It natively uses Midi, OSC, UDP, TCP, etc. It is possible to create a translation from anything to anything, including mimo’s web api.

But, due to mimo’s API it takes hours to set up, and is not maintainable in any practical way. The proprietary web API is extremely awkward to work with.

@Gabriele_LS I’ve no doubt that the Keyboard Maestro solution can work for this as well – in the past I used KM for similar things. But I haven’t used KM in some years and don’t have a current license for testing.

Finally, OF COURSE enterprising users like @JoPhi have come up with ways to make things work for their own purposes. We, who do this kind of stuff, always do. But that doesn’t mean we can’t ask for a better way.

My suggestion was a what-you-see-is-what-you-get-editor for a surface, which you can integrate by just using one url. The surface does already exist: WebControl. It just can’t talk osc/midi currently. :slight_smile:

And please believe me: There wouldn’t be a more convenient way in configuring, when WebControl could communicate (without Webcontrol) through OSC/MIDI, providing all necessary background-communications. Besides: wheels are just curved sliders.

Next to the Audio-wheel, there are some more wheels/sliders/switches (simply in Standard-Placer, the sholution has also to be compatible with the Layer API.). Even this could someone want to have in control…(My suggestion includes even this. Even Layer Variants…)

If we can setup it with WebControl, we should be able to have it on OSC/MIDI. It’s as simple as rebuilding the own hardware-device as a WebControl surface. Not more not less.

If you don’t currently use OSC (or midi) in your control solutions, this thread probably doesn’t matter to you.

If you DO use OSC, or midi devices in your workflow, and have an investment in it as many people do, all the rest of this is basically a distraction.

The proprietary web API is a poor replacement for what is industry-standard control communication techniques. No amount of alternate solutions are going to change the desire to do it the way which is directly compatible with our tools and workflows.

I’m talking about a way how you could get this. You say, that you want it. So, where is the point? :slight_smile: Maybe I’m not able to talk in an understandable way. #kismet.

Your OSC-Device needs an Endpoint, which tells it, what should be placed where to switch. In mimoLive, there are two standards: Layer API and Web API. If you want to have something compatible to it, Layer API and Web API are the base for it. Believe me, there are things, which MIDI nor OSC do understand.

The minimum efford to have an integration, are users, who are ready to tell the OSC-app what should be controlled. mimoLive is too dynamic to have any conclusion about what should be switched.

What feature do you think is WebControl not able to switch/slide/wheel? All Audio Sliders/Wheels are available. As said: Currently it’s simply not able to talk in OSC or MIDI. Everything else is there.

I’m not looking to this group for an alternate solution to OSC. I understand that I can use mimo’s current HTTP API, and that I can translate from other tools to do that. Believe me, I do that kind of stuff all the time.

What I want, is midi or (better yet) OSC mapping capability. Just like the thread title. Note that I wasn’t asking a question, or looking for help. I was making a feature request for control solutions that conform to standards used by other, related, software and hardware.

Incidentally, mimoLive is NOT “too dynamic” to control with OSC. That’s absurd. I use OSC with plenty of tools equally as “dynamic” as mimo.

People who do not use midi, or OSC, and don’t want to, really shouldn’t care about this thread.

On the other hand, discussion of the automation features mimo does have and what can be done with them is very interesting, but is the topic of different threads.

I do not talk about an alternative solution. I suggested a solution, how boinx could integrate this. With the help of WebControl you’d built your hardware-device, which understands OSC. If WebControl could speak in OSC, you’d have what you want.

I did not say, that it is to dynamic to be controlled, I said it’s too dynamic that another software could automatically know, what you want to switch. So, you have to define it. The easiest way would be to use the already existing WebControl to “re-build” your hardware design for software.

For your convenience, I sent a detailed feature request to Boinx, suggesting a way to help your OSC to understand which part of all this dynamic you want to switch/toggle/wheel… Just in case, it comes.

S u m m a r y :
If I have an OSC-Device, I’d configure a WebControl-Sufrace (as a blueprint), which matches my Hardware-Surface. It would be cool to - then - have a hardware connection through OSC. I know, that I’d need one URL, which I can tell my OSC-companion to import and control mimoLive.

How Boinx implements it under the hood is not part of the original feature request.

Hopefully Boinx has read this thread, looked at some other similar software which does have OSC support, and considered the cost / benefits and their own engineering approach.

It would be a very good thing to be compatible with control standards. Midi, OSC… and DMX, would all be appropriate for mimo’s software category. Those are the big three. Anything else is proprietary.

An example:
This is about 5% of all layers, which contain audio inside of this document. It’s without showing sources. I could breake the audio control down to 11 switches. If you know a way, how OSC could automatically track this, I’d be realy interested in.

Yes, it would be handy to have hardware switches for it. And yes, I’d create a blue print in WebControl if this would help to get all of this on my hardware switcher. There are some, who just have 3 layers in their documents. And from this point of view it might be strange to rebuilt the hardware surface in WebControl to get access through other protocols. But it would be a way, and possible, if the resources are available for it.

OSC is bi-directional, so mimo would be reporting status of controls all the time. Usually, this is done in a continuous stream and parsed, but individual controls can also be polled for status.

Crafting smart control systems starts with a good (and standardized) communication protocol.

Yes, so I said: Currently, WebControl is not able to talk in OSC or MIDI (only in JSON). But JSON is already bi-directional. So all is prpared for everything else: Look:

https://drive.google.com/file/d/1BD6DL1bqVGJF48mg_94IL-TzNtiwlKoO/view?usp=sharing

and

https://drive.google.com/file/d/1_IbV2AYF4s614LwGSK_lLIVBS7pA_i1-/view?usp=sharing

Where you - then - pull the wheel doesn’t matter. Re-Creating the hardware design with webcontrol to have communication with OSC does have another advantage. When the hardware-switcher breaks, the show could be continued with the web-control-switcher. Nice to have a backup solution.

The same as mimoLive: JSON API. It’s a standard and bi-directional.

I’m repeating myself. So, I think all is said. Happy Day.

@JoPhi Does WebControl allow to do that? https://youtu.be/anaImmNwfgQ (the window with the two sliders is my iPhone screen).

Yes, it responds to changes in mimoLive. Why don’t you just try it out? :slight_smile: It’s bi-directional. So, as soon as it is possible to talk in other protocols, I do not see why it should be a problem to switch in different protocols the same time… Edit: X-Keys is already another protocol, which is supported.

@Gabriele_LS , my screen recording sucks currently, too many tasks, but look here: https://drive.google.com/file/d/1El1uAXMCvdnDWglFtWTyNtviiflQzbJ_/view?usp=sharing

Try mimoRemote from AppStore for iPhone. If you want to test/manage the surfaces, simply open http://localhost:8989/ on the mac where mimoLive is installed and running. Open any document to create a surface.

A quick ovierview to WebControl => Remote Control Surfaces

Edit: You can also have more actions per Switch. Like Macros:
Most of the time, this saves to use scripts or Automation.

I love mimoRemote. It is awesome. It also has nothing to do with this feature request.

The feature request here is for integrated midi-mapping and/or OSC-mapping.

I replied to a question. I already said: I wrote a matching feature request for you and sent it to Boinx. However. Control Surfaces (WebControl) will be your editor for your hardware-switcher, that might be the principle, similar to this: X-keys - mimoLive - 5 So you could get affine to it. :slight_smile:

To have the keys, the control surface is done with mimoLive for it. This principle won’t change. Independently from the protocol. It wouldn’t give any sense. Even not for MIDI or OSC.