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.

The guide to beta testing iOS music apps.

edited April 2021 in Knowledge Base

Hi all. There's quite a lot of talk about this subject here and yet there doesn't seem to be a repository of knowledge about the basics. I'll add some links to beta testing and, hopefully, we can push forward the knowledge and practises surrounding this subject with input from those on here who feel they have something to add.

Testing apps with Testflight.

The Beginner's Guide to iOS App Testing

The Complete Guide to Beta-Testing your iOS App

Comments

  • This is going well.

  • edited June 2021

    A couple of tips.

    Don’t demand.
    Be patient.

    Be careful of usage of language when communicating with dev’s.
    Some can be a little bit sensitive.
    For some it is understandable taking into account
    intellectual property rights etc, etc and all that.

    If you’re an artist learn the tech vocabulary, very important.
    What seems perfectly normal language for you could well be insulting for someone else.

    Once you are on the beta team, play it cool.
    Don’t holla out on the forums every new thing that is being
    developed unless the dev would like you to do so but
    don’t try and read the dev’s mind, ask permission first.

    Be curious.

    Be prepared to have differing points of view and also be prepared
    to occasionally go head to head with other beta testers.

    It’s not all roses.

    Other than that, it is a very fun to thing do. 😏

  • @ashh said:
    This is going well.

    :lol: i'm sorry it passed unnoticed before.
    This is good knowledge you guys shared

    I think beta-testers can try to think out of their box too.
    Gonna use myself as an example. In VS I would probably always use it synced to the host tempo. But I think the internal tempo could use tap tempo if someone was doing live visuals for a sound source provided by another person.

    So it's something I would barely use, but it could be really useful to others

  • edited June 2021

    I just always test my set of use cases for stability and fiddle with every feature I can find for at least a couple minutes to check for bugs. I don’t go above and beyond trying to break it with esoteric usage cases or see if I can load 40 instances or whatever, but I also don’t ever request features that I want. The only thing I will respectfully provide input on if there’s no bugs (unless specifically requested) is the visuals—UI layout or colors. The rest is under the hood stuff that’s none of my business.

    I usually only have one or two going at a time, but I really like doing it because it prods me to finish at least one full track using it; gives me an “excuse” to stop procrastinating.

  • Cheers! Always a good reminder

  • @Gravitas said:
    A couple of tips.

    Don’t demand.
    Be patient.

    Be careful of usage of language when communicating with dev’s.
    Some can be a little bit sensitive.
    For some it is understandable taking into account
    intellectual property rights etc, etc and all that.

    If you’re an artist learn the tech vocabulary, very important.
    What seems perfectly normal language for you could well be insulting for someone else.

    Once you are on the beta team, play it cool.
    Don’t holla out on the forums every new thing that is being
    developed unless the dev would like you to do so but
    don’t try and read the dev’s mind, ask permission first.

    Be curious.

    Be prepared to have differing points of view and also be prepared
    to occasionally go head to head with other beta testers.

    It’s not all roses.

    Other than that, it is a very fun to thing do. 😏

    Niceness! Tyvm.

    Ty all for your contributions. :)

    I was hoping to get a dev or 2 to contribute. Imma ask @brambos because I have all your apps and you are my favourite dev. What is the top top thing you need from a beta tester? After actually using the app and getting back to you lol.

  • @ashh said:

    @Gravitas said:
    A couple of tips.

    Don’t demand.
    Be patient.

    Be careful of usage of language when communicating with dev’s.
    Some can be a little bit sensitive.
    For some it is understandable taking into account
    intellectual property rights etc, etc and all that.

    If you’re an artist learn the tech vocabulary, very important.
    What seems perfectly normal language for you could well be insulting for someone else.

    Once you are on the beta team, play it cool.
    Don’t holla out on the forums every new thing that is being
    developed unless the dev would like you to do so but
    don’t try and read the dev’s mind, ask permission first.

    Be curious.

    Be prepared to have differing points of view and also be prepared
    to occasionally go head to head with other beta testers.

    It’s not all roses.

    Other than that, it is a very fun to thing do. 😏

    Niceness! Tyvm.

    Ty all for your contributions. :)

    I was hoping to get a dev or 2 to contribute. Imma ask @brambos because I have all your apps and you are my favourite dev. What is the top top thing you need from a beta tester? After actually using the app and getting back to you lol.

    Well, the best way to make a dev happy is to explain how to reproduce problems. When you run into a problem, retrace your steps and see if you can make the same thing/crash/weirdness happen again. That info will save a developer literally many hours of work. :)

  • @brambos said:

    @ashh said:

    @Gravitas said:
    A couple of tips.

    Don’t demand.
    Be patient.

    Be careful of usage of language when communicating with dev’s.
    Some can be a little bit sensitive.
    For some it is understandable taking into account
    intellectual property rights etc, etc and all that.

    If you’re an artist learn the tech vocabulary, very important.
    What seems perfectly normal language for you could well be insulting for someone else.

    Once you are on the beta team, play it cool.
    Don’t holla out on the forums every new thing that is being
    developed unless the dev would like you to do so but
    don’t try and read the dev’s mind, ask permission first.

    Be curious.

    Be prepared to have differing points of view and also be prepared
    to occasionally go head to head with other beta testers.

    It’s not all roses.

    Other than that, it is a very fun to thing do. 😏

    Niceness! Tyvm.

    Ty all for your contributions. :)

    I was hoping to get a dev or 2 to contribute. Imma ask @brambos because I have all your apps and you are my favourite dev. What is the top top thing you need from a beta tester? After actually using the app and getting back to you lol.

    Well, the best way to make a dev happy is to explain how to reproduce problems. When you run into a problem, retrace your steps and see if you can make the same thing/crash/weirdness happen again. That info will save a developer literally many hours of work. :)

    Cool! Such a helpful tip. Tyvm!

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

    Agree with everything @winconway said.

    Plus here are a few of my own...

    • Please don't pester the dev constantly. Compiling a collection of bugs/suggestions into a well-written summary is much more helpful than short-burst stream-of-consciousness DMs and @ mentions.
    • It's not cool to boast about the fact you are on the beta. Play it cool and try to remain anonymous. This process is not about YOU.
    • During the beta you may be tempted to get into debates about the app (and how it works) on this forum. Try to not reply impulsively and instead, discuss the right tone and approach with the dev. It is not your job to be a spokesperson for the app or to defend design decisions or missing features.
    • Ask the dev if you can contact other beta testers and work as a group. Setting up a kanban board (e.g. Trello) can be an extremely helpful way to collaborate on testing. It means all testers can confirm (or deny) suspected bugs, and also avoids lots of duplicated messages about the same issues.
  • and remember that English isn't everyone's first language.

  • @brambos said:

    @ashh said:

    @Gravitas said:
    A couple of tips.

    Don’t demand.
    Be patient.

    Be careful of usage of language when communicating with dev’s.
    Some can be a little bit sensitive.
    For some it is understandable taking into account
    intellectual property rights etc, etc and all that.

    If you’re an artist learn the tech vocabulary, very important.
    What seems perfectly normal language for you could well be insulting for someone else.

    Once you are on the beta team, play it cool.
    Don’t holla out on the forums every new thing that is being
    developed unless the dev would like you to do so but
    don’t try and read the dev’s mind, ask permission first.

    Be curious.

    Be prepared to have differing points of view and also be prepared
    to occasionally go head to head with other beta testers.

    It’s not all roses.

    Other than that, it is a very fun to thing do. 😏

    Niceness! Tyvm.

    Ty all for your contributions. :)

    I was hoping to get a dev or 2 to contribute. Imma ask @brambos because I have all your apps and you are my favourite dev. What is the top top thing you need from a beta tester? After actually using the app and getting back to you lol.

    Well, the best way to make a dev happy is to explain how to reproduce problems. When you run into a problem, retrace your steps and see if you can make the same thing/crash/weirdness happen again. That info will save a developer literally many hours of work. :)

    Yea I try to give details about everything.

  • edited June 2021

    Also, while we're on the whole subject of how to communicate with devs (yes we are!) then I'd like to say how much it makes me cringe when a new app is about to be released, the dev proudly steps out from behind the curtain with a triumphant Ta..... DAAA! and the first voice that speaks up is like "needs more cowbell."

    I am not into telling others what they can and cannot say or do. Not one bit. If you're living your life one way and I don't like it, who am I to tell you about your bad self? No one. But I just wanted to say this. I honestly feel like I can see the dev, with their ice cream cone of appness clutched in their hand, looking at their lovely chocolate ice cream that's just been splatted on the floor and feeling like crying when something like that happens. So please, just, I dunno, have a heart? Or something.

    Lu u x

  • None of it is personal... you comment, because you care, or at least trying to...

  • @0tolerance4silence said:
    None of it is personal... you comment, because you care, or at least trying to...

    Exactly this.

    Be supportive.

  • If you’re going to post a feature request (especially an exotic one which potentially only fits your own workflow), try to explain your use case and ask nicely.

    One-word posts like “Slicer?” or “Ableton Link?” are immensely annoying and lazy and do nothing to support your cause. :)

    So is a passive-aggressive “Am I missing something?” when it’s clear that a feature was consciously left out.

    Keep in mind that a large part of the product management task is to come up with a balanced feature set while avoiding feature creep. You can be certain that the dev didn’t stupidly forget about your feature, but had reasons for deciding against it. Feature creep is the devil ;)

  • edited June 2021

    @brambos said:
    If you’re going to post a feature request (especially an exotic one which potentially only fits your own workflow), try to explain your use case and ask nicely.

    One-word posts like “Slicer?” or “Ableton Link?” are immensely annoying and lazy and do nothing to support your cause. :)

    So is a passive-aggressive “Am I missing something?” when it’s clear that a feature was consciously left out.

    Keep in mind that a large part of the product management task is to come up with a balanced feature set while avoiding feature creep. You can be certain that the dev didn’t stupidly forget about your feature, but had reasons for deciding against it. Feature creep is the devil ;)

    Cool cool.

    Feature creep. Never thought about it much but I have thought that if I made an app it would be all about focus. Like, what do I want? What does everyone else want? What can I do well? I don't like apps that have dead ends. Like, you can see that they implemented something and just left it dangling out there, tbc.

    Ok, so with me and being in a beta, I've opened the app, done something with it, everything has gone well, I've closed it and then I'm sat there thinking "should I have told them something?" Like, I don't use any app a lot. I'm always dipping into one then another etc. I kind of feel like, if I'm in a beta then I have a responsibility to feed back but quite often I don't have anything to feed back and then I think maybe I shouldn't be a beta tester for it because they're getting nothing from my involvement. Do you see what I mean? Beta guilt. It's fo' real.

    Oh and I'm on a forum that is kind of a community thing, been my main forum for over 20 years and someone mentioned Hammerhead. They used to use the one that fitted on a floppy. Felt good to see it out there.

  • edited June 2021

    @ashh said:

    @brambos said:
    If you’re going to post a feature request (especially an exotic one which potentially only fits your own workflow), try to explain your use case and ask nicely.

    One-word posts like “Slicer?” or “Ableton Link?” are immensely annoying and lazy and do nothing to support your cause. :)

    So is a passive-aggressive “Am I missing something?” when it’s clear that a feature was consciously left out.

    Keep in mind that a large part of the product management task is to come up with a balanced feature set while avoiding feature creep. You can be certain that the dev didn’t stupidly forget about your feature, but had reasons for deciding against it. Feature creep is the devil ;)

    Cool cool.

    Feature creep. Never thought about it much but I have thought that if I made an app it would be all about focus. Like, what do I want? What does everyone else want? What can I do well? I don't like apps that have dead ends. Like, you can see that they implemented something and just left it dangling out there, tbc.

    Ok, so with me and being in a beta, I've opened the app, done something with it, everything has gone well, I've closed it and then I'm sat there thinking "should I have told them something?" Like, I don't use any app a lot. I'm always dipping into one then another etc. I kind of feel like, if I'm in a beta then I have a responsibility to feed back but quite often I don't have anything to feed back and then I think maybe I shouldn't be a beta tester for it because they're getting nothing from my involvement. Do you see what I mean? Beta guilt. It's fo' real.

    My response was not specifically about betas, but more about posting on a forum or emailing directly. I understand everybody focuses mostly on their own workflow, but as a dev/designer you have to make sense out of those hundreds of possible workflows and come to a 80/20 design that covers as much as possible without becoming a complicated mess :)

    The other day I received a rant-style email about some details in my design. No salutation and ending with "Did I make my point?". Obviously such emails go straight into the trash as I value polite and human communication above all else ;)

    When you're on a beta, even a quick message saying that you used the app/beta a bit and didn't find any quirks or problems is helpful. In fact, such messages are very welcome B)

  • I tend to keep my beta interactions to tech stuff, report bugs etc and only get into feature stuff if asked. Strangely though, I have found myself making uninvited feature requests publicly post release and I realise how annoying that must be, so I’m trying to not do that anymore 😁

Sign In or Register to comment.