Feature Request: Midi Mapping

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

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. :joy::joy::joy: 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. :wink:

I hope you reported your crash-report to boinx.

Sorry, I do not understand what you are talking about. 2 urls for doing what?

1 Like

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.