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 StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Why is midi set up so choresome
I’m wondering why midi and cc setup seems to be much more of a hassle than it needs to be. While Octachron comes with a bunch of pre-configuref maps for different drum apps, this is extremely rare in my experience, with most apps requiring every end user to reinvent the wheel each time…
It seems it would be trivial to generate maps for any number of different conceivable application connections, and then make them available as downloads, if not presets.
Wouldn’t a midi-map-sharing forum thread, or a category on patchstorage for them, generate a lot of interest? Or does it already exist? I remain technically very sketchy with midi, so perhaps I’m missing the complexity of what I’m suggesting.
Comments
It is actually complicated to create such a thing because of the number of source apps and destination apps, each with their own schemes. Also, destination apps can be ambiguous. Most apps can have any sound on any pad. So not only does the note needed to trigger each pad vary from app to app, but you also don't know for sure if something like a hi hat is on pad 6, 8, 16 ... And how does one map output from a 16 pad app or a General Midi Drum Map file that can have up to at least 46 notes ... to a drum app with 8 pads?
Multiply the number of source apps by the number of destination apps and you could end up needing several dozen maps to even scratch the surface. Then there are the wild-cards - apps like Drum Computer where the notes output can vary even from patch to patch.
If someone did think this was worth pursuing, it would also require an app to be chosen to act as the middle-man. I use mfxConvert for this purpose, and save presets for the maps I need. The ideal app though would be able to import plain text files to lay out the mapping, imo. There isn't such an app that I know of.
btw, in my opinion an app that could be a really versatile mapper should use the GM drum map as the "neutral" mapping. Then you would set up how various apps map to the GM drum map. For instance, if pad 1 / note 49 is normally a bass drum, then it might map to GM notes 35 and 36, pad 2 / snare, to GM note 36, 37, 38, 39, and 40 (all of which are snare-like sounds in GM).
Once all that's defined one could just set the input and output apps and the mapping should work. Such an app doesn't exist.
Sounds like a nice Streambyter hack.
I doubt that would be very practical.
Thanks, interesting answer, but I'm still puzzled. E.g., I have drum computer, and I want to map it to, say, FAC Drum Kit. If I generated a patch or map for this, it seems I would have something that would be equally useful to a lot of other people. A couple hundred such files available on a server would only scratch the surface of possible app combinations, but still... a lot of surface would receive welcome scratching... but again I'm no midimeister.
But the fact you allude to that drum sequencers/drum kits still have no standardized mapping goes to the same point, that midi setup could be a lot less haphazard. Dunno
*Edit = E.g., the presets in Octochron for 10 or so drum apps are undeniably useful, even though they only cover a handful of existing drum apps. The same mappings for Drum Computer would also be useful, but I don't think I could easily find that patch, instead would have to reinvent a wheel.. OK, nuff sed by me
Go for it @GUB.
Who would you envision hosting a server such as this?
No one would claim that there not being a more conformance to a standard would be a bad thing. But that's the way it's been since MIDI was invented. The closest to a "standard" was the General Midi Drum map. It was adopted by many drum machines and apps, but far from all. And as more and more flexible drum apps came about, fewer and fewer of them have conformed. It's just the way it is.
Yah the midi standards on this platform are so loosey goosey. Typically it is why when I decide to midi up and integrate the ipad into a complex creative setup the moment it is running and working in that way is special and temporal because I am unlikely to return to it again in that form.
sounds like a suggestion for the mozaic request line
I thought about that long ago and even started to code it, but it soon became clear to me that it was impractical. There would be no modification without coding, no meaningful textual description of the mappings, massive if/else statements, and several other things I thought about but don't recall right now.
If Mozaic could read from text files, and if it had string variables, maybe. But I just don't see Mozaic as a good vehicle for this when you consider the number of mappings that would be needed.
Seems like having Midi Learn on the destination app for the pads or slots would be the easiest for all users.
Being able to trigger each source pad or lane in the sending app would also make a good standard.
Then you could easily setup everything without much menu diving or having to explicitly enter numbers by hand.
Yep. That would be ideal.
Though I bet you'd still get people unhappy that they have to go to the bother of midi learning things.
It would go a long way to reducing the pain of app to app communications. It wouldn't do a great deal of good for GM drum midi files though. For that you'd need many-to-one midi learn.
@wim I’d envision it being hosted by patch storage.com, or a site that hosts SYSEX files, or… I don’t know. Whoever wants to do it as sort of a public service with little hope of financial gain.
If your question is a rhetorical one, and implies that no one would want to host such a thing, then why is that the case?
it sounds like a doable thing, it doesn’t sound much different from similar things that are done on the Internet like sites that host, SYSEX files, and it sounds useful, although not a complete solution by any means. As far as feasibility, it’s feasible now, as opposed to any app or streambyter script that might do the same thing.
I thought about patchstorage.com, but that's geared toward specific application patches whereas this is generic. The site developer is very accommodating though. You may want to contact him.
No, it wasn't rhetorical or implying anything. It was a genuine question. I only ask questions to draw out details or clarify issues with the intent of narrowing in on a solution if there is one.
Yes, it would be doable if anyone with the motivation and means becomes interested in the idea.
BTW, you could also start a thread here for such patch files. The forum only accepts certain file types, so the best approach would be to ask people to zip the files, and of course provide installation and usage details with their posts.
Ya I think this is a great idea. Making maps available via zoo is a fantastic idea.