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.
General midi cc architecture question
Some LFOs show what appear to be standardized or suggested assignments for CC#s -- e.g., 2 - breath controller.
Is this just part of a half-realized stab at standardization across apps? The CC#s themselves are indistinguishable in terms of actual functionality for the most part, correct?
Comments
As I remember it (from some 25 years ago, when I was really into MIDI), a number of controllers (including continuous ones) had been officially standardized, with others being reserved for inside System Exclusive messages (which are vendor- or even model-specific, and get ignored by the rest). Besides, some not officially allocated ones may have become de-facto standards: the competing and conflicting additional standards GS (by Roland) and XG (by Yamaha).
You may find all answers at the source: the MIDI Association .
These mappings are a convention. Hardware manufacturers often adopted to standardize cc interpretations and some soft synths implement them as defaults. Their just suggested mappings.
OK, thx, that's what I figured.
I still find it interesting that there hasn't more of a coordinated effort across manufacturers to better standardize midi protocols. I gotta imagine the number of people who have not pursued using midi because of unnecessary complexity can't be trivial. Those were potential customers.
They can't even agree what number to assign to middle C, or what the lowest CC channel is? Maybe lack of cross-brand standards was a failed attempt to lock customers into a kind of forced brand loyalty? Just wild conspiracy theorizing, talking to myself, really
@GUB: middle C is standardized in midi. Note 60 is middle c in the midi spec.
You are thinking of octave numbering which is not in the midi spec and precedes midi. When midi came around, there were already competing conventions.
It isn’t that there was a lack of effort to standardize…a lot of manufacturers adopted the conventions…most, even, when midi came out 40 years ago.
Thank you for the correction, although it’s a fairly pedantic initial reply considering the point I was making: Is there any reason why every drum app publisher doesn’t just employ a map that corresponds to the chromatic scale? That’s not a rhetorical question, there may well be. I just haven’t had it explained. Would anything be lost in terms of functionality if that happened, and is there any argument that it wouldn’t make things a whole lot simpler?
If your proof that there have been appreciable efforts to standardize is that a lot of manufacturers adopted conventions, but things haven’t improved much in the last half-century. It almost sounds like you’re describing destandardization if most manufacturers cooperated 40 years ago, but not today. But I’m not sure if that’s what you’re saying.
I know what you mean re. lack of standardization.
I was dealing with this most recently with sound modules for wind controllers.
I'm surprised there's been no mention of General MIDI (GM), which was one of the earliest standards:
https://en.m.wikipedia.org/wiki/Comparison_of_MIDI_standards
This archived article from Electronic Musician explains some of the reasons why GM did not generally apply:
GM Modules for the Masses