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.

Excessive mapping via MidiFlow

Those with experience using MidiFlow, have you tried pushing the app to its limits in terms of complexity/number of routings?

Currently I am using MidiFlow to turn my Launch Control into an iOS MIDI MADNESS MACHINE! I am currently using 56 routings to operate AUM, Patterning, and iElectribe, but I plan on making even more in order to add to this mapping to control some of my synths with other templates on my controllers.

However, after this last build, I'm experiencing some problems sometimes with MidiFlow locking up which results in my controller not being able to send any messages. This is fixed with a restart of the app and unplugging/plugging in my controller again, but depending on other apps in use at the time (AUM, Patterning, Gadget), it can be quite frustrating to get the whole thing operational again.

I was wondering if anyone here has experience taking MidiFlow further than me and if this becomes a bigger issue down the road.

Check out my video for a glance at my mapping:

Thanks

Comments

  • The user and all related content has been deleted.
  • edited August 2018

    I went on a similar path making it crash in foreground when showing mifi events. Stopped using it since my needs were too heavy for it. I am too lazy to try to figure how to transfer presets between device so I don’t know yet how an ipad pro would do.

    The midiflow patch was for my nanokontrol 1 and microkey.
    With the nano top row buttons I could send midi from all slidders and pot to up to 8 channels of my choice simultaneously. With bottom row, I was transfering microkey control to up to 8 midi channels simultaneously.

    Then, I added a shift function to double that...
    My ipad 2 was struggling, but it was my dream setup.
    1 keyboard and 1 controller to control 8 IAA synth simultaneously.
    A blast!

  • The user and all related content has been deleted.
  • @tja said:
    Isn't that the domain of MIDI Designer Pro?

    Also, I just learned about MIDIfire with embedded StreamByter, which is fantastic

    Hey! Maybe you can help me with something as I've yet to dabble in Bome software. I'm really interested in MTP as I'm sure it will be capable of all the mapping I need and more. But to use the MIDI mappings you create, you have to have your controller actively plugged into the computer in which you're running MTP, correct?

    It's essential to me for live use that I only have my Launch Control and my iPad, so that's why I was attempting everything in MidiFlow. If indeed MTP only allows for MIDI mapping with the software actively running on a connected computer, how exactly can someone save sophisticated MIDI mappings onto their hardware for standalone use? There must be a way, right?

  • edited August 2018
    The user and all related content has been deleted.
  • Midiflow is a great app, but you may want to check out Midifire, which with streambyter is very powerful too. especially since I found it better for complex setups, the lanes system in Midiflow I found to be difficult when doing larger mappings. Midifire has a more modular approach and is probably easier to condense those mappings down into an easier to manage routing.

  • @tja said:
    This is outside of my knowledge, maybe some other can help

    Turns out that I would need to modify the firmware on the Launch Control and then develop some software to make changes to that firmware. Makes sense. Guess I was just hoping for a magical solution. :sweat_smile:

  • In my day, excessive mapping was frowned upon...

  • @cnsg_music Interesting :)
    Doing something a bit similar with AUM+StreamByter. With few rules in StreamByter, I also block all unwanted additional "bleeding everywhere" midi.
    And it's much more stable now...
    Keep in mind that the GUI of MidiFlow adds inevitably more CPU/Ram usage and/or side effects...

    Also something important, for the long run implementation, what's your sound card ? (and/or midi interface(s) that you're planning to use with your external gears ? )
    What's your iPad model ?

  • @crony said:
    @cnsg_music Interesting :)
    Doing something a bit similar with AUM+StreamByter. With few rules in StreamByter, I also block all unwanted additional "bleeding everywhere" midi.
    And it's much more stable now...
    Keep in mind that the GUI of MidiFlow adds inevitably more CPU/Ram usage and/or side effects...

    Also something important, for the long run implementation, what's your sound card ? (and/or midi interface(s) that you're planning to use with your external gears ? )
    What's your iPad model ?

    You know, my set up lately has been pretty stable... Maybe I am just opening up my apps in the correct order and getting lucky? Problem is I plan to continue this monstrosity with additional MIDI routings to also include remappings for some of my synths, and well I will have to wait and see how well it will be able to handle that.

    I'm curious about StreamByter -- what exactly is so great about it? I thought in general MIDI mapping works fairly straightfowardly regardless of what one uses to do it. Do you think StreamByter adds some level of implementation that cannot be achieved with MidiFlow? I haven't had a lot of problems with "bleeding" MIDI, but then again I painstakingly configured my routings to avoid such problems.

    MidiFlow hasn't seemed to add to much to my CPU usage as far as I can tell. I figured it's because MIDI in general is pretty light data transfer, but I'm sure the GUI as you mentioned does add some weight to my device's workflow. I'm currently on a 2018 Ipad (9.7") and I'm running my controllers straight into a USB hub and then into my iPad without an interface. No external gear -- maybe someday. :smiley:

    I probably sound like a geek, but damn I love this stuff. If you're curious, I'd be happy to share with you my template so you can see how cool it is. :sunglasses:

  • edited August 2018

    Hé hé...I know it's cool...
    You're telling us you've got some freeze at some point, and you want to add more...
    All I'm saying is StreamByter is lighter and AUv3...
    Don't get me wrong, MidiFlow is really great to set things quickly, very user friendly and also to learn, and works perfectly for a reasonable amount of midi rules, even a lot, but then, omho, StreamByter (with MidiFire I guess) is the next step while things get really wild and you want to be more "secure"...

    An other thing to consider, are the other apps you're using, they might also crash and does not involve MidiFlow at all...

  • I looked it up (sorry I'm only doing this now.) Looks cool! I like that you can do things MidiFlow cannot, like that slapback stuff. But the idea of having to learn StreamByter code is a little daunting considering how much I'd be having to write out in order to achieve what I currently have. And I'm not so sure I will be able to do everything I need to do. For example, MidiFlow is really great about "conditions" -- for instance, using a CC value on a separate controller as a "function" button to remap all the knobs on a different controller (effectively giving it a new template.) I can see perhaps it working in a smaller scale (if indeed one is able to route StreamByter from one channel in AUM into a StreamByter in a different channel and add conditions that way, if I'm understanding correctly), but by the time it got to what I'm currently doing, that would be a giant mess! :lol: I think MidiFlow works well in this regard as all controllers are operating on the same level and not routed into one another. Or maybe I have the wrong understanding. This stuff is very abstract and difficult to communicate... Thanks for sharing though! I may purchase it and mess around with it if I start encountering more problems going forward. Still hoping MidiFlow works out though! (It's been behaving much better :smile: )

Sign In or Register to comment.