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.
Comments
+1 to note repeat and slicing. A way to collapse/minimise selected tracks/groups to take up way less screen space would also be great.
Both "Folder tracks" and "Collapse empty tracks" are already on the roadmap
Animoog Z Portamento fixed! New beta will be out shortly 🙏 🥳 (note that the problem occured during recording, so any clips recorded in existing projects will still have the problem.)
Why do this in your code
Midi -> abstraction -> midi
Because it's very awkward to work directly with raw MIDI data in a sane way.
Let's take the example of just displaying a note in the pianoroll editor: you'd have to find each NoteOn event in the MIDI stream to find each note's start, pitch, and velocity, then to know its length, parse the MIDI stream again to find the corresponding NoteOff event.
In the abstracted data, there's just a single array 'notes' with each member being an array of [time,pitch,velocity,length].
If you take something like (N)RPNs, it's even worse as each controller "bar" you need to draw again consists of (sometimes, but not always) multiple MIDI messages spread over the MIDI stream, plus another MIDI message to determine the "width" of the bar (namely, the next controller message with the same CC number).
The code would be many times more complex, bug-prone and slow...
Hey everyone, 2.3.19 Beta has just gone live, let me know your findings regarding Animoog Z (and others) @espiegel123 et al!
I also have a request for comments: During working with Animoog, I noticed that Xequence's behaviour with intentionally overlapping notes is somewhat sub-optimal:
So far, I've always assumed that MPE notes should never overlap, i.e. there should never be two notes that partially overlap and share the same channel.
However, with portamento, this does make sense and actually seems "normal" behaviour (you'll notice that if you record portamento from Animoog Z, there'll be pairs of notes with, say, channel 12, then the next portamento pair with channel 13 etc.)
BUT: Xequence tries its utmost to prevent overlapping notes with the same channel as soon as you execute any kind of editing operation: For example, if you MOVE these overlapping notes in the pianoroll editor, Xequence will re-assign a different channel to one of the notes because it "thinks" that overlap is bad.
How do other DAWs handle this? How could this be handled well?
Maybe do not re-assign channels if some notes overlapped already before the operation?
Add a toggle to completely disable automatic channel re-assignment in the editors? (right now, it can only be disabled for new stuff, like drawing notes, recording notes, etc.)
...
Interested in opinions / how other apps work.
Regarding overlapping notes, an idea: if notes are still overlapped after edit, keep channel unchanged, if not, ask to assign a new channel?
Yes that sounds good. i.e., detect which notes overlapped before the edit, and if the same notes still overlap after the edit, don't change their channels except if they now overlap with other notes as well. (but then change the channel of the other notes)
This is all quite complicated... I wonder if any DAW actually handles all of this transparently and correctly...
OK, so this should then probably go into the instrument MPE settings, as it's specific to how a particular instrument is used?
So probably rename this section to "Auto-Assign Free Channels to new Notes from", and then add another toggle "When moving / duplicating" or so?
Also, should this be enabled or disabled by default?
>
Good suggestion!
@SevenSystems : rather than ask us, you might want to talk to geert Bevin who besides working at Moog also works on the Linnstrument and is a fount of knowledge about MPE and how things are supposed to work.
@SevenSystems : unfortunately still not working correctly.
Hrmmmm, okay... could you try the following (each in order):
Thanks!
I guess I might end up having to write an entire manual section for each combination of MPE input/output device
No difference.
No difference
It was already disabled
no difference. i tried The Meaning of... and also Brass with glide all the way up.
no difference
@SevenSystems : you might want to record midi from animoog into MTR and Xeq at the same time then export from mtr and xequence and compare?
sounds exhausting!
@espiegel123 last idea: In "MIDI / Recording" -> "MIDI Output", set "Length Correction" to 0? (all the way to the left)
THAT WORKED!
Holy hell! 🥵 another thing to consider then. The intention of "Length Correction" is to avoid "false portamento" when quantizing notes to be exactly next to each other... but if portamento is intended and the receiving synth (here: Animoog Z) is extremely picky about timing, then it will make portamento fail.
Oh dear! Maybe Length Correction should default to 0 then, or be a per-instrument setting (at some point though, the instrument settings will look like a spaceship.)
So in the end, another compromise: What's more important:
Thinking about it, it might be best to scrap the "Length Correction" feature entirely, and if users notice that their synth is doing portamento when it shouldn't, maybe they'll figure out they need to manually shorten notes a little in the pianoroll editor anyway?
In any case, I'm now pretty convinced the default should be 0 or off, as it's in a way a "destructive" feature anyway (unexpectedly changes the MIDI output data)
I agree.
Right. Might be a good thing for the FAQ section in the manual
@SevenSystems I would second the recommendation to connect with Geert Blevin about some of this stuff. He's very approachable and probably the leading authority at this point regarding where these topics converge. I don't think he is interested it working out all the oddities of MPE editing himself, but I suspect he would be more than happy to support you in the effort. Wonder twins unite!
There’s a parallel here with a common UX interaction pattern in plugin synthesizers. The interaction design pattern began life in 303 emulators. They needed to offer a simple way to program slides via the pianoroll. And this was solved by introducing a design pattern to treats legato notes as seperate notes and overlapping notes as slides/portamento. In fact, if you want to achieve authentic 303 playback, legato playing doesn’t exist as the 303 sequencer ends notes short of their note value (whilst still being longer than staccato). This design pattern is now found in some other plugin and hardware synths.
Whilt we’re not talking the same thing here as legato notes trigger portamento in Xequence 2.3 MPE, but the parallel is close enough that your suggested workflow should come naturally enough to many.
Weirdly enough, when utilising MPE in Ableton, I often step program the process. To many, this may seem tedius but in practice I find that it’s faster to do this than record MPE as a live performance and then edit the playback.
@jonmoore yes, I know about that pattern -- that's mostly why I introduced the "Length Correction" in the first place. I was expecting synths to expect that pattern, and to account for possible slight timing variations (especially with hardware), I wanted to make sure that when users used the "Process" -> "Legato" feature in the Pianoroll editor (or used "Ends" quantization), no synth would "accidentally" trigger portamento because of the extremely short gap (zero) between one note's end and the next note's beginning.
But it seems like Animoog Z and probably many others will send and receive portamento only when note ends and beginnings exactly align, so that "Length Correction" feature makes portamento stop working then (except if users went in and manually extended notes, but that has other problems).
The whole portamento situation is a mess because there's no agreed on standard. I also just recently found out that there's 3 (three) MIDI CC messages that explicitly control portamento (on/off, time, and even which note!), which Animoog Z uses as well as expecting notes to exactly align. This is many different things that have to go exactly right in order for portamento to work.
I guess the ole' 303 implementation is a bit saner.