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.
‘Default’ CC Mappings for Moog Model D?
Hey all,
I’ve used Moog Model D with a controller quite a lot as an AU in AUM or as stand alone, using the provided MIDI mapping functionality for those. I’m trying to incorporate it into a BM3 workflow at the moment. Issue is that I want to use it with a MIDI controller (macros won’t cut it — I want to map every dial. This also applies for controlling Model D when hosted in AB3 as AU).
I tried hosting it as an AU in an IAA instance of AUM or as a stand-alone IAA instance. Works great however the IAA port crashes on session load either way, so I’m not going to pursue that any further.
Then.. as I was puzzling over it, I moved a fader idly, and a control moved inside Model D! I hadn’t mapped anything! I didn’t explore more deeply at that time but it made me wonder if there are default CCs mapped that it listens for (like Bram Bos apps do). I couldn’t find any reference from a quick search on built in control mappings, but that’d be the ideal solution (love how Bram Bos apps all listen for default MIDI CCs — allows easy controller mapping in any host!).
Anyone have any more info on this or have any more experience working with MIDI controllers and the AU of Model D?
@MoogMusicInc how about MIDI learn functionality in the AU!?? 
Cheers,
Oscar
Comments
I don't think there is default mapping aside from pitch & mod wheels.
Yeah we need that MIDI learn in AU if possible.
I haven´t mapped anything, but CC 74 and 71 seem to be mapped to filter cutoff and resonance/emphasis by default.
Perhaps in an AU setting, developers see it as natural to only expose AU parameters and let the host do the midi CC mapping to AU parameters, like how AUM does it. It kind of makes sense that every developer should not need to replicate this functionality. In that case, the feature request (bug?) should be directed at Intua and not Moog.
Does other apps that recently became AU (like Egoist) support midi learn in AU mode?
And CC 5 for glide. Model 15 has also 7 for volume and 64 for hold.
@OscarSouth have you tried searching if anyone already made a midi cc map for you controller? Model D has map import, but I haven’t tried it myself
It has map import in standalone, but not when used as an AU, as far as I can see. Again, I think Moog has decided that the AU host should do this job.
I agree, AB and BM3 need updates for proper AUv3 MIDI hosting and routing.
Model D is working great, every parameter is accessible to be controlled by the AUv3 host. I can MIDI learn every single parameter inside AUM and route the control from any MIDI source. It is beautiful
now all Moog needs to do is make Animoog into AU.
@bleep but if you map in the standlone doesn’t it remain mapped in the AU?
Can’t see a way to access the cc settings in the AU, but I only experimented with 74 and 71, which are set by default
Is there any chance it's the same as the actual hardware unit and you could find the manual/info for that and give it a try?
Yeah it was one of these that I moved by mistake. Interesting!
That would be very cool and perfect for me. I'll have to explore more there.
While this is built on sound logic, I disagree here. I don't see the difference in behaviour being a good thing because even if your chosen host is able to fill in the missing functionality, it's still going to break your workflow and demand an input of time to re-create the same experience as stand alone. Why can't you just import a MIDI mapping that you prepared earlier in stand alone? (this may be possible as @pedro suggests -- I haven't tested been with my equipment since opening this thread . In that case.. cool!)
Either way I see two logical 'low effort' options here, which could keep workflows consistent:
MIDI learn/mapping functionality from stand alone in AU:
This method transferred over great for Egoist and co. and makes for the most unbroken workflow from stand-alone. This is already implemented in stand alone so I can't see it being too hard to add to AU.
Default CC Mappings:
This seems to be already somewhat done? At least some of the controls have a default CC mapped (as mentioned above). Kind of strange that it'd be half implemented and not documented (if that is the case -- haven't tested completeness of it). Having a full mapping that's in line with the hardware (as mentioned by @vitocorleone123) and a table in the manual to document it clearly (as is the case with all Bram Bos apps, and damn useful too!!) would be a perfect solution that seems sooooo easy to include, considering it's already partially done, if not more so!
EDIT: seems like the stand-alone MIDI mapping carries over into the AU (tbc but lookes that way) .. cool!
Yes fucking please. Filtatron too.
@OscarSouth those mappings mentioned are some standard CCs from General Midi that match almost any synth.
I prefer a full default mapping by the maker instead of a teching the device > 60 knobs/dials, in particular if using automated data from sequencers.
Hardware teching may optionally 'overule' the default values.
If there are CCs defined, there's a (very) small chance that they used the same CCs as in this app for the UseAudio Minimax, which existed as a desktop module and as an exoansion board fir some keyboards.
„ASX Minimax“ von Benoit Bouchez
https://itunes.apple.com/de/app/asx-minimax/id1265279829?mt=8
Yeah, that’s how I noticed one by accident — I use those ‘standard’ mappings on my MIDI controllers as it’s easy to remember (and much available reference exists). So when I idly moved the fader for CC 74 (most likely), the AU recieved it and reacted.
I 100% agree that I prefer a full default mapping. This would also be my choice. MIDI learn is flexible but tedious.
Filtatron! Yes, something I agree on 100% !
And I see your other points as well, the more options the better. it seems it could get messy with default MIDI bindings once you have more than one instance of an AU, but the host should be able to sort that out also.
Filtatron is still awesome and sounds amazing! It would be fantastic as an AU! ( @MoogMusicInc please?). I'd love Animoog as well of course. It's expressive in some ways that no other synths can be.
As far as default bindings -- in my experience with Bram's deep implementations in this way, there aren't really any issues. You just make sure that the AU is only listening to the single channel that is sending the relevant messages.
Exactly this. I appreciate being able to "learn" MIDI controls in apps and/or hosts but there's definitely a use case for apps to ship with CC defaults (like hardware does) so you don't have to manually "relearn" in each host. Bonus if those defaults used standard (named) MIDI CCs by default (like 7 for volume, 74 for cutoff...).
Even with software alone, if you want to use Rozeta LFO or a Quantum CC lane to modulate some parameter, you first have to go through the learn or manually assign process. Seems a waste of time to me.
Yeah this is exactly what I meant. It's such a useful addition and seems so low effort for such an enhanced level of functionality. If a well documented 'default' midi mapping using standard CCs, with suitable page of documentation was provided for every app, it'd be much easier and quicker to work with MIDI overall and it'd add a lot of functionality across the board in hosts without MIDI-learn (which includes Audiobus).
I just ran through all CCs while moving a slider and watching the AU and the controls that moved were the same as my MIDI mapping in standalone (and only those controls) so I'm assuming then that as @pedro suggested, the stand alone MIDI mapping carries over into the AU. That's awesome and very well thought through functionality!
Or, even better: TB MIDI Stuff.
https://itunes.apple.com/de/app/tb-midi-stuff/id480953919?l=en&mt=8
It contains a Minimoog template too, but everything is completely customizable, you could even add your own buttons and knobs and MIDI functionality. Or create a number of custom, simplified UIs for Model 15. Or control surfaces for whatever apps controllable by MIDI CC.