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.

Developing plugins for personal use?

2»

Comments

  • McDMcD
    edited April 2022

    I'd like to follow your guidance into the realm of coding for sound and/or MIDI. I tried to use the forum to expose Mozaic scripting to more members and it was a tricky vehicle for that purpose.

    If I did it again I'd put lessons in the Wiki and then have parallel discussion in a thread for questions, comments and to alert people to new updates in the Wiki content.

    The Wiki would become a core set of instructions, documents and graphics.

    I'm curious to see how you manage this. A series of videos is also a useful option. That might bring in more music production people into the fold here.

  • Yep, I’m definitely interested!

  • Strongly interested!

  • edited April 2022

    @NeonSilicon said:

    @sonosaurus said:
    For those of you who are OK with C++, using JUCE ( https://juce.com ) is a great way to write audio plugins (or apps) without having to deal with the often annoying details of native plugin APIs. You get the bonus of complete cross-platform support with a single codebase as well. It’s open source and dual licensed (GPL and commercial) so you don’t have to pay anything to get started, or if you just want to do something for yourself (or be open sourced).

    I won't be using JUCE if I do go through with this. The licensing won't work for people that use any code that I would write and then want to move it into a commercial iOS project of their own. There would be potential conflicts between what I would license my code as, probably CC by 4.0, and the non-commercial GPL of JUCE.

    Also, I don't really like JUCE and I like their new owners even less.

    I think I will look at using Faust as a starting point and dev tool for some projects.

    Sorry, I think I misread your original post and follow ons… JUCE clearly isn’t the right thing for your project.

  • @NeonSilicon said:
    I think I will look at using Faust as a starting point and dev tool for some projects.

    with Faust It'd be even more interesting!

  • I'm definitely interested.

    And I was also thinking it would be useful to have some sort of "study group" where we journal our progress, and work toward creating more materials for people to learn from.

    I know there's a subforum here for app development, but I would imagine that there will be some "frequently asked questions" or some confusing aspects of AU development that everybody encounters. It would be nice to collect those somewhere. "How to expose AU parameters" or "how to expose the list of presets".

    We could create tutorial apps in addition to the ones Neon Silicon creates, once we develop the skills to do that.

    And perhaps we could post our own ideas, for what a "tutorial app" might contain. MIDI Tape Recorder would be on the more complex side, but what would be the characteristics of the most simple MIDI recorder possible? Which audio instrument, audio effect, and midi effect, would have the fewest lines of code? How does the code differ for a simple, digital low pass filter, versus an analog modeled low pass filter?

    I'm also interested to see what the code for the same program looks like, on different platforms. How would I port an app to Android, or to Windows?

    If the tutorials by @NeonSilicon can get us started with AU development, it would be nice to have an organized list of such questions, even if we can't answer them yet.

    It probably takes literally 100x longer than it could to create a plugin, in any genre. I would imagine that you could probably have with a synth project with a section labeled "oscillator goes here, filter goes here, ADSR goes here" and then you could choose from different algorithms for each one, and just copy and paste blocks of code.

    Maybe in a few years, there could be a tier list for open source algorithms for knob movement, along with info on what each one is best at. Shortest code for a knob algorithm, best code for precise adjustments, best rotary knob, etc.

  • @McD said:
    I'd like to follow your guidance into the realm of coding for sound and/or MIDI. I tried to use the forum to expose Mozaic scripting to more members and it was a tricky vehicle for that purpose.

    If I did it again I'd put lessons in the Wiki and then have parallel discussion in a thread for questions, comments and to alert people to new updates in the Wiki content.

    The Wiki would become a core set of instructions, documents and graphics.

    I'm curious to see how you manage this. A series of videos is also a useful option. That might bring in more music production people into the fold here.

    How to do this is a good question. My tendency is towards textual based tutorials. Video based content for this kind of thing usually slows me down when I'm trying to learn. But, I'm open to what people would be interested in. It's been about 15 years since I produced a video though and even longer since I've taught a class.

  • @sonosaurus said:

    @NeonSilicon said:

    @sonosaurus said:
    For those of you who are OK with C++, using JUCE ( https://juce.com ) is a great way to write audio plugins (or apps) without having to deal with the often annoying details of native plugin APIs. You get the bonus of complete cross-platform support with a single codebase as well. It’s open source and dual licensed (GPL and commercial) so you don’t have to pay anything to get started, or if you just want to do something for yourself (or be open sourced).

    I won't be using JUCE if I do go through with this. The licensing won't work for people that use any code that I would write and then want to move it into a commercial iOS project of their own. There would be potential conflicts between what I would license my code as, probably CC by 4.0, and the non-commercial GPL of JUCE.

    Also, I don't really like JUCE and I like their new owners even less.

    I think I will look at using Faust as a starting point and dev tool for some projects.

    Sorry, I think I misread your original post and follow ons… JUCE clearly isn’t the right thing for your project.

    No problem. Lots of devs use JUCE, so it is definitely something for people to look into when they are considering options.

  • @NeonSilicon said:
    How to do this is a good question. My tendency is towards textual based tutorials. Video based content for this kind of thing usually slows me down when I'm trying to learn. But, I'm open to what people would be interested in. It's been about 15 years since I produced a video though and even longer since I've taught a class.

    Documenting the path in the way that works best for you is so important. Others can create the additional extending content: video, wiki, etc.

    In a very crowded thread I often use the browser page search function to just see the input of a single author and I'll use that to follow along if you decide to deliver your text as a series of comments in a thread.

  • @vasilymilovidov said:

    @NeonSilicon said:
    I think I will look at using Faust as a starting point and dev tool for some projects.

    with Faust It'd be even more interesting!

    Yeah. I really like domain specific languages and the power they can give people to develop their own tools. Faust is really impressive in the breadth of targets you can develop for with it --- from embedded systems to iOS. Thinking ahead, I think a basic background on how to structure an AUv3 to start with and then a some examples using Faust would be a good path. If this plays out well, then some content on resources and how to use these to develop libraries of building blocks would probably be where I headed next.

  • @NeonSilicon said:

    @McD said:
    I'd like to follow your guidance into the realm of coding for sound and/or MIDI. I tried to use the forum to expose Mozaic scripting to more members and it was a tricky vehicle for that purpose.

    If I did it again I'd put lessons in the Wiki and then have parallel discussion in a thread for questions, comments and to alert people to new updates in the Wiki content.

    The Wiki would become a core set of instructions, documents and graphics.

    I'm curious to see how you manage this. A series of videos is also a useful option. That might bring in more music production people into the fold here.

    How to do this is a good question. My tendency is towards textual based tutorials. Video based content for this kind of thing usually slows me down when I'm trying to learn. But, I'm open to what people would be interested in. It's been about 15 years since I produced a video though and even longer since I've taught a class.

    I don't care much about the form of the tutorials. But I'd suggest having everything on github, even if there are discussions about it here on ABF. Seems more likely to expand scope of helpfulness when interested people find it on github by a web search rather than ABF. Plus the seamless way code is handled on github. Ideally, the discussions could be part of the 'Issues' thread on github, even if just duplicating what happens here. Or maybe just links from github to discussions here.

  • @hes said:

    @NeonSilicon said:

    @McD said:
    I'd like to follow your guidance into the realm of coding for sound and/or MIDI. I tried to use the forum to expose Mozaic scripting to more members and it was a tricky vehicle for that purpose.

    If I did it again I'd put lessons in the Wiki and then have parallel discussion in a thread for questions, comments and to alert people to new updates in the Wiki content.

    The Wiki would become a core set of instructions, documents and graphics.

    I'm curious to see how you manage this. A series of videos is also a useful option. That might bring in more music production people into the fold here.

    How to do this is a good question. My tendency is towards textual based tutorials. Video based content for this kind of thing usually slows me down when I'm trying to learn. But, I'm open to what people would be interested in. It's been about 15 years since I produced a video though and even longer since I've taught a class.

    I don't care much about the form of the tutorials. But I'd suggest having everything on github, even if there are discussions about it here on ABF. Seems more likely to expand scope of helpfulness when interested people find it on github by a web search rather than ABF. Plus the seamless way code is handled on github. Ideally, the discussions could be part of the 'Issues' thread on github, even if just duplicating what happens here. Or maybe just links from github to discussions here.

    Definitely. I've got the two demo projects I've done for AUv3's up on GitHub already and I'll put the code for the projects there. I've been thinking about using GitHub Pages to do the written documentation. That's another point where I'm not clear on how to link in video content to the overall concept. I think I've got to learn a bit

  • @Skyblazer said:
    I'm definitely interested.

    And I was also thinking it would be useful to have some sort of "study group" where we journal our progress, and work toward creating more materials for people to learn from.

    I know there's a subforum here for app development, but I would imagine that there will be some "frequently asked questions" or some confusing aspects of AU development that everybody encounters. It would be nice to collect those somewhere. "How to expose AU parameters" or "how to expose the list of presets".

    We could create tutorial apps in addition to the ones Neon Silicon creates, once we develop the skills to do that.

    And perhaps we could post our own ideas, for what a "tutorial app" might contain. MIDI Tape Recorder would be on the more complex side, but what would be the characteristics of the most simple MIDI recorder possible? Which audio instrument, audio effect, and midi effect, would have the fewest lines of code? How does the code differ for a simple, digital low pass filter, versus an analog modeled low pass filter?

    I'm also interested to see what the code for the same program looks like, on different platforms. How would I port an app to Android, or to Windows?

    If the tutorials by @NeonSilicon can get us started with AU development, it would be nice to have an organized list of such questions, even if we can't answer them yet.

    It probably takes literally 100x longer than it could to create a plugin, in any genre. I would imagine that you could probably have with a synth project with a section labeled "oscillator goes here, filter goes here, ADSR goes here" and then you could choose from different algorithms for each one, and just copy and paste blocks of code.

    Maybe in a few years, there could be a tier list for open source algorithms for knob movement, along with info on what each one is best at. Shortest code for a knob algorithm, best code for precise adjustments, best rotary knob, etc.

    Great ideas! A list of resources that included information for development of algorithms and open source projects could go a long way towards helping people progress. https://github.com/gbevin/MIDITapeRecorder has already been mentioned. Another is the source from @chowdsp at https://github.com/Chowdhury-DSP. There are lots of others that aren't specific to AUv3 but could be very useful too.

  • Synths or effects first?

    Note: I've never done a plugin synth before, guess I'd have to learn along the way too.

  • “Developing plugins for personal use…”

    That’s kinda how I describe what I’m doing in Drambo every day :D

  • @tk32 said:
    “Developing plugins for personal use…”

    That’s kinda how I describe what I’m doing in Drambo every day :D

    Absolutely and in many ways that's a better path. If iOS allowed for Drambo to enable importing of custom built modules, I'd focus on that path. If Apple allowed for JIT enabled processing, I'd be working on an AU that let people run Faust programs in an AU.

    I'm a strong believer in the idea that a computing device only reaches its potential when people can program the device to do what they want it to do. I love domain specific languages for how they enable people to program their devices. Drambo is great in this regard.

  • The user and all related content has been deleted.
Sign In or Register to comment.