Loopy Pro: Create music, your way.

What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

AB3 - what qualifies as a midi sender?

[Deleted User][Deleted User]
in General App Discussion
The user and all related content has been deleted.

Comments

  • SebastianSebastian

    @d4d0ug said:
    Loving AB3...

    One (maybe dumb, and potentially repeated) question though, what qualifies an app as a midi sender?

    I've got lots of apps that can send midi, but only the ones with AB3 specials appear in the midi sender list.

    Do we need to petition devs of all the other apps to implement a special way to register with AB3?

    Would love to see Patterning in that list...

    Yeah, developers need to update their apps with the AB 3 midi capability necessary for this. We're going to go live with the new SDK shortly so more developer can get their hands on it. Some already have access to the beta SDK, too.

  • [Deleted User][Deleted User]
    The user and all related content has been deleted.
  • aplourdeaplourde

    @Sebastian
    One question: Is it (or would it) be possible to expose AB3 MIDI inputs through Core MIDI? Obviously we want devs to update to AB3, but there could be older apps that won't get that update. Allowing a manual connection would allow these apps to work with the new filters in a state-saved AB3 patch.

    If you could allow different channels to be routed to different lanes that would allow multiple apps access to the new AB3 MIDI world....

  • AudiojunkieAudiojunkie

    Yes!! This is the absolute best feature of AB3! I just need a solid sequencer in that slot, and I'll have everything! :-)

  • wimwim
    edited April 2017

    @aplourde said:
    @Sebastian
    One question: Is it (or would it) be possible to expose AB3 MIDI inputs through Core MIDI? Obviously we want devs to update to AB3, but there could be older apps that won't get that update. Allowing a manual connection would allow these apps to work with the new filters in a state-saved AB3 patch.

    If you could allow different channels to be routed to different lanes that would allow multiple apps access to the new AB3 MIDI world....

    To avoid bunging up the whole concept of AB3, which is to avoid all that core midi in-out routing crap, maybe a compromise would be special "receiver" and "sender" apps. The "receiver" app would go in the Midi Input slot and have core-midi connection ability to the outside world, then convert it to be AB internal compatible. A "sender" app could go in the output slot to pass selected internal midi routes on to the outside world.

    I think this would be an elegant solution that wouldn't tread too much on the AB3 concept. As separate "exception" apps, maybe they AB3 wouldn't itself wouldn't need to be messed with much code-wise. I would pay for apps like these two in an instant.

  • aplourdeaplourde

    That's a great idea. I would pay for those as well - even more if the dev added some simple MIDI processing / transformations.

  • wimwim
    edited April 2017

    I think the developer would have to be the Audiobus team as it doesn't seem like the kind of thing the SDK would support.

    I don't think adding processing in there at all would be a good idea. That is what the new midi FX class of apps are for.

    It should just be like an adapter that allows outside midi data in, and another to let it out. It would work exactly like midi hardware in/out works now, except for apps rather than hardware.

  • SebastianSebastian
    edited April 2017

    @wim said:

    @aplourde said:
    @Sebastian
    One question: Is it (or would it) be possible to expose AB3 MIDI inputs through Core MIDI? Obviously we want devs to update to AB3, but there could be older apps that won't get that update. Allowing a manual connection would allow these apps to work with the new filters in a state-saved AB3 patch.

    If you could allow different channels to be routed to different lanes that would allow multiple apps access to the new AB3 MIDI world....

    To avoid bunging up the whole concept of AB3, which is to avoid all that core midi in-out routing crap, maybe a compromise would be special "receiver" and "sender" apps. The "receiver" app would go in the Midi Input slot and have core-midi connection ability to the outside world, then convert it to be AB internal compatible. A "sender" app could go in the output slot to pass selected internal midi routes on to the outside world.

    I think this would be an elegant solution that wouldn't tread too much on the AB3 concept. As separate "exception" apps, maybe they AB3 wouldn't itself wouldn't need to be messed with much code-wise. I would pay for apps like these two in an instant.

    Interesting. Definitely something to discuss with Johannes and the team.

  • iamspooniamspoon

    This sounds like a good idea potentially to me too.
    Maybe just expose these AB3 virtual ports to be used by older/non AB3 compatible MIDI apps?

  • JohannesDJohannesD

    I've been thinking about this for some time now. There could be an adapter app that offers virtual MIDI ports (Core MIDI) that can be used as input/output in the MIDI settings of a "legacy" app. More precisely, the user would have to configure the "legacy" app to send/receive exclusively to/on that port. Only that way, the adapter app would be able to handle the communication properly, without double notes etc.

    If the "legacy" app cannot be configured that way, there is no luck I think.

  • wimwim
    edited April 2017

    What if there was only an input adapter, not output, and if that adapter could only listen on its virtual port? Once the midi hits the adapter, AB owns it. It would only route to apps in a midi output slot, not to apps that were loaded just in an audio input slot, and those apps are already precluded from receiving from anywhere else, so I don't think there would be a danger of messed up routings there. A tiny handful of apps that can only output to their own virtual port would be incompatible with such an adapter, but only a few. For those people would just have to load the receiving apps only on the audio side and receive like they do now.

    Something tells me that if you had an output adaptor, you could make it smart enough not to be able to route back to the same app that originated the traffic to avoid loops. But if not, I'm not even all that convinced an output adapter is needed.

  • AudiojunkieAudiojunkie

    I like how this guy is thinking!! ^^

    I definitely DON'T want to gum up the beauty and ease of AB3!! That said, a "Legacy" adapter for those developers (NOTE: Not all developers) that surely won't do it themselves, would be useful. My only concern is that I don't want the other developers to get lazy (which also will surely happen (AGAIN NOTE: I'm not including all developers here), and have them just point us to the legacy adapter for our AB Midi support needs. That would be my primary fear of a useful tool such as this.

  • wimwim

    @Audiojunkie said:
    I like how this guy is thinking!! ^^

    I definitely DON'T want to gum up the beauty and ease of AB3!! That said, a "Legacy" adapter for those developers (NOTE: Not all developers) that surely won't do it themselves, would be useful. My only concern is that I don't want the other developers to get lazy (which also will surely happen (AGAIN NOTE: I'm not including all developers here), and have them just point us to the legacy adapter for our AB Midi support needs. That would be my primary fear of a useful tool such as this.

    Agreed, that could be the downside.

  • NoonienSNoonienS

    A risk for sure, but keep in mind that some (still very useful) apps are more or less "abandoned" (or dev spends as little effort as possible to keep it "alive"), I guess because dev has moved on can't spend the time needed. For such apps, such an adapter might be the only realistic choice..bad workflow but better than nothing..

  • CarnbotCarnbot

    I think some kind of app which lets you use core midi as a sender in Audiobus 3 is a good idea. This would be great for advanced users who miss this functionality and then can use any midi app with Audiobus 3 but any novice midi users wouldn't have to install or use it. The more ways you can use Audiobus in your workflow the better. I don't think It's a risk, more a risk to not do it.

  • TrueyorkyTrueyorky

    @JohannesD said:
    I've been thinking about this for some time now. There could be an adapter app that offers virtual MIDI ports (Core MIDI) that can be used as input/output in the MIDI settings of a "legacy" app. More precisely, the user would have to configure the "legacy" app to send/receive exclusively to/on that port. Only that way, the adapter app would be able to handle the communication properly, without double notes etc.

    If the "legacy" app cannot be configured that way, there is no luck I think.

    Doesn't this app exist already? It's called MidiBridge.

  • NoonienSNoonienS

    Midibridge is not AB3 compatible, i.e can not be input or output in AB3..at least it doesn't show up for me.

  • ModerndaycompilerModerndaycompiler

    @Sebastian said:

    @wim said:

    @aplourde said:
    @Sebastian
    One question: Is it (or would it) be possible to expose AB3 MIDI inputs through Core MIDI? Obviously we want devs to update to AB3, but there could be older apps that won't get that update. Allowing a manual connection would allow these apps to work with the new filters in a state-saved AB3 patch.

    If you could allow different channels to be routed to different lanes that would allow multiple apps access to the new AB3 MIDI world....

    To avoid bunging up the whole concept of AB3, which is to avoid all that core midi in-out routing crap, maybe a compromise would be special "receiver" and "sender" apps. The "receiver" app would go in the Midi Input slot and have core-midi connection ability to the outside world, then convert it to be AB internal compatible. A "sender" app could go in the output slot to pass selected internal midi routes on to the outside world.

    I think this would be an elegant solution that wouldn't tread too much on the AB3 concept. As separate "exception" apps, maybe they AB3 wouldn't itself wouldn't need to be messed with much code-wise. I would pay for apps like these two in an instant.

    Interesting. Definitely something to discuss with Johannes and the team.

    I would pay for this yesterday :smile:
    Any idea if @BitShapeSoft has reached out to add AB3 support to TC-Data?
    I really use that heavily and would love to see it integrated into the midi side of AB3...

  • AudiojunkieAudiojunkie

    Any idea if @BitShapeSoft has reached out to add AB3 support to TC-Data?
    I really use that heavily and would love to see it integrated into the midi side of AB3...

    That would be REALLY, REALLY awesome!!!

  • ecamburnecamburn
    edited January 2021

    Necro bump.

    I've been using Audiobus more lately and noticed there's a lot of MIDI apps that don't appear as senders - Riffer, Rozetta, Chordpolypad, Octachron, Atom, to name a few.

    I feel like I've missed some basic feature of the ios ecosystem. Why don't all AUV Midi apps that send midi show up as Midi senders in Audiobus? Given this thread, it seems like it's on devs to put in Audiobus functionality. Is that right?

  • wimwim

    @ecamburn said:
    Necro bump.

    I've been using Audiobus more lately and noticed there's a lot of MIDI apps that don't appear as senders - Riffer, Rozetta, Chordpolypad, Octachron, Atom, to name a few.

    I feel like I've missed some basic feature of the ios ecosystem. Why don't all AUV Midi apps that send midi show up as Midi senders in Audiobus? Given this thread, it seems like it's on devs to put in Audiobus functionality. Is that right?

    Are you sure you’re looking under Audio Units?? All those apps show up as midi senders. Any Midi AU will show up without any action needed by the developer.

    Something not right there. Try a reboot.

  • ecamburnecamburn

    That was it @wim. I’d missed those filter buttons for Apps, Audio Units, etc. Thanks.

Sign In or Register to comment.

© Vanilla Keystone Theme 2025