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.

ATOM Piano Roll update is coming soon

1383941434457

Comments

  • edited March 2021

    For those who want #2.. You can always wait until it is ready.. you don’t have to use this version... unless you already have access to the beta and just want ... well

    Anyway.. option #1 please..

  • @jblock said:
    Option 1 for sure. People will always want more. From an agile perspective, big releases are more few and far between for many companies. More frequent, smaller releases are the way to go when you don't have an army of devs, or more importantly, QA folks to ensure a big release has all the bugs worked out.

    We're in the middle of switching from quarterly releases to weekly. I hear you. I don't feel that the MVP! Iterate! approach is always ideal, but there's always going to be a #2 to work on.

  • I also vote for option 1. I have been waiting for loading MIDI files in for quite some time :)

    And, to emphasize this again, thanks for this brilliant plugin!

  • edited March 2021

    @espiegel123 said:

    @0tolerance4silence said:

    @ExAsperis99 said:
    Can we define what we mean by automation?

    For instance: I have a synth that is being sent midi from an instance of Atom. As this clip plays back, I manually open and close the filter on the synth. That gesture could not be recorded by Atom2, correct? Or would it be recorded but editing it would not be possible? Would love to see that in the future.

    I still vote for No. 1. By a mile.

    What you’d like to achieve won’t be possible, even later. Not without lengthy mapping etc. Software synths rarely transmit/generate midi, there is nothing Atom can do about that.

    He may have meant opening and closing it via CC event from a controller -- which for me is the critical case. Capturing the CCs generated by the knobs and wheels and sliders on my controllers (and aftertouch, etc)

    This is what I mean, but I'm surprised this was even in the offing. I'm not looking for Atom2 to edit all the movement of my instruments in the final iteration, but that would be wonderful. (I was always banking on at some point moving the midi or the stems to a DAW for further refinement.)

    I really just want a fast and flexible and reliable solution to capturing the songwriting/jamming process within AUM.

  • @ExAsperis99 said:

    @espiegel123 said:

    @0tolerance4silence said:

    @ExAsperis99 said:
    Can we define what we mean by automation?

    For instance: I have a synth that is being sent midi from an instance of Atom. As this clip plays back, I manually open and close the filter on the synth. That gesture could not be recorded by Atom2, correct? Or would it be recorded but editing it would not be possible? Would love to see that in the future.

    I still vote for No. 1. By a mile.

    What you’d like to achieve won’t be possible, even later. Not without lengthy mapping etc. Software synths rarely transmit/generate midi, there is nothing Atom can do about that.

    He may have meant opening and closing it via CC event from a controller -- which for me is the critical case. Capturing the CCs generated by the knobs and wheels and sliders on my controllers (and aftertouch, etc)

    This is what I mean, but I'm surprised this was even in the offing. I'm not looking for Atom2 to edit all the movement of my instruments in the final iteration, but that would be wonderful. (I was always banking on at some point moving the midi or the stems to a DAW for further refinement.)

    I really just want a fast and flexible and reliable solution to capturing the songwriting/jamming process within AUM.

    +1

    and there is nothing that does that. Photon ALMOST does, but its lack of state saving makes it a pain to use and just enough extra steps to get your recording assigned to a pad and playing back that it feels clunky. ATOM1 is almost there -- except that it doesn't record the MIDI channel info with the incoming notes and doesn't record controllers.

    I'd love controller editing when it comes -- but if it is usable sooner than that without it I think that would serve a lot of people's needs. LK is nice as a clip launcher but for a piano roll note editor, I'd choose ATOM -- and LK only handles 4/4.

  • edited March 2021

    Option 1 for sure ... it's been quite a wait already, and so releasing gets it out the door, plus gives you more time to get automation sorted without the pressure of everyone waiting for SOMETHING to drop, especially as you set such high standards for yourself.

  • Don’s understand the dilemma.
    If it is release now those who want to buy it can buy now, it those who want to wait can wait. 😀😀
    Where is the problem ?

  • edited March 2021

    @espiegel123 said:

    @ExAsperis99 said:

    @espiegel123 said:

    @0tolerance4silence said:

    @ExAsperis99 said:
    Can we define what we mean by automation?

    For instance: I have a synth that is being sent midi from an instance of Atom. As this clip plays back, I manually open and close the filter on the synth. That gesture could not be recorded by Atom2, correct? Or would it be recorded but editing it would not be possible? Would love to see that in the future.

    I still vote for No. 1. By a mile.

    What you’d like to achieve won’t be possible, even later. Not without lengthy mapping etc. Software synths rarely transmit/generate midi, there is nothing Atom can do about that.

    He may have meant opening and closing it via CC event from a controller -- which for me is the critical case. Capturing the CCs generated by the knobs and wheels and sliders on my controllers (and aftertouch, etc)

    This is what I mean, but I'm surprised this was even in the offing. I'm not looking for Atom2 to edit all the movement of my instruments in the final iteration, but that would be wonderful. (I was always banking on at some point moving the midi or the stems to a DAW for further refinement.)

    I really just want a fast and flexible and reliable solution to capturing the songwriting/jamming process within AUM.

    +1

    and there is nothing that does that. Photon ALMOST does, but its lack of state saving makes it a pain to use and just enough extra steps to get your recording assigned to a pad and playing back that it feels clunky. ATOM1 is almost there -- except that it doesn't record the MIDI channel info with the incoming notes and doesn't record controllers.

    I'd love controller editing when it comes -- but if it is usable sooner than that without it I think that would serve a lot of people's needs. LK is nice as a clip launcher but for a piano roll note editor, I'd choose ATOM -- and LK only handles 4/4.

    This is why I respectfully disagree with @rs2000 and @0tolerance4silence when they say "most of these things can already be done". I'd say a large market segment exists that simply wants what you describe above.

  • I’m going to vote option 1. Updates and features being added are always something I generally expect to happen after the first version of an app anyway. People will endlessly ask for features anyway and automation will be awesome but i think the main draw for the app is the piano roll features

  • @blueveek A consequence of a release now will bring you in the situation that you must also reply at posts that will be placed here in this thread. The community will ask you questions, will post bugs and will ask for features. This will distract you. If you want to focus on the further development of Atom 2, don't release it now. That's a choice you can/must make yourself.

  • Hmmmm. so I have been not in the game lately and I’m a dolt... are we saying that version 1 will not let you draw automation for exposed parameters in AUM for example?

  • I’ve seen screen grabs for weeks to know I could make good use of this app as is so Option 1 for me.

  • Option 1 please.

    If you do option 2 the pressure will be too much!!!

    A good update is also like another birthday present 🎁

    It’s like your giving two amazing gifts to the community :)

    Or put me onto the Beta list hahaha 🤣

  • edited March 2021

    @espiegel123 said:

    @blueveek said:
    @espiegel123 CC.

    It would be very annoying to record CC and not be able to edit/delete it (e.g. if a new layer or a different phrase is recorded).

    Regarding channels, you can pick whichever channel to output on (there's a new toolbar on the left that was shown in previous screenshots). Atom listens to everything it receives, and filtering input can be done at the host level.

    I disagree somewhat. I would strongly recommend an option to be able to record all received information and play it back even if it weren’t editable (other than say maybe select all and moving everything in time).

    It is the single biggest hole in the MIDI recording AU world..the ability to simply capture and playback everything that comes in.

    Sure there are lots times where one wants to edit the CC stuff...but I’d rather be able to capture and play everything without editing than not have that.

    MY vote goes for option 1 BUT with CC recording enabled! you can filter CC if you need to record notes only!
    I really miss a AUv3 MIDI recorder capable of recording all MIDI events.
    Then later you can finish and add the CC edit feature in a future update. I think thats the best scenario for us users! Thanks for bringing the question to public!

  • The user and all related content has been deleted.
  • The user and all related content has been deleted.
  • edited March 2021

    Clearly and without a doubt option1 please. We can expect an outstanding tool with lots of new features compared to the first version that will immediately advance our AUv3 piano roll workflow tremendously. So why wait? Automation is coming anyway. It's about creating music now! And not to wait for the very last perfectly implemented future feature and the ultimate version, which is per se an utopia because it will never exist, the perfect app. In any case, I'm glad that Imaginando does not make us wait three years with LK and then present their final >I can now (still not) do everything< version. 😉 Victor himself provides the best argument for option 1: “...and this doesn't really affect anything: in the long term we'll arrive at the same thing.”

    So guys, be thankful and use the tools he wants to provide you with right now for your benefit.

    I don't know why so many here are concerned when it comes to expectations, feature requests and distractions. Victor certainly knows how to deal with them, I'm sure these issues won't present him with any particular challenges. He seems to know pretty well what he wants to achieve with Atom 2. I have full confidence in his abilities and determination. Thank you Victor for your dedicated work and your openness here in the forum!

  • ya youve def just unleashed like 10 pages worth of battling @blueveek

  • @sloJordan said:
    ya youve def just unleashed like 10 pages worth of battling @blueveek

    He's just playin us. He wants to beat the Drambo thread for longest running thread before launch.

  • Option 1 now and add automation and striped curtains in updates Msr Veek ... all his work isn't earning you a penny while it's sitting on the bench. Should be a very popular app with an eager audience.

  • edited March 2021

    Must say I’ve been pleased to read so many supportive and sensible responses above.

    The problem with Atom2 - speaking as one of the very small number of lucky beta/QA testers - is that once you start using this deep app, it’s so very easy to keep thinking of deeper and deeper ways you would like to use it. In other words... you can’t help thinking of new niche use-cases that suddenly require the dev to expose more settings or a raft of new tick boxes that enable users to override default settings under the bonnet that were previously assumed would never need to be adjusted.

    I must accept that responsibility for some of the delays to releasing this app rest squarely with me. This app is nothing if not ambitious (as you will soon see). And you should see some of the deep and exciting stuff we’ve already pencilled onto the (potential) roadmap for a 2.X update on our beta tester’s Trello board! (feel free to ask about my obsessive enthusiasm for a ‘state machine’ add-on)

    As both a modular piano roll and clip launcher, this app needs to be versatile enough to slot into almost any host and/or workflow... no easy task. It also needs to strike the right balance between power and flexibility and ease of use... an even harder task. And on top of all this it supports deep integration with Launchpad hardware controllers!

    Suffice it to say... I’m completely torn between supporting option 1 and option 2. I wish Blueveek good luck in making his choice. It will be awesome whenever it releases: now or later.

    Side note:
    It sounds like some users here are in favour of Atom acting as a kind of ‘black box’ MIDI recorder. I understand this desire. Being able to capture all incoming CC, MPE, and multi-channel MIDI is an important requirement. But I’m not sure that’s quite what this app was designed to be. Although I agree it would be nice to capture all CC for some future update where it becomes fully editable and redirectable - the second you start moving notes about in your pattern - i.e. chopping and painting notes - surely all that CC data goes out of sync with your patterns?

  • Option 1 and those who wanna wait for 2, are more than welcome hehe i wanna get this thing rolling and get familiar with it!

  • I'd say option 1 with draft ,delete automation, reverse automation , inverse automation buttons

    Later on detailed editing automation can be added

    BUT
    if option 2 requires GUI rearrangement , major code rewrite , then I'd prefer waiting for a polished release :)

  • This is like the hype man before a show asking "can i get some NOIISSSEEE??!?!?!" and if we are loud enough he'll finally drop this bad boi

  • edited March 2021

    Another +1 for option 1 Plus the CC recording. Even if it can't be edited on release it's still something. It'd be nice if overdub was included just to refine a looped part for example but still. I like Xequence but I'm tired of having to rely on an external app and having to load the same songs on multiple apps, which is why I'm eager to try the new Atom option 1. I'm fine with using Drambo for automation; doesn't seem like a hassle imo. I just want a convenient piano roll for the compositional bit.

  • edited March 2021

    A key concept in AGILE software development is release early and release often. It is a more modern approach than waterfall which relies on one big release later. Your users get more value from the frequent releases, the users get to be testers and provide feedback (if you want it) and as long as Option 1 doesn't come with a price and what comes in 2.X also has a price, then I'd say do Option 1 at whatever upgrade fee you were planning... and then only make the automation available to those who have the updated Atom 2 and paid your upgrade fee.

    Release early and release often. We do two week sprints.

  • @Jeezs said:
    Don’s understand the dilemma.
    If it is release now those who want to buy it can buy now, it those who want to wait can wait. 😀😀
    Where is the problem ?

    Exactly. Releasing now is a no-brainer

  • @fprintf said:
    A key concept in AGILE software development is release early and release often. It is a more modern approach than waterfall which relies on one big release later. Your users get more value from the frequent releases, the users get to be testers and provide feedback (if you want it) and as long as Option 1 doesn't come with a price and what comes in 2.X also has a price, then I'd say do Option 1 at whatever upgrade fee you were planning... and then only make the automation available to those who have the updated Atom 2 and paid your upgrade fee.

    Release early and release often. We do two week sprints.

    I cant argue with that and I follow same practice in my workplace as dev.

    However, in my personal projects I definitely feel this need to "complete" or "perfect" or "reach end-goal" before releasing. I'm not sure its logical or rational and most likely is a more emotional response.

    If the goal is to fulfil a need of the community then it makes sense to make it an iterative process.

  • I think there's also a perspective of what makes the most people happy.

    Releasing option 1 now makes a lot of people happy now.
    At a later date when the version with the automation is released, then all who wanted automation will be happy to have that feature.

    I can't see any reason why releasing option 1 now, should make those who are waiting for option 2 unhappy...
    Because they would have had to wait for option 2 anyway.

    All the people using option 1 now will be happily making music with it, because it serves a music making purpose that is needed now.

This discussion has been closed.