atemOSC
atemOSC copied to clipboard
SteffeyDev
RFC: MIDI Support
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.
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.
That would be totally awesome and save us all so much pain with OSCulator configuration.
It would be great to have the midi support! I‘m using an c touch mini to control my Atem mini with a bar
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 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.
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
I'm trying to figure this out for almost 2 Weeks and are very frustrated...
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 Auto. One sends the OSC Auto Take message; one toggles enable on the forward version on the slider message; one toggles enable on the reversed version. I have to only use the X-Touch to control it, or it gets out of phase, and jumps when I move the slider.
Thank you! I still try to make it work with the feedback from the bar, but this idea is working for me, too!
I'm trying to figure this out for almost 2 Weeks and are very frustrated...
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
Auto. One sends the OSC Auto Take message; one toggles enable on the forward version on the slider message; one toggles enable on the reversed version. I have to only use the X-Touch to control it, or it gets out of phase, and jumps when I move the slider.
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.
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.
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.
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.... It is supposed to be possible using Osculator and Atem OSC, but I can't get atemOSC to see my Atem MINI Keep getting this "192.168.10.240: No response from Switcher, retrying 4 more times" 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 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 😅
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?
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?
