Feature Request: Midi Mapping

[Troy]

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.

[JoPhi]

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.

[Troy]

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.

[JoPhi]

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.

[Troy]

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.

[JoPhi]

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.

[Gabriele_LS]

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

[JoPhi]

Yes, it responds to changes in mimoLive. Why don’t you just try it out? 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

Remote Control Surfaces - mimoLive - 5

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

[Troy]

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.

[JoPhi]

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.

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.

[Troy]

Thanks. I’d just like this very long thread to not end on a distracted tangent.

X-Keys, web control, etc. are not related to this request and do nothing to change it.

The immutable request here is for midi and/or OSC mapping.

[Gabriele_LS]

Sorry @JoPhi, are you sure the WebControl allows to have real-time bidirectional sliders? Other than this, is that WebControl able to interact with other software?

[Gabriele_LS]

@Troy this thread is two years old, I guess the Boinx team had enough time to evaluate this request. Maybe further discussing that matter would help them understanding the reasons of the request. People not using OSC/MIDI could have some difficulties in understanding why that’s so important. And I don’t think it would help to reaffirm a number of times the subject of the request.

[JoPhi]

You use it already, every time when you call /v1/api…/Endpoint. The same is WebControl doing. If you want it like this, the surface is the GUI for the mimoLive HTTP-API. “Remote Control Surfaces” is a on-top using JavaScript + json. Achim told us that it’s based on node.js - In sum I call it WebControl.

So, it’s widely open for to be used by/with third party apps. Over the past years, lots of genius features were added to the API. So, Control Surfaces were growing too.

The API itself talks json, Find more information about it at the http-api documentation.

[Gabriele_LS]

Sorry @JoPhi, I do not understand what you are saying. Could you please answer my questions with a “yes” or a “no”? Simple questions require simple answers.

Does what you call WebControl allow to have sliders like the ones showed in the video I shared above?

Does what you call WebControl allow the user to control software and hardware other than mimoLive?

[JoPhi]

(v5.10.1b3) yes, yes / no, no / depends on

Hmmm… Software:
Control Surfaces is there to control mimoLive, and not a generic switcher to switch whatever you need. At least currently not.

You cannot control Super Marios movements in an Emulator on Solaris (except it accepts httpRequests). But you can use commands like httpRequest() to ping other software too, which is able to receive a httpRequest():

Automation-Layer (the bridge between mimoLive and all which should be automated) aims currently just Toggles inside of mimoLive and curently no “sliders” (That’s why I did a demo, to aim a wheel/slider, to make it’s importance visible). With the current version of Automation Layer (v1.32) it’s not possible to read and process the result that httpRequest() receives, so you’re not able to let your Automation Layer react on a particular result.

It’s a step by step development, so when there are no particular feature requests this may never change.

About the sliders:
The sliders in my demo video are calculated by JavaScript which is processed in a web browser. (I thought that it is clear, that mimoLive’s API does hot have API-Endpoints to aim a wheel/slider.) This Script is currently fireing - onChange - the new status to mimoLive, and onChange it receives an update of the current status. This is how the “GUI for the API” - currently - works. In lack of Endpoints with a specialized logic.

On a multi touch device, you’re able to use up to 10 fingers to slide sliders. Maybe I do not get the point. Did you use programmable sliders, which do automatic cross fades, or something like this? As long as there are no real End-Points to aim sliders/wheels (which is definately not present, at least not now), you’re not able to profit by this logic.

So, even with external software, you can just trigger the result out of a responding json-object, but you have to write your own function to handle switches / sliders… So your showen sliders are also not able to do it out of the box. And again, if you miss a feature, it would be good to write a request.

So, what Requests could be now interesting to enhance all of this to your needs?

• udpRequest()?
• oscRequest()?
• midiRequest()?
• Particular Endpoints which are able to do a particular logic?

My personal speculation about this:
Some features are introduced in a quick way as a proof of concept (like this current sliders at the Control Surfaces). A piece of JavaScript is easy/simple to add. It’s also simple to remove/change/update, if necessary. An API-Endpoint on the other hand, needs more plan/development, also some kind of documentation, so all circumstances should be exactly clear, before adding this logic to the API forever.

Finally, I’m not able to give a clear yes or no, because currently all is “depends on”. I’m simply able to recommend to know all current possibilities around the API, and to send on point Feature Requests.

[Gabriele_LS]

What I get is:

Does what you call WebControl allow to have sliders like the ones shown in the video I shared above?

YES (almost)

Does what you call WebControl allow the user to control software and hardware other than mimoLive?

NO

The answer to the second question is the reason an OSC integration is needed. There is nothing else to add.

[JoPhi]

I agree to this. Almost. … Btw, your ‘no’ is not correct. e.g. You’re able to change ATEM-switcher channels. … It depends on, what you want to do. My post does not fight against a feature request.

It would be helpful to understand what exactly should be added. OSC is a way to communicate. This alone does not bring the solution. First, I think, there is to add some more logic to fully cover the basic functionality, especially for sliders. Otherwise mimoLive would not know what to say in or how to react on content in json/OSC/MIDI… whatever.

[Gabriele_LS]

@JoPhi why don’t you ask ProPresenter or vMix developers why they included MIDI in their software?

It’s pretty clear that you’ve never used MIDI or OSC. So it makes no sense for you to carrying on such a discussion. If you don’t know the car exists (or you don’t have one) you will always find smart ways to take advantage of your horse. But you will never be able to convince people knowing the car exists (and having one) to use a horse.

MIDI/OSC integration would be a great step ahead for mimoLive, period.

[JoPhi]

Currently, it does not make sense to include it, because it even cannot switch wheels/sliders natively by API. (Two endponts are missing. An increasing and a decreasing one.). Independently in which language it would now talk or listen to. You could press buttons right now. So, even it could already talk in OSC or listen on OSC, it would lack in sliding (and this because of the two missing endpoints). That’s all. The first step should be completing the logic. And as I watched, Boinx is working hard to provide as many features as possible. But all starts with a proof of concept. Compare: current sliders integration at the native Web Control Surfaces.)