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.

EG Nodes

1679111242

Comments

  • @ElliottGarage said:
    'About the 4 bars thing, no testers complain about that...remember that this is not conceived as a full MIDI piano roll au3 app (there are already some on iOS to do that), but as an environment built on scenes and different nodes type that must coexist in a coherent way and 4 bars seems to be enugh for the sceneraio :)

    RE: 4 bars, I'm making this comment as someone who hasn't used Nodes and who has glanced at but not looked closely at the demo video. I also will likely purchase just because it looks like an interesting new approach I'd like to try.

    My comment: It's nice to have an environment where midi sequencer and editing functionality is built in. But I'm curious how I'd make use of my favorite sequencer and chord app plugins within Nodes. Is this demonstrated anywhere?

  • @wim said:

    People complain regularly about the 16 bar limit in Drambo. Enough is never enough. 😉

    Except when it is…

    When Flip Sampler was released, it had a limit of 4 bars. I hated it—it felt way too short. But Ampify Groovebox only has 8 bars, and I love that little app to death. I use it all the time. So I know that for me at least, “Eight is Enough,” but 4 isn’t.

  • I did just try atom in it and it was able to record many bars…

  • I dont get the comments like ‘you dont need that, go somewhere else’.

    Let people request what they want.

  • Is there a way to record and export stems ?

  • edited January 3

    I love when 4, 8, and 16-bars people complain about those who need more bars. 😂 I will never complain about the 4 bar limit in Nodes, it’s just not an app for me. I’m really happy for those who like limitations, they will finally get the perfect solution. It’s like a haiku-style sequencer. 🤩

  • @5k3105 I like when users send me requests or suggestions...it means they like the app and want to use it! That's why I will publish the board with the roadmap... I'd just like that requests will come after they tried the app and check its workflow and if they really miss that feature. Unfortunately it's not easy to make a trial period for an app into iOS.

    @Luxthor everything is a tradeoff between performance, creativity and workflow...limitations are mandatory if you have your design for an app. EG Nodes for me is not a transparent tool as a DAW where you will work and you already know that piano roll works in this way, there you have this tool, there is this and there is that... my apps should have their approach and their way to make things, I need to be creative and have fun while developing...like it or not :)

  • @ElliottGarage said:
    @5k3105 I like when users send me requests or suggestions...it means they like the app and want to use it! That's why I will publish the board with the roadmap... I'd just like that requests will come after they tried the app and check its workflow and if they really miss that feature. Unfortunately it's not easy to make a trial period for an app into iOS.

    @Luxthor everything is a tradeoff between performance, creativity and workflow...limitations are mandatory if you have your design for an app. EG Nodes for me is not a transparent tool as a DAW where you will work and you already know that piano roll works in this way, there you have this tool, there is this and there is that... my apps should have their approach and their way to make things, I need to be creative and have fun while developing...like it or not :)

    I know a lot about limitations, format, and discipline in art, don’t get me wrong. I already stated that Nodes is a fantastic new app. Just that people who work with more bars are not some flux in the matrix, they are real people too, haha. ;)

  • wimwim
    edited January 3

    .

  • It looks great and I have preordered it. Does it have a song mode ? Is it possible to export separate tracks ? Is it possible to export the midi ?

  • edited January 3

    @Luxthor said:

    @ElliottGarage said:
    @5k3105 I like when users send me requests or suggestions...it means they like the app and want to use it! That's why I will publish the board with the roadmap... I'd just like that requests will come after they tried the app and check its workflow and if they really miss that feature. Unfortunately it's not easy to make a trial period for an app into iOS.

    @Luxthor everything is a tradeoff between performance, creativity and workflow...limitations are mandatory if you have your design for an app. EG Nodes for me is not a transparent tool as a DAW where you will work and you already know that piano roll works in this way, there you have this tool, there is this and there is that... my apps should have their approach and their way to make things, I need to be creative and have fun while developing...like it or not :)

    I know a lot about limitations, format, and discipline in art, don’t get me wrong. I already stated that Nodes is a fantastic new app. Just that people who work with more bars are not some flux in the matrix, they are real people too, haha. ;)

    I totally get that limitations are a good thing. It’s a big reason why I choose the iOS platform.

    16 bars would still be a limitation. Christ, if you really want to be limited and be forced to make interesting creative decisions, just never set it past 1 bar. I happen to enjoy making the music I make, just always looking for more efficient workflows, and nodes looks like the one for midi in loopy pro.

    Anyway, I’m repeating myself. Looking forward to trying this in loopy pro and voting for 16 bars and midi export the second the dashboard is published 😉

  • @5k3105 said:
    I dont get the comments like ‘you dont need that, go somewhere else’.

    Let people request what they want.

    If you don't like comments like 'you don't need that, go somewhere else', then go somewhere else.
    (just kidding)

  • I just took a look at Doug & the Dev’s videos & pre-ordered, cause it looks like a nice in-between of aum & drambo & maybe it will be a nice workflow addition. I like the focus on organization of scenes/sequences & the ease of automation & mapping.

    I gotta say: STRONG +1 to more than 4 bars for the rhythm, sequencer, & piano roll.
    I’m a terrible keyboardist & 4 bars is really not a lot to work with. Especially if there’s no pre-recording count-in.
    & I’m sympathetic to the “any limit of bar lengths are always gonna be too small for some people” but dig this: we’ve got 8 scenes by 8 scenes in eg nodes already & 8x8x8 feels nice in a groovy numbers way.

    & popular songs for a loooong time (e.g jazz standards, up to 2020s pop songs) often work in intervals of 8 bars.

    & lastly, if 8 or 12 or 16 bars is more than you need, great!, don’t use ‘em!
    I think it’s better to have ‘em & not need ‘em, than to need ‘em & not have ‘em.

    Thanks for listening!

  • edited January 4

    @wim said:

    @5k3105 said:
    I dont get the comments like ‘you dont need that, go somewhere else’.

    Let people request what they want.

    If you don't like comments like 'you don't need that, go somewhere else', then go somewhere else.
    (just kidding)

    I know right!

    So Im announcing my new project but if anyone not on my test team has a problem, too late you missed your opportunity (that you never had)

  • wimwim
    edited January 4

    @5k3105 said:
    So Im announcing my new project but if anyone not on my test team has a problem, too late you missed your opportunity (that you never had)

    That strikes me as an unfair bit of snark when the developer has made it clear he'll do it if asked and has encouraged all suggestions and thanked everyone thoroughly for them. All he did was express surprise that no one on the beta team brought it up if it's such a common need.

    The situation reminds me of the surprise from the NS2 beta team at the clamor of users over there being no sustain pedal support when the app was released. Not one of them, nor the developer, had ever given it a thought over years and years of development. Sometimes it just goes that way. 😂

    (fwiw, 4 bars sounds like too few for my taste and style, but I admit to not having watched any videos of the app.)

  • Beta tests on small scale tend to result in responses that are unrepresentative of a broader user base. Oftentimes, the points of view tend to be more aligned to the aesthetics of the developer than one might imagine. It is really hard to avoid that.

  • wimwim
    edited January 4

    And bigger beta test groups that are encouraged to give feature feedback in addition to just bug testing can end up making the development process to initial release take a lot longer. That can be the best route in some cases but in others it's necessary or more effective to stay small, get the product to market sooner, and be open to product feedback after release.

  • @wim said:

    @5k3105 said:
    So Im announcing my new project but if anyone not on my test team has a problem, too late you missed your opportunity (that you never had)

    That strikes me as an unfair bit of snark when the developer has made it clear he'll do it if asked and has encouraged all suggestions and thanked everyone thoroughly for them. All he did was express surprise that no one on the beta team brought it up if it's such a common need.

    I was actually taking a snipe at the test group, who are the ones here who have been shouting down the feature requests. Im saying this is what they believe the devs intention was.

    The situation reminds me of the surprise from the NS2 beta team at the clamor of users over there being no sustain pedal support when the app was released. Not one of them, nor the developer, had ever given it a thought over years and years of development. Sometimes it just goes that way. 😂

    (fwiw, 4 bars sounds like too few for my taste and style, but I admit to not having watched any videos of the app.)

    NS2 sustains still do not work correctly. Which brings up an excellent feature request for eg nodes!

  • @wim said:
    And bigger beta test groups can end up making the development process to initial release take a lot longer. That can be the best route in some cases but in others it's necessary or more effective to stay small, get the product to market sooner, and be open to product feedback after release.

    I think the issue is less size than making sure that you have diverse points of view and users. In my opinion, getting to market sooner is not always better...sometimes lack of awareness of important use-cases and needs (particular with complex feature sets) often leads to architectural decisions that are hard to change late in the game.

    It is really hard to put together volunteer beta test teams. A lot of luck is involved.

  • wimwim
    edited January 4

    @5k3105 said:
    I was actually taking a snipe at the test group, who are the ones here who have been shouting down the feature requests. Im saying this is what they believe the devs intention was.

    I must be skimming the thread too quickly. I haven't noticed any "shouting down". I've seen people disagreeing about the importance of it, but don't recall anyone telling anyone they shouldn't speak their mind. Big difference. But probably I overlooked some things.

  • @wim said:

    @5k3105 said:
    I was actually taking a snipe at the test group, who are the ones here who have been shouting down the feature requests. Im saying this is what they believe the devs intention was.

    I must be skimming the thread too quickly. I haven't noticed any "shouting down". I've seen people disagreeing about the importance of it, but don't recall anyone telling anyone they shouldn't speak their mind. Big difference. But probably I overlooked some things.

    No. I was exaggerating.

  • edited January 4

    @wim said:

    The situation reminds me of the surprise from the NS2 beta team at the clamor of users over there being no sustain pedal support when the app was released. Not one of them, nor the developer, had ever given it a thought over years and years of development. Sometimes it just goes that way. 😂

    Another example of the real killer of NS2 was the beta team.

  • @espiegel123 said:

    @wim said:
    And bigger beta test groups can end up making the development process to initial release take a lot longer. That can be the best route in some cases but in others it's necessary or more effective to stay small, get the product to market sooner, and be open to product feedback after release.

    I think the issue is less size than making sure that you have diverse points of view and users. In my opinion, getting to market sooner is not always better...sometimes lack of awareness of important use-cases and needs (particular with complex feature sets) often leads to architectural decisions that are hard to change late in the game.

    It is really hard to put together volunteer beta test teams. A lot of luck is involved.

    Agreed on all points.
    It all comes down to what works best for the developer. Sometimes you just gotta get the product out the door. Sometimes you shoot yourself in the foot with that kind of thinking. Sometimes you think you did it all the right way and still get blindsided.

  • wimwim
    edited January 4

    @OnfraySin said:

    @wim said:

    The situation reminds me of the surprise from the NS2 beta team at the clamor of users over there being no sustain pedal support when the app was released. Not one of them, nor the developer, had ever given it a thought over years and years of development. Sometimes it just goes that way. 😂

    Another example of the real killer of NS2 was the beta team.

    Oh jeez. I can't agree with that statement at all.

    It was also one of the most bug free releases of one of the most elegant pieces of software ever made for iOS. Are you going to credit them with that too?

  • @wim said:

    @espiegel123 said:

    @wim said:
    And bigger beta test groups can end up making the development process to initial release take a lot longer. That can be the best route in some cases but in others it's necessary or more effective to stay small, get the product to market sooner, and be open to product feedback after release.

    I think the issue is less size than making sure that you have diverse points of view and users. In my opinion, getting to market sooner is not always better...sometimes lack of awareness of important use-cases and needs (particular with complex feature sets) often leads to architectural decisions that are hard to change late in the game.

    It is really hard to put together volunteer beta test teams. A lot of luck is involved.

    Agreed on all points.
    It all comes down to what works best for the developer. Sometimes you just gotta get the product out the door. Sometimes you shoot yourself in the foot with that kind of thinking. Sometimes you think you did it all the right way and still get blindsided.

    Yep.

    ButterSynth is a good example where the beta team seemingly suggested many of the features. I joined the beta very late but could tell some key members really helped make it a special app. The trade off seems to be some missed bugs but all that extra flexibility inevitably creates so many more possible scenarios to test.

  • wimwim
    edited January 4

    I gotta get off the internet. It seems like all I'm doing is picking arguments over every post I read. 😂

  • @Krupa said:
    I did just try atom in it and it was able to record many bars…

    Just to reiterate…

  • @Krupa said:

    @Krupa said:
    I did just try atom in it and it was able to record many bars…

    Just to reiterate…

    If you use nodes as an auv3 in a host like loopy pro, you can’t host other auv3s within it so this makes no difference.

  • @gregsmith said:

    @Krupa said:

    @Krupa said:
    I did just try atom in it and it was able to record many bars…

    Just to reiterate…

    If you use nodes as an auv3 in a host like loopy pro, you can’t host other auv3s within it so this makes no difference.

    Ah yeah too right 👍

  • @espiegel123 said:
    Beta tests on small scale tend to result in responses that are unrepresentative of a broader user base. Oftentimes, the points of view tend to be more aligned to the aesthetics of the developer than one might imagine. It is really hard to avoid that.

    You've made some really interesting points. Even though this forum is better than a small test group, it's just niche compared to the wide iOS market.

Sign In or Register to comment.