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.

How Difficult is it to Develop a Musical App?

2

Comments

  • @benkamen said:
    Thanks @brambos, I've come across Bessel functions two dozens times and still don't understand them :) My approach with synthesis has so far been band limited wavetables, and simply choosing the correct wavetable based on what I think the maximum frequency will be. With standard synths this is easy (pitch + pitch bend range), but with FM, I'd have to modulate through different bandlimited wavetables very fast and I can't quite wrap my brains around that one yet. Not even sure if that would work, actually.

    Ah, that last part just made sense to me..... one could conceivablely make a crazy additive sine wave bank and modulate each oscillator! And you'd probably need hundreds or thousands of sine waves per voice! Yikes.

    Disclaimer: I haven't tried the following and these are just the ramblings of a designer who isn't supposed to be talking about physics...

    Anyway, you could probably get away with it in a "simpler" way. You can use the Bessel functions to predict the frequencies that will result from a certain frequency modulation. Once you know these frequencies you can cut away anything above Niquist and perform an Inverse Fourier Transform on the resulting spectrum.

    The output should then be a perfectly band limited signal.

    Still pretty complicated but at least you won't have to tinker with a bazillion wave tables :smiley:

  • one thing that's not difficult, is imagining a new app

  • @brambos said:

    @benkamen said:
    Thanks @brambos, I've come across Bessel functions two dozens times and still don't understand them :) My approach with synthesis has so far been band limited wavetables, and simply choosing the correct wavetable based on what I think the maximum frequency will be. With standard synths this is easy (pitch + pitch bend range), but with FM, I'd have to modulate through different bandlimited wavetables very fast and I can't quite wrap my brains around that one yet. Not even sure if that would work, actually.

    Ah, that last part just made sense to me..... one could conceivablely make a crazy additive sine wave bank and modulate each oscillator! And you'd probably need hundreds or thousands of sine waves per voice! Yikes.

    Disclaimer: I haven't tried the following and these are just the ramblings of a designer who isn't supposed to be talking about physics...

    Anyway, you could probably get away with it in a "simpler" way. You can use the Bessel functions to predict the frequencies that will result from a certain frequency modulation. Once you know these frequencies you can cut away anything above Niquist and perform an Inverse Fourier Transform on the resulting spectrum.

    The output should then be a perfectly band limited signal.

    Still pretty complicated but at least you won't have to tinker with a bazillion wave tables :smiley:

    Or you could just oversample.

  • @cian said:
    Or you could just oversample.

    For single operator FM that may do it, but if you go 4 OP or 6 OP I'm not sure oversampling would be enough. Those frequencies get pretty wild.

    But I could be wrong, of course. o:)

  • @db909 said:
    one thing that's not difficult, is imagining a new app

    True that!
    That's why I sometimes let my imagination run wild and type 'fairy-tales' like the WeirdOSC thing :D

  • @bri77 said:
    Great thread. What about Audiokit? Does this help make things easier?

    http://audiokit.io/features/

    @bri77 I am working on creating an Audiokit based app now. Audiokit is well made, but I believe if my app gets really complex, I may still have to roll my own custom DSP code.

  • Just came across this on the A Tasty Pixel blog:

    If you’re interested in the technical details around how music apps get made, this is an excellent talk by music technologist Greg Cerveny on creating music apps. He’s interviewed a bunch of developers (including the developers of Patterning, Fugue Machine, Elastic Drums, and me) about their process and their background, and these are the results. Worth a watch!

  • @ElderX said:

    @bri77 said:
    Great thread. What about Audiokit? Does this help make things easier?

    http://audiokit.io/features/

    @bri77 I am working on creating an Audiokit based app now. Audiokit is well made, but I believe if my app gets really complex, I may still have to roll my own custom DSP code.

    Speaking of A Tasty Pixel, Michael suggests that "99% of people should be using Audiokit anyway" on his TAAE2 retirement notice.

  • https://arielelkin.github.io/articles/mandolin.html

    Maybe helpful as first step to eat the elephant.

  • Great thread this, loads of useful links. Food for thought...

  • Speaking of A Tasty Pixel, Michael suggests that "99% of people should be using Audiokit anyway" on his TAAE2 retirement notice.

    @syrupcore It was actually the TAAE2 retirement notice that led me to Audiokit. It was the right info at exactly the right time.

  • I'd have to do the math to be sure but I feel 8x would cover it. The outer bands don't have a lot of power.> @brambos said:

    @cian said:
    Or you could just oversample.

    For single operator FM that may do it, but if you go 4 OP or 6 OP I'm not sure oversampling would be enough. Those frequencies get pretty wild.

    But I could be wrong, of course. o:)

    I'd have to do the math to be certain, but my gut feel is that 8x would be plenty. Anything that went over the 8x limit would probably end up in the noise floor anyway. If that didn't work, you could always combine it with a more gentle version of the Yamaha trick.

    Maybe Faust will finally have a version that can do oversampling and I can try it out :smile:

  • @brambos said:
    Making something that produces sound is probably not too hard (altough quite a bit harder than making a website with a Wordpress template).

    Making a decent music app is really hard. There are a couple of things you need to master:

    • Programming the app (the basic framework of an app, coding the UI behavior and handling of user interaction). Ideally done in Objective-C, mixed with lots of C/C++ for the realtime audio bits. Swift is not yet a real option since most low-level frameworks are still built around (Objective-)C. Also, you need to be good at optimizing code in really clever ways if you have any hopes of doing stuff in real time with low latency.

    • DSP: generating and manipulating sound. Nothing about this is easy. If something seems simple, you're probably doing it wrong and soon you're in for a world of aliasing and distortion :D Lots of physics and maths involved here. Be prepared to put lots of hours into studying highly arcane aspects of physics and signal theory and brushing up on your trigonometry. Again, knowing the physics is not enough. You need to be able to build your DSP code so efficiently that it can be run in realtime without cutting corners wrt sound quality. You and Mr. Niquist are going to be very close friends.

    • Design: underestimated by many app developers. It can be the little things that make or break a workflow. And that's before you even get into the aesthetics, established interaction design patterns and how to deal with device fragmentation. Particularly hard on iOS because no two workflows are the same and people expect you to consider even the most obscure use cases of how your app will be used in conjunction with a chain of other apps.

    • The crazy intricacies of low level audio tech, i.e. CoreAudio, AudioUnits, CoreMidi, Ableton Link, etc. Many aspects of this are barely documented and need to reverse engineered by looking at C header files and labyrinthine sample code. Sometimes bugs in the OS (or third party libraries/apps) will have you pulling out your hair for days. And you have to understand low-level system stuff like threading priorities and locking to make sure your fancy GUI doesn't clash with realtime audio processing causing inexplicable glitches and clicks.

    Sorry if this sounds off-putting, but there really is nothing easy about it if your ambition is to go beyond the point of an app that just plays a WAV file when you press a button on the screen B)

    If you've already covered some of the above to some extent you have a pretty good starting point, however, and everything can be learned if you put your heart into it. If you're starting from scratch I would recommend beginning with something a bit simpler. :)

    @brambos, thanks for your insights. I have c/c++ experience, but never looked into objective-C/swift. How easy is to learn objective-C if you already know C? I was planning to learn swift as this is supposed to be the future w.r.t ios programming ...so are you saying we really can't do any audio/music stuff in swift?

    Is there any common libraries/API's for general music related stuff that we can just re-use?

    I was wishing someone made an app - that can simulate orchestral instrument articulations..like take two or more violin samples and process them to produce a legato or any other.
    FingerFiddle app uses physical modelling..if only they could combine actual samples + modelling , the o/p would be more realistic.

  • I think that Swift is a interesting language, but i am not that sure it is a good choice for programming DSP processes. It seem to be a kind of a "objective c with some additional features". That does not neccessarily mean it is better for learning. More methods and options usually have the outcome that there is more to learn. Swift code can get very compact and short - and quite complex.

    Macmark is quite skeptical about Swift:

    (sorry: links are in German language)

    http://www.macmark.de/dev/osx_dev_swift_flight.php
    http://www.macmark.de/dev/osx_dev_swift_check.php

    Hint: My last code is more than 20 years old (and i was really bad at coding - but i have loved "Modula 2"). Now i think about learning programming again and i am looking for a good, modern language, too.

  • How much actual DSP is necessary these days, that hasn't already been done?

  • Interestingly, that mentions SAOL, which is actually part of MPEG-4, and this particular part of the MPEG-4 specification is something I've always found quite intriguing https://en.m.wikipedia.org/wiki/MPEG-4_Structured_Audio - nothing came of that, it seems.

  • @u0421793 said:
    How much actual DSP is necessary these days, that hasn't already been done?

    They even have some audio programming languages based upon stacks like Forth such as Sporth.

  • @InfoCheck said:

    @u0421793 said:
    How much actual DSP is necessary these days, that hasn't already been done?

    They even have some audio programming languages based upon stacks like Forth such as Sporth.

    Yes, I was looking at that again the other day. FORTH is the first language I learned (and arguably, the only I ever understood, if you count PostScript as a FORTH). SPORTH is something I intend to set up on a Raspberry Pi (my Pi is at present tucked away behind a cupboard, wifi connected, and running Wordpress on nginx as my theme development test server, so really should get another).

    SPORTH, however, begets this: http://audiokit.io/playgrounds/Synthesis/Sporth Based Generator/

  • @u0421793 said:

    @InfoCheck said:

    @u0421793 said:
    How much actual DSP is necessary these days, that hasn't already been done?

    They even have some audio programming languages based upon stacks like Forth such as Sporth.

    Yes, I was looking at that again the other day. FORTH is the first language I learned (and arguably, the only I ever understood, if you count PostScript as a FORTH). SPORTH is something I intend to set up on a Raspberry Pi (my Pi is at present tucked away behind a cupboard, wifi connected, and running Wordpress on nginx as my theme development test server, so really should get another).

    SPORTH, however, begets this: http://audiokit.io/playgrounds/Synthesis/Sporth Based Generator/

    Yes, it seems all of these audio programming languages find their way into the tool box of developers who create iOS apps as well as other platforms like the Pi.

  • Openframeworx anyone?

  • edited March 2017

    Well that certainly caught my eye.

  • @paradiddle said:
    Well that certainly caught my eye.

  • Thank you @nrgb Awesome!

  • writing interesting new DSP code without real understanding of (sound)wave physics and signal processing math is impossible, but today there are many resources for the most optimized versions of classical DSP code snippets for getting something together without all the math. Still, getting a DSP pipeline to work in practice needs at least some deeper understanding and experience (real-time multi-threaded programming is very different than lets say online services programming).

    I would guide to start with a single small app/plugin for something that is more about few features and style rather than about structure and optimization. For beginning I would advice using RtAudio or JACK for the first dsp engine. They are much easier than diving straight ahead into the cryptic world of core audio. As for programming language.. most imperative ones work equally good but most resources are found for C/C++, usually the standard for DSP code along with matlab (usually used for more mathematical stuff). More important is where the code is going to run and how.

    From my experience in music technology and software development I would say.. first the most difficult phase is to gain understanding of real-time digital audio, driver callbacks and basic dsp math and to work out some kind of input & output machine that works as wanted.. lets say a simple oscillator with envelope, or a sample/mp3 player. A lots of try-and-fail here depending on background but after getting the hang of that, it is not very hard to write small dsp programs. Like my signal processing professor said: "DSP is not hard, it's just really complex:"

    With that basic understanding it's easy to re-use and re-factor one's own dsp codes to build new things while improving the code base. The real difficulty or the price in the field is producing some new dsp math or making wild new implementations of old ones - practically a career scientist thing to do. Code optimization is also very important to master so some average level programming skills are welcome. Ultimately the biggest job as in work hours is the reality of writing creativity software for other people to enjoy or find useful. It includes everything from the first design sketches to large scale testing and user feedback and going back and forth. Many non-technical musical people are needed to have fresh ear for sound and inspiration for user experience which all can go astray with too closed development.

  • Another thing that is remotely related: how big is the possible market for great, but advanced (read musician) apps? An advanced synth? A DAW? A multi-effects unit? I'm talking about "our" apps, not the "apps-for-the-masses" type of apps now, but often rather serious instruments or music creation tools.

    I mean, I have literally no idea about volumes. I don't know if they sell 10, 100, 1000, 10000 or 100000+ units.
    Just looking at the BM3 page, it looks like there are roughly 1800 people currently signed up on their e-mail list. If we say 75% of those actually will purchase it, and another 50% on top who haven't bothered signing up, still will purchase it (just grabbing these numbers unscientifically out of the air).
    1800 x 0.75 = 1350 people on the list will purchase. 1350 + 1800 / 2 = 2250 people.
    If we assume the price will be $40: 2250 x $40 = $90k.
    Then Apple cuts its share (30%): $63k left.

    Now, I hope my assumed numbers are horribly wrong, otherwise I don't see how BM3 alone can feed that many people (and their families) on $63k, especially over many years (looking at BM2 release date).

    If you are a solo developer and you develop an app that'll cost say $20 and you'll sell it to 1000 people = $20k - 30% (Apple) = $14k. Hardly a great annual salary, and you probably wouldn't get it up front anyways. So you'd need to either sell more units, or start making more products in the hope that selling more units overall...but that obviously also comes with an increase in support needed etc.

    Just saying, unless there is a huge hidden number of potential buyers for advanced music apps, I think there are probably other, quicker, routes to richness and fame. I think many devs of "our" apps are doing it for the love of music and a passion of creating something new, but I wouldn't be surprised if they have other jobs on the side.

    Then again, when I look at the give aways on musicappblog.com I rarely recognise the names of the winners, despite having been in this "community" both here and on Facebook, for years, so maybe there is a huge hidden number in the target audience that I just don't see...?

  • I have no idea how big the full market is, but you can see the different magnitudes by looking at e.g. Facebook groups.

    The iPad Musicians group has just over 5000 followers. Native Instruments alone has 240000 followers :-D

  • edited March 2017

    A (really good) developer once told me that demo requests result in less than 5% of sales.
    Some folks just ask out of curiosity, many will wait for the crack and only a few actually buy.
    Apples store model worked quite well in the beginning when it was a 'fire and forget' action.
    Since customers demand proper service for less than low budgets it's plain bullshit, except under the aspect to shrink the market into the direction of (some) big players.
    Regarding DSP code I can only tell that I'm (recently) really surprised about some stuff that's almost 20 years old (digging through some ProTools TDM mess under classic MacOS that I happened to aquire for a few bucks some time ago).
    I also have a Sharc DSP based system from early 2k years. Most of that stuff still outperforms VST native implemenations.
    In other words: code quality really matters (still) ;)

Sign In or Register to comment.