RFC: MIDI Support #111
Comments
|
Thats something that I find intriguing. I regularly use both OSC and Midi, and in some cases wind up having to bridge one to the other. My perspective is always that its better to have more comm protocol options than less. One other fear I have right now is the current dearth of simple midi patchbay apps for MacOS. Midi Patchbay development ceased years ago, and is 32 bit, so will stop working in the next OS update. Midi Pipe is great, but development has also dropped off. The developer is supposedly updating it for future MacOS versions, but there is very little communication there, and its just one dude I believe, and closed source. I guess what I'd really love is a FOSS Midi and OSC routing app. Even if it didnt do any complex transforms like MidiPipe and OSCulator. |
|
Like @carbon43 mentioned, I think it would be more valuable to create a standalone app that is good at converting MIDI to OSC but has a lower learning curve than OSCulator. While integrating MIDI sounds like a good idea at first, I think it would slow down development (every time I make a change I would then have to program for and test the midi), as well as make the app unnecessarily complex for people who don’t want MIDI. That being said, I am also a huge fan of apps as having one dedicated purpose, one thing it is very good at doing, so I’m already a bit biased by that philosophy. Just my thoughts :) |
|
I’m all for this idea. I currently run a live production switcher and to use my midi controllers I have to run AtemOSC and OSCulator and then I also have a Steam Deck Controller that has its own software and an app called Companion to adapt it to the switcher also. So 4 pieces of software to convert over 2 hardware devices to OSC commands to the switcher. Whew. |
|
Would 100% use on a weekly basis |
|
That would be totally awesome and save us all so much pain with OSCulator configuration. |
|
Yes, please! I want to use midi controller to control ATEM mini! |
|
Yes please :) |
|
It would be great to have the midi support! |
|
Definetely! |
|
Most definitely. I use a Korg nanoKontrol2 and being able to map this to audio mix, etc. would be extremely useful! |
|
While it is appealing to only have to run one background app instead of two, I fear this might change atemOSC from the simple clean app that it currently is into something rather cluttered. Also there are some relatively complex operation I do with OSCulator which I would need to be able to replicate in atemOSC in order to make OSCulator redundant. For example, I have the master fader on my X-Touch Mini acting as a transition bar for the ATEM Mini, I need two instances of the mapping, with opposite directions, which have to toggle enabling of each time I press the auto-take button. That said, if atemOSC could implement a more powerful approach to this, with status-aware mathematical operations being applied to mappings (allowing things like linear fader position being mapped to logarithmic gain) that would be fantastic. OSCulator appears to be EOL, so we won't get any new functionality there. |
|
@nick-shaw Could you please help be with this?
I'm trying to figure this out for almost 2 Weeks and are very frustrated... Sorry for answering in this thread, but I don't know how to contact you in any other way |
To be honest I got it working by trial and error. I use Midi substitution to send three OSC messages when I press the button I use for |
|
Thank you! |
How do you send three message with one button. What do you mean forward/reverse T-Bar? Do you mind making a video for this? Thanks. |
|
Yes please |
|
I would find direct MIDI support very useful so +1 on this issue, it would simplify most things for me. But I also agree that as long as MIDI is doable (AND STABLE) with Osculator or other tools, it is better to have a dedicated powerful, stable tool doing one thing well, that can be combined with other powerful tools doing THEIR thing well. |
|
It will be great and easier to setup where midi can be read directly and control the ATEM. Or the conversion part of Midi to OSC should be integrated into the software so that users can use only one software to do the entire setup. |
|
I would absolutely love the addition of this. I am just starting out the setup process, but it makes 100% sense to only need one application. I am available for testing and feedback and possible collaborations as well. |
|
@nick-shaw: I saw your message above with complex operations, and also others mentioning that it may clutter the interface unnecessarily to add MIDI to the atemOSC interface. However, wouldn't it be a good start to do relatively "simple" transforms and messages as a start to even get people up and running with atemOSC and then switch to OSCulator when you really need the in depth features mentioned? That would — in my humble opinion — be a good middle ground to start with. And a thought about the complexity of the app and testing: couldn't the interface in a way be relatively separated from what is already possible and by doing so keep the interface from being overly complex for people who do not need the MIDI parts? And while doing so it could "more or less" be two separate parts running in one app. Yes, I see the point that some could make that then it could also be two separate apps… but it would still stick with the "one use case" scenario and doing that well. Just my few thoughts 🙈 looking forward to getting to know atemOSC further. I'm already amazed about all the things that are already possible with this. |
Like I said, I did it by trial and error, and can't remember exactly what I did! Essentially I used OSCulator's MIDI substitution to create multiple new OSC messages sent to itself when the Auto button was pressed on the X-Touch, and then had different things being triggered by each of those. |
|
I would love it. I am trying to switch cameras for my live stream while I am playing to Logic pro sequencer tracks. Since logic can spit out MIDI commands to IAC Midi ports, I want to switch camera angles on the bridge, the intro, the chorus etc.... |
|
I would love to see support for direct MIDI input into atemOSC. I use a product called Bome MIDI Translator Pro to control workflow of multiple applications and hardware devices. If I could send MIDI it would be very easy to integrate atemOSC into the workflow. |
I was able to do what I needed using sendOSC to send an OSC message to atemOSC. Thanks! |
|
I would like to see support for direct MIDI input into atemOSC. It would be very helpful. |
|
I've been thinking that I'm probably never going to add MIDI support to atemOSC, but I may consider making a variant (maybe atemMIDI) that primarily targets MIDI instead of OSC as the input method if there's enough interest. Let me know how many of you would be interested in something like this! |
|
I think my strong personal preference would be that it be the same app, tbh. Also wow I originally commented on this in 2018, feels like a lifetime ago 😅 |
@XENONChromatic Gotcha, could you elaborate on exactly why that is your preference? |
Sure thing. So thats how other best in class apps like TouchOSC do it for one. And I consider AtemOSC in that category. That is to say, one app, that supports multiple interaction protocols. Thinking not just of OSC/Midi specfic apps, but NLEs, DAWs, etc. Like, imagine if Ableton had two entirely separate versions, one that supported Midi and one that supported OSC. As Ive grown older consistency in behavior across apps (even those by different developers) has become something I value more highly since it lowers the mental overhead of what app to use for what task. "I can just use this one app I know and like, and it'll work using whatever protocol is most convenient for me in the scenario/moment." etc Then another big thing is deployment/updates. I already have far more apps than Id like, to maintain, bug track, ensure theyre working with the OS version X or Y or Z computer is on, etc. as a user. I would prefer to have not yet another app added to that list. Lastly, if we're talking about the Unix philosophy of "do one thing. do it well." that one thing is atem control, imho. Not OSC. OSC is just the protocol currently being used, but it certainly would not be a violation of the unix philosophy to support both Midi and OSC. Also thank you again for this app, its really been a joy to use over the years, and I appreciate the care that goes into it. |
|
I believe it would give you a lot more flexibility if you do the MIDI mapping to OSC yourself. With software such as Osculator (Mac Only) or TouchOSC: https://osculator.net/ you have such a wealth of possibilities, that I think it would be constraining if the mapping were done in atemOSC. Every user will have their own mapping needs and requirements, whether it be sending notes, cc, program change, etc. Perhaps Peter it might be possible, if you haven't already, to provide documentation on MIDI to OSC conversion in the atemOSC documentation? |
Strongly disagree. I dont want to be stacking apps on apps on apps just to intermediate between protocols, if and when it can be helped, which is why Im asking for it to be in a single app. That adds both latency and greater stability concerns, not to mention the developer now needing to keep multiple apps updated, if they were to adopt Midi support in some capacity, but in a second version of the app. And there is nothing at all constraining about supporting multiple protocols, lets dispense with that claim. People are free to use or not use midi or OSC as they see fit. The developer adopting support for midi wouldnt somehow obviate the ability of someone to use TouchOSC or OSCulator if they so choose. Though personally as someone working in production environments on a daily basis I have learned and value minimizing the number of links in a signal chain. Generally speaking, we need less links in the app/device chain, not more. |
|
I strongly disagree with your strong disagreement. If you take that position, it's better not to be doing anything too experimental. Whenever things become neatly packaged then you end up with canned functionality. atemOSC has been created in the spirit of experimentation for DIY practitioners who want to break outside of the box. There is plenty of other software that is more packaged with abundant features that don't allow you the flexibility you need when you are working in the spirit of invention. |
Thats complete and utter nonsense. atemOSC is entirely stable and production ready. There's nothing "experimental" about it. Stop with the FUD, and stop with telling people how they should be using the software they use weekly. In the 5 years this RFC has been open youve never once participated before now. Go away. |
|
Thanks for following up on this @SteffeyDev - totally understand your position. I for one would love an atemMIDI app. Thank you for your great work. |
|
@XENONChromatic @chrisspiegl @cybrgloom @twumphlett @jtw-phbc and anyone else on this thread who’s interested. I’ve been thinking more about this feature and would like to learn more about your different use cases, please reach out to me at peter@steffey.dev if you would like to meet with me to discuss this, either over a video chat or just over email depending on time zones and your preference. |
|
@SteffeyDev Sure thing. I should have some time Tuesday or Wednesday to hop on a video chat if thats helpful. I'll email you in a little bit. |
and others
I am curious to hear your feedback on this idea. In many cases atemOSC is used together with Osculator to map MIDI signals to OSC messages.
Should we support MIDI messages out of the box? We could have a list of actions, which you can learn MIDI nodes for.
The text was updated successfully, but these errors were encountered: