Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
How Difficult is it to Develop a Musical App?
A very subjective question, I know. But I'm curious. Obviously much of this answer depends on the complexity of the app being dedigned. I imagine it's very complicated, time consuming, etc. Probably requires formal education to some extent with a background in programming.
That being said, I honestly have no idea. I was recently surprised at how simple it was to produce a (very basic) website for a local school in a couple hours using a template. Perhaps there are similar templates for app design that make the process less intimidating than it seems?
For starters, how difficult/time consuming is it to design an extremely simple piano app? Just a piano keyboard that makes basic piano sounds?
Which "add-ons" dramatically increase the difficulty factor? For example, adding a "record" function, adding a metronome, adding additional sound banks, etc.
Is this something that can be learned through an extensive online course or two? Or is this super complicated stuff that takes years to learn? Seems to me the latter.
Comments
It depends on what you are trying to do. For iOS, you code in xcode, a development environment that runs on Mac. You write in Objective-C, the original language for iOS, or swift. There is a lot of basic stuff built in to help with standard tasks; control widgets such as sliders and switches are part of the platform. With a piano app you could do it very simply. Get a graphic of piano keys, and when you tap on a particular key, play an mp3 of that note. Once you got the basics of xcode, that would be relatively simple. Then comes all the details. How long do you want to sustain the note? How do you want to cut it off? Do you want different piano sounds, our to throw in organ? Do you want pedals? Etc., Etc. It takes years to become a very proficient programmer; I work worth amazing people who do very cool things. But starting to learn, and mucking with it is easy, as all the tools are free, if you already have the computer. Tons of tutorials as well.
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
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
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.
Well, you have one more Phasemaker user in Spain now.
Hello world.
@brambos your post is incredibly generous. If I understood correctly, my dreams of writing a revolutionary neural network phase vocoder, aren't easily achievable?
I can't imagine you can learn all this program languages from scratch without proper education.
To counterbalance with a slightly more encouraging suggestion: I would start with a MIDI app because that would get the nasty real-time DSP out of the equation and be a more gentle introduction into the world of iOS music.
Still not trivial, but a more realistic goal for a novice project
Thank you very much for sharing all of that, and for preventing me from wasting a colossal amount of time. I'll go back now to using apps instead of pretending I have any chance of ever developing one, and working on "Spacefrog", an instrumental track featuring an incredible app called Troublemaker.
I'm going to play devil's advocate to Bram's (as ever) excellent post: Pretty much anyone here will tell you that Bram's app are 'a step above'. Yes, it's going to take you a very very long time to be able to produce something as clean, efficient, handsome sounding and easy to use as any one of his apps. Shit, look how long it took him and he's obviously a clever bird!
A basic delay, flanger or distortion effect though? Probably a lot easier. The guts of the C/C++ code for the core DSP algorithms are out there. Sort out how to wire it up. Then add stuff. If I'm not mistaken, this is how Holderness got started! For sure, the somewhat obtuse notion of 'a good flanger' will likely not come from pulling a repo on github. But it can get you started if you're interested. A little more complicated but not in the Phasemaker realm: a basic VA subtractive synth. One OSC, a LPF and an envelope where the pitch of the osc is mapped to a keyboard. There are tutorials out there for this. And these days you can cook one up with Javascript. Will not be of much practical use on iOS but the core concepts are the same and you can learn on any OS without needing to deal with compilers.
Like you mentioned, the answer is very much 'it depends'. And to a core part of what I took from Bram's post, it depends on the goal. Do you want to sell iOS music apps with some reasonable volume? If so, see above. If you just wanna make stuff though, it's really just up to you and how much time you have.
Also, for inspiration: Drum Perfect (not pro) was Marinus' first time coding.
I have a few self taught friends who make a living programming quite complex apps. It can be done but it requires an obsessive streak for sure, which they all share.
^ good advice from Syrupcore. Again, I don't want to sound negative.
The biggest trick is to learn how to eat an elephant: in many tiny little bites
In other words: learn how to break down the project into a collection of many small problems that need to be solved one by one. It will make the learning curve more manageable and rewarding as it will give you a long chain of gratifying victories 
I have enough awareness to know that @brambos is not exaggerating in the slightest about the challenges of creating iOS music creation apps and if anything he makes it seem easier than it actually is. Out of curiosity I've looked at some iOS coding examples and even the simplest of tasks requires a long series of steps in a chain where any mistake results in failure. Developing an app is definitely something I'm thankful other people have the time, knowledge, skills, and commitment to do.
Working with modular apps such as Audulus or Pd is about as deep as I want to go towards programming my own sounds.
There are self-taught coders out there but you have to have an aptitude for it and be willing to put in much effort.
Thanks to the internet there are a ton of resources to mine.
But, I believe really effective software engineers all share a similar mindset an ability to logically breakdown and analyse functional requirements.
In short it will take a ton of time and dedication whatever your educational background.
I tried programming back in the early 80s when everyone else quite irritatingly was able to do it better than I could. I learned FORTH, which finally enabled me to write programs that actually did something instead of nothing. It didn't really catch on as well as I anticipated. I'd prefer it if it came back.
All the cool kids were learning COBOL man.
Well, they were incorrect, weren't they. One trick pony that turned out to be - only good for Y2K contracting.
AMOS 4evr
I'll give you all a good Sunday Night/Monday Morning laugh
I'm not a programmer but I can come up with sketches/crazy ideas.
This is something I thought of last night when I couldn't get any sleep...
It's just a 'oscillator' I call it WeirdOSC. It would need modulation sources(LFOs, Step-Sequecer, Envelope) and other stuff to make it shine. If anyone feels tempted to 'materialise' it just go ahead...
WeirdOSC V0.0.1
One 'WeirdOSC' Consists of an added, subtracted or multiplied combination of two types of 'Ramps'.
Output Level for WeirdOSC is set on the 'sum' of the 'ramp combination'.
All 'WeirdOSC Paramaters' should be freely modulate-able/adjustable all time.
For the each of of 'Ramps' in a WeirdOSC the following can be set.
Ramp Type
Ramp (1 Cycle)
Ramp Up&Down/Triangle (2 cycles, 1 up & 1 down)
(One octave lower than regular 'Ramp' due to 2 cycles).
Relative pitch/fine-tuning
The second ramp can optionally 'reset' it's 'start-phase' when ramp one completes it's cycle.
By default both ramps start at the phase set for each of the ramps.
EOF
Nah, I got you all beat. WAY back in highschool, My dad and I wrote a program in basic that fit all the band members with uniforms. It did take all year, but we did it, lol! You will note I have never developed for IOS - or anything else!
BASIC? Pah, come back to me when you've got some assembly language under yer belt.
Or have keyed in a game from a magazine and have it actually work.
Or, more elite yet, have managed to get through a modern Visual Studio development session without the frigging thing crashing AGAIN.
I fear I am off-topic. I am on the Monday commute in so a need a little rant ...
Interesting posts. Ive just recently (3 mnths) got back into writing code after 20 odd years and its not so different but I was never very good. Here is my timeline.
Apple swift playground 3 or four great intros plus free ipad app
Xcode and the audiokit and more playgrounds on gf's imac
Gave up after making an app that makes a tone that changes with a slider. High hopes but lots of strange behaviour with building a UI in xcode that meant that if I didnt save my work and rename it, almost with every change, I would get horribly unexpected results that caused me to abandon the code and start again from the start. I must have done something wrong but read and watched 10s of hours of tutorials. It was very enjoyable to see my own app on the iphone screen but a very, very frustating journey.
Now Im much happier with coding and building in Arduino and (in the future) interfacing with the ipad through bluetooth and midi usb through the camera kit. Coding in arduino is only slightly less frustrating and I still have to backup and rename very regularly or I get unexpected compile errors which I cant solve and mean I have to go back to scratch !!!!
I think its important for us appaholics, time permiting, to give it a shot at writing an app at least to appreciate/feel the pain a bit. I have the time but I dont think my patience can cope with xcode. Hopefully Ill do a bit better with Arduino, so far it's much more fun!
I still have a Forth system for the classic Mac OS on the shelf, though I hardly used it.
After all programming is about methods, not languages
The basics are quite easy, but (a lot of) details require experience, which can be tedious, as @brambos explained. His short summary hits it perfectly imho.
Great thread. What about Audiokit? Does this help make things easier?
http://audiokit.io/features/
I love your down to earth, non sales pitch input @brambos. I already have Troublemaker but just bought Ruismaker FM too as I would like to see you continue to develop iOS apps.
Nice thread! Have worked alongside developers for years and am still in awe.
I know this isn't why you posted this, but regardless ...
Your work =
Just saying.
Hey @brambos speaking of nyquist, are there any good resources you can recommend for learning about anti-aliased FM synthesis?
@benkamen Patterning = in my top 3 most
rhythm apps.
Just saying.
Sorry for OTing.
Interesting question! I couldn't find any when I was researching it, so I sought out some of the gurus at the audio dsp mailing list (reading some of the discussions on this list is a humbling experience).
Basically, there are two sources of aliasing in FM synthesis:
Yamaha never managed to remove the latter form of aliasing in their DX/TX synths. What they do (which is also the method I adopted for Phasemaker) is to reduce the aliasing effect by applying keyboard-tracking to the modulation index. Basically: reduce the modulation amount the higher you move into the keyboard range. This will reduce the amount of frequency sidebands crossing the Niquist limit. Unfortunately it won't avoid the introduction of aliasing. It will then be a matter of sound-design to limit the audible aliasing across the meaningful range of your patches.
It is in theory possible to do band-limited FM, but it is very CPU intensive and hardly practical on iDevices unless you stick to very simple single operator FM. For example, you can use Bessel Functions (linky) to determine the frequency components of an FM operator and then use additive synthesis to reconstruct the signal up to the Niquist Frequency.
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.
It does seem similar to radio, where with modulation, the energy is transmitted more efficiently as a sideband. Hence, most professional radio transmission systems such as in avionics (when it was all analogue) use SSB. It is also not dissimilar to four quadrant multiplication being used as ring modulation. In an ideal ring modulator, we only end up with frequencies of carrier+modulator and also carrier-modulator. If one wanted just one of those side bands, one would have to sharply filter just the one and not the other (which is do-able). In the audio domain, the result is a (not very natural) form of pitch up or down shifting. Of course, most actual synths have leakage and mixing going on in the ring modulator, hence the character (except the odyssey and MS20, both of which used an XOR gate arrangement on purely the pulse waves only, so, no character).