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.

Xequence 2.4: Workflow, Workflow, Workflow!

1356

Comments

  • Looks and sounds great
    Looking forward to the update

  • edited August 2022

    @Gavinski said:
    Also probably not small (you're gonna regret making this thread), but I'd love to see Xequence keys au as an mpe keyboard!

    +1 on MPE keyboard.

    Lol. There will be feedback, but maybe a little more then you bargained for, lol.

    Congratulations @SevenSystems on making X2 even better.

  • Hi! Many thanks @SevenSystems for your continuous efforts and participation.
    Not posting here a lot (but following the discussions with high interest), I tend to use X2 more and more.

    I wonder if anything better could be done to set the loop from the ruler bar, instead of the two taps via the loop button, and also shifting the loops (…I quite like how it is done in NS2 - sorry to be that guy). Or did I miss the obvious?
    Thanks

  • edited August 2022

    Great. So as soon as 2.4 is released, all those nutcases* who left a one-star review for the lack of this button can return and change it into a 6-star 🤣

    (*) I value all my customers! Nutcase in this context is meant purely as an affectionate term.

  • Not workflow related, but I’m wondering where tempo and meter changes are on the roadmap?

  • @Strigoi said:
    Not workflow related, but I’m wondering where tempo and meter changes are on the roadmap?

    Tempo changes: very far down, unlikely to happen soon (sorry) -- meter changes: Further up, likely at some point implemented at the clip level.

  • at the risk of my sanity being - be it affectionately - questioned:
    a question whether (a request to if needed) a switch to loopy pro standalone button will be included (just like AUM)?
    I will off course add seven stars

  • @prtr_jan said:
    at the risk of my sanity being - be it affectionately - questioned:
    a question whether (a request to if needed) a switch to loopy pro standalone button will be included (just like AUM)?
    I will off course add seven stars

    That'll already be possible anyway in 2.4 by adding Xequence as an IAA source in Loopy Pro, just tested:

  • @SevenSystems said:

    @prtr_jan said:
    at the risk of my sanity being - be it affectionately - questioned:
    a question whether (a request to if needed) a switch to loopy pro standalone button will be included (just like AUM)?
    I will off course add seven stars

    That'll already be possible anyway in 2.4 by adding Xequence as an IAA source in Loopy Pro, just tested:

    Great! (I probably misread host for AUM)

  • edited August 2022

    I'm considering adding a "Note Gap" setting to the pianoroll editor. This would open a menu similar to the grid size dropdown (1/16, 1/32 etc.), and the setting would:

    • for "Process -> Legato": leave a gap between notes
    • for "Draw" mode: make drawn notes always that much shorter than actually drawn (or the grid size, when tapped) (doesn't apply when grid is off)

    Would anyone find this useful? I often find myself wanting to have a specific gap between notes either drawn according to the grid or when using "Legato", and am too lazy to keep manually shortening them using the handle after.

  • @SevenSystems said:
    I'm considering adding a "Note Gap" setting to the pianoroll editor. This would open a menu similar to the grid size dropdown (1/16, 1/32 etc.), and the setting would:

    • for "Process -> Legato": leave a gap between notes
    • for "Draw" mode: make drawn notes always that much shorter than actually drawn (or the grid size, when tapped) (doesn't apply when grid is off)

    Would anyone find this useful? I often find myself wanting to have a specific gap between notes either drawn according to the grid or when using "Legato", and am too lazy to keep manually shortening them using the handle after.

    +1
    I do also switch off snap to and manually adjust lengths.
    Also, being lazy and not scanning every post…has the “humanise” thing been mentioned again?
    A subtle randomiser for note position/length on a sliding percentage scale…? 🤞🏻

  • @crushed said:
    Hi! Many thanks @SevenSystems for your continuous efforts and participation.
    Not posting here a lot (but following the discussions with high interest), I tend to use X2 more and more.

    Thanks a lot, glad you like the app.

    I wonder if anything better could be done to set the loop from the ruler bar, instead of the two taps via the loop button, and also shifting the loops (…I quite like how it is done in NS2 - sorry to be that guy). Or did I miss the obvious?
    Thanks

    I guess the main advantage of Nanostudio here is that you can move both loop points at once by dragging in the middle? (vs. Xequence where you can only drag the start and end individually)

  • edited August 2022

    @Zerozerozero said:

    @SevenSystems said:
    I'm considering adding a "Note Gap" setting to the pianoroll editor. This would open a menu similar to the grid size dropdown (1/16, 1/32 etc.), and the setting would:

    • for "Process -> Legato": leave a gap between notes
    • for "Draw" mode: make drawn notes always that much shorter than actually drawn (or the grid size, when tapped) (doesn't apply when grid is off)

    Would anyone find this useful? I often find myself wanting to have a specific gap between notes either drawn according to the grid or when using "Legato", and am too lazy to keep manually shortening them using the handle after.

    +1
    I do also switch off snap to and manually adjust lengths.

    Good, thanks for confirming.

    Also, being lazy and not scanning every post…has the “humanise” thing been mentioned again?
    A subtle randomiser for note position/length on a sliding percentage scale…? 🤞🏻

    Hey, that's a feature request, not a workflow optimization! 😉 it is on the roadmap though and useful for sure.

    btw -- have you tried using the per-track Swing settings? Some odd combination of percentage and "Swing rhythm" (maybe with triplets) might give you something useful (and non-destructive) for now...

  • @SevenSystems said:

    @crushed said:
    Hi! Many thanks @SevenSystems for your continuous efforts and participation.
    Not posting here a lot (but following the discussions with high interest), I tend to use X2 more and more.

    Thanks a lot, glad you like the app.

    I wonder if anything better could be done to set the loop from the ruler bar, instead of the two taps via the loop button, and also shifting the loops (…I quite like how it is done in NS2 - sorry to be that guy). Or did I miss the obvious?
    Thanks

    I guess the main advantage of Nanostudio here is that you can move both loop points at once by dragging in the middle? (vs. Xequence where you can only drag the start and end individually)

    Yes, spot on! And also toggle the loop mode by double-tapping. Does it count as an un-discoverable gesture?

  • @crushed said:

    @SevenSystems said:

    @crushed said:
    Hi! Many thanks @SevenSystems for your continuous efforts and participation.
    Not posting here a lot (but following the discussions with high interest), I tend to use X2 more and more.

    Thanks a lot, glad you like the app.

    I wonder if anything better could be done to set the loop from the ruler bar, instead of the two taps via the loop button, and also shifting the loops (…I quite like how it is done in NS2 - sorry to be that guy). Or did I miss the obvious?
    Thanks

    I guess the main advantage of Nanostudio here is that you can move both loop points at once by dragging in the middle? (vs. Xequence where you can only drag the start and end individually)

    Yes, spot on! And also toggle the loop mode by double-tapping. Does it count as an un-discoverable gesture?

    Hah. The "undiscoverable gesture" bit was actually crossing my mind.

    I probably would avoid the double-tapping. You can already toggle the loop with two taps (Loop button -> "Song Loop")... just not exactly in the same spot ;)

    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

  • @SevenSystems said:
    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    I think it’s faster, at least for how I use loop regions. I usually know how many bars I want, just not always which section of the larger clip. So sliding around is much quicker and easier, and doesn’t force me to count bars. Plus, if the bit you’re looking for starts after the end marker it forces even more juggling. Lastly, if the region is longer than the display then you save zooming out, moving with less precision, checking number of bars…

  • @SevenSystems said:

    @crushed said:

    @SevenSystems said:

    @crushed said:
    Hi! Many thanks @SevenSystems for your continuous efforts and participation.
    Not posting here a lot (but following the discussions with high interest), I tend to use X2 more and more.

    Thanks a lot, glad you like the app.

    I wonder if anything better could be done to set the loop from the ruler bar, instead of the two taps via the loop button, and also shifting the loops (…I quite like how it is done in NS2 - sorry to be that guy). Or did I miss the obvious?
    Thanks

    I guess the main advantage of Nanostudio here is that you can move both loop points at once by dragging in the middle? (vs. Xequence where you can only drag the start and end individually)

    Yes, spot on! And also toggle the loop mode by double-tapping. Does it count as an un-discoverable gesture?

    Hah. The "undiscoverable gesture" bit was actually crossing my mind.

    I probably would avoid the double-tapping. You can already toggle the loop with two taps (Loop button -> "Song Loop")... just not exactly in the same spot ;)

    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    It’s much of a muchness, I admit. One’s habit is not necessarily anyone else’s and there are good reasons to keep things as they are.
    Learnt something in this discussion. Didn’t know that tapping song loop again would actually toggle the current loop, sure I can catch this habit.

  • @SevenSystems said:
    Great. So as soon as 2.4 is released, all those nutcases* who left a one-star review for the lack of this button can return and change it into a 6-star 🤣

    (*) I value all my customers! Nutcase in this context is meant purely as an affectionate term.

    I hope they do. I’m not even a developer and it still kind of upsets me when I read a review that is clearly a user error, or it’s something that is obviously not the apps fault…

  • @wim said:

    @SevenSystems said:
    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    I think it’s faster, at least for how I use loop regions. I usually know how many bars I want, just not always which section of the larger clip. So sliding around is much quicker and easier, and doesn’t force me to count bars. Plus, if the bit you’re looking for starts after the end marker it forces even more juggling. Lastly, if the region is longer than the display then you save zooming out, moving with less precision, checking number of bars…

    OK, that all makes sense, and I'm almost persuaded.

    We have two options now:

    1) just drag the song loop as soon as finger is put on the ruler inside the loop region and moved. We lose the ability to position the song pointer inside the loop region then
    2) only drag the song loop when HOLDING the finger inside the loop region and then moving. We can then still position the song pointer with short taps.

    Whaddayathink? Also @crushed

    ( 3) I'll probably make this configurable. Options Shmoptions! )

  • @Poppadocrock said:

    @SevenSystems said:
    Great. So as soon as 2.4 is released, all those nutcases* who left a one-star review for the lack of this button can return and change it into a 6-star 🤣

    (*) I value all my customers! Nutcase in this context is meant purely as an affectionate term.

    I hope they do. I’m not even a developer and it still kind of upsets me when I read a review that is clearly a user error, or it’s something that is obviously not the apps fault…

    Yes, I also sometimes cringe when reading other good apps' reviews.

    My "favorite" Xequence review is still this though:

    ;)

  • The user and all related content has been deleted.
  • @tja said:

    @SevenSystems said:

    ( 3) I'll probably make this configurable. Options Shmoptions! )

    This!

    😅🤗

    Yes. Will resume development as soon as my Model M keys are finished drying...

  • The user and all related content has been deleted.
  • @SevenSystems said:

    @wim said:

    @SevenSystems said:
    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    I think it’s faster, at least for how I use loop regions. I usually know how many bars I want, just not always which section of the larger clip. So sliding around is much quicker and easier, and doesn’t force me to count bars. Plus, if the bit you’re looking for starts after the end marker it forces even more juggling. Lastly, if the region is longer than the display then you save zooming out, moving with less precision, checking number of bars…

    OK, that all makes sense, and I'm almost persuaded.

    We have two options now:

    1) just drag the song loop as soon as finger is put on the ruler inside the loop region and moved. We lose the ability to position the song pointer inside the loop region then
    2) only drag the song loop when HOLDING the finger inside the loop region and then moving. We can then still position the song pointer with short taps.

    Whaddayathink? Also @crushed

    ( 3) I'll probably make this configurable. Options Shmoptions! )

    Nice! May I suggest another one?

    On short tap + drag in the loop region (no undiscoverable “holding”)
    If the tap location is on the song pointer: move the song pointer
    Otherwise, move the loop region

    If not feasible, I’d rather have one forced mode rather than yet another setting

  • @crushed said:

    @SevenSystems said:

    @wim said:

    @SevenSystems said:
    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    I think it’s faster, at least for how I use loop regions. I usually know how many bars I want, just not always which section of the larger clip. So sliding around is much quicker and easier, and doesn’t force me to count bars. Plus, if the bit you’re looking for starts after the end marker it forces even more juggling. Lastly, if the region is longer than the display then you save zooming out, moving with less precision, checking number of bars…

    OK, that all makes sense, and I'm almost persuaded.

    We have two options now:

    1) just drag the song loop as soon as finger is put on the ruler inside the loop region and moved. We lose the ability to position the song pointer inside the loop region then
    2) only drag the song loop when HOLDING the finger inside the loop region and then moving. We can then still position the song pointer with short taps.

    Whaddayathink? Also @crushed

    ( 3) I'll probably make this configurable. Options Shmoptions! )

    Nice! May I suggest another one?

    On short tap + drag in the loop region (no undiscoverable “holding”)
    If the tap location is on the song pointer: move the song pointer
    Otherwise, move the loop region

    If not feasible, I’d rather have one forced mode rather than yet another setting

    That would be feasible, however it would introduce another new concept: "Drag the song pointer". (currently, you don't need to drag it -- you can just tap or drag anywhere in the ruler to set / move it). Also, the song pointer currently doesn't have any visual representation inside the ruler area, so nothing indicates it could be dragged (in fairness though, NOTHING in the ruler indicates that anything can be done 😄)

    Thanks for all the feedback... I'll probably go with a setting. I LOVE settings. Not for my sake -- for me it's very tedious and bug prone... but I know USERS want to have things JUST their way 🤔☺️

    Maybe a good compromise is:

    • Setting 1: Everything stays as it is now
    • Setting 2: Just TAPPING inside the loop area sets the pointer. DRAGGING inside the loop area moves the loop. And maybe (@crushed suggestion) : DRAGGING inside the loop area, but starting the drag near the pointer, moves the pointer. However, that could result in fiddliness because there's no visual indication that the area near the song pointer is "special" and one cannot count on being able to "just quickly move the loop area in a hurry" because one might accidentally hit and drag the song pointer instead.

    See how ONE little request can result in 3 days of philosophical UI UX discussion 😂

  • wimwim
    edited August 2022

    @SevenSystems said:
    Thanks for all the feedback... I'll probably go with a setting. I LOVE settings. Not for my sake -- for me it's very tedious and bug prone... but I know USERS want to have things JUST their way 🤔☺️

    How very non Apple-ish of you. (That's a compliment btw. 😎)

    Maybe a good compromise is:

    • Setting 1: Everything stays as it is now
    • Setting 2: Just TAPPING inside the loop area sets the pointer. DRAGGING inside the loop area moves the loop. And maybe

    Setting 2 sounds the best to me.

  • @SevenSystems said:

    @crushed said:

    @SevenSystems said:

    @wim said:

    @SevenSystems said:
    About the "move whole loop region by dragging in the middle": I'm not entirely sure. I've thought about this a lot before starting on Xequence, and at least for me, I almost ALWAYS want the loop region to be identical to the extents of one or more existing clips in the arrangement. That's why Xequence has this "Select, then set loop region" concept.

    Is it truly faster to drag the loop region manually and try to hit exactly the correct bars? (truly wondering! Maybe it's just a habit because most other software works that way?)

    I think it’s faster, at least for how I use loop regions. I usually know how many bars I want, just not always which section of the larger clip. So sliding around is much quicker and easier, and doesn’t force me to count bars. Plus, if the bit you’re looking for starts after the end marker it forces even more juggling. Lastly, if the region is longer than the display then you save zooming out, moving with less precision, checking number of bars…

    OK, that all makes sense, and I'm almost persuaded.

    We have two options now:

    1) just drag the song loop as soon as finger is put on the ruler inside the loop region and moved. We lose the ability to position the song pointer inside the loop region then
    2) only drag the song loop when HOLDING the finger inside the loop region and then moving. We can then still position the song pointer with short taps.

    Whaddayathink? Also @crushed

    ( 3) I'll probably make this configurable. Options Shmoptions! )

    Nice! May I suggest another one?

    On short tap + drag in the loop region (no undiscoverable “holding”)
    If the tap location is on the song pointer: move the song pointer
    Otherwise, move the loop region

    If not feasible, I’d rather have one forced mode rather than yet another setting

    That would be feasible, however it would introduce another new concept: "Drag the song pointer". (currently, you don't need to drag it -- you can just tap or drag anywhere in the ruler to set / move it). Also, the song pointer currently doesn't have any visual representation inside the ruler area, so nothing indicates it could be dragged (in fairness though, NOTHING in the ruler indicates that anything can be done 😄)

    Thanks for all the feedback... I'll probably go with a setting. I LOVE settings. Not for my sake -- for me it's very tedious and bug prone... but I know USERS want to have things JUST their way 🤔☺️

    You’re probably right that we are in a domain in which it’s difficult to find the way that will satisfy the most, and you have already realised that the ABF crowd is particularly demanding.

    Maybe a good compromise is:

    • Setting 1: Everything stays as it is now
    • Setting 2: Just TAPPING inside the loop area sets the pointer. DRAGGING inside the loop area moves the loop. And maybe (@crushed suggestion) : DRAGGING inside the loop area, but starting the drag near the pointer, moves the pointer. However, that could result in fiddliness because there's no visual indication that the area near the song pointer is "special" and one cannot count on being able to "just quickly move the loop area in a hurry" because one might accidentally hit and drag the song pointer instead.

    Thanks a lot for being so open. I think your proposal is very reasonable, and sounds like a genuine improvement, even without the bit I suggested. I hope that the people interested will acknowledge it’s indeed a good compromise.

    See how ONE little request can result in 3 days of philosophical UI UX discussion 😂

    We can be waffling forever on the forums, but the truth is in the pudding.
    Such UI topics are IMHO better discussed after the users had a chance to try with their fingers. If you ever considered running such experiments in the betas, you could get some more informed feedback.
    (I know though it’s probably not possible at your scale to spend development time on features that may or may not end up in the product.)

  • @wim said:

    @SevenSystems said:
    Thanks for all the feedback... I'll probably go with a setting. I LOVE settings. Not for my sake -- for me it's very tedious and bug prone... but I know USERS want to have things JUST their way 🤔☺️

    How very non Apple-ish of you. (That's a compliment btw. 😎)

    Hah, thanks. It's interesting because when you look at it, the iOS settings app actually contains a HUGE amount of settings. It just seems like Apple maybe doesn't take the right decisions about which ones to include... 🤔

    Setting 2 sounds the best to me.

    Yeah, I guess I'll go with offering both "modes" in Settings, i.e. "old behaviour" and variant 2).

  • @crushed said:
    You’re probably right that we are in a domain in which it’s difficult to find the way that will satisfy the most, and you have already realised that the ABF crowd is particularly demanding.

    I wouldn't call it demanding... people just know exactly how they want to work and are able to articulate it (most of the time). You don't get that with your average photo filter app users... so I actually appreciate it. Just sometimes I guess you have to tame the crowd a little, like excited kids running around on a birthday party! 😄

    Thanks a lot for being so open. I think your proposal is very reasonable, and sounds like a genuine improvement, even without the bit I suggested. I hope that the people interested will acknowledge it’s indeed a good compromise.

    Yeah, I'll probably be offering both the current way and variant 2). If there's one thing that users hate like the plague, it's when an update CHANGES some behaviour of the app, even minor, that's deeply ingrained in their muscle memory.

    See how ONE little request can result in 3 days of philosophical UI UX discussion 😂

    We can be waffling forever on the forums, but the truth is in the pudding.
    Such UI topics are IMHO better discussed after the users had a chance to try with their fingers. If you ever considered running such experiments in the betas, you could get some more informed feedback.
    (I know though it’s probably not possible at your scale to spend development time on features that may or may not end up in the product.)

    I've actually done that with the MPE stuff a lot, the beta feedback was really quite helpful there.

    Anyway. Cleaned the keyboard today and it took hours to dry so didn't get around to doing much. More tomorrow! 🤣

  • Is the 2.4 beta out? Mine is showing 2.3.21 still. I just downloaded that X2LoopyDawless1.1 setup for testing and I get a message that it’s been created in a newer version of X2 so I’m just curious…

Sign In or Register to comment.