I am really stuck on this one and need some opinion….. I am trying to design a step sequencer as the heart of a music app where beats can be played from a beat pad. The default quantization I have is 1/64 for one bar and maximum of 27 sound files for each time slot of the bar (64). Right now I am creating 1 AUGraph, 1 Audio Unit. I have 27 input buses for each of the time slots ( up to 64 ). But this approach does not work for me since 27*64 buses in all and this is probably creating a lot of noise while trying to play back the recorded sounds. Can you suggest me a good design approach towards creating a sequencer in terms of how many AUGraphs, Audio Units and input buses to be used?

by the way…really appreciate the knowledge you have shared on the dev forums and over here. Thanks!

Thanks for sharing your knowledge, that's not so frequent.

As programmer and user of Loopy, I was wondering how you manage the memory part of the audio.

Do you write the audio data directly to files, or is it retained in RAM partially or completely ?

User side, the question becomes : Can we record almost infinite length loops within loopy ^^ ?

Looking forward for the community features on Loopy !! By the way, will it be an update of Loopy or another app ?

Cheers

Raphaël

You make some good points – particularly with the clapping example. Echo removal is a fairly imprecise science, even when it's done well, and it can certainly interfere with incoming audio. Whether such interference is the exception or the rule when it comes to a musical looping application is something I'm not sure of.

The primary limitation of the whole thing is, as you mention, the hardware – having the mic right next to the speaker on the iPhone isn't particularly conducive to a live performance-based app, unless users bring their own external hardware and connect it up to the iPhone.

What would be perfect is to somehow gain access to the echo cancellation that's in place for speakerphone mode, but given that it's probably just embedded right into the hardware's audio pipeline, that's extremely unlikely to occur =)

The more I consider it, the more I think that echo cancellation might be at odds with the very purpose of the app.

For example, in "Just For Now" after Imogen has built up the main vocal loop, she claps a rhythm twice round the loop. In the second iteration, how is an adaptive filter to differentiate between the clapping coming from her hands and that coming from the monitor speakers? (Presumably, in the studio, they actually use a gated short-range mic to work around the problem.)

If her timing and the audio reproduction are both perfect, the filter should theoretically remove the entire input signal. If her timing is not perfect, how can a filter be expected to converge? One could perhaps try to capitalise on the imperfect fidelity in the iPhone, but that doesn't really get you away from the bottom line: echo is rhythmic in nature.

I think perhaps your approach is not just the easiest but actually the only way to go (maybe with a little adaptive gating?) Ho hum, I guess that rules out performance characteristics of the kind I'd hoped for. (ThePETEBOX is great, isn't he? He's damn good without the loop pedal too!)

Cheers, Hamish

That's very thoughtful of you, with your disclaimer; that's fine, though.

Those youtube videos were fantastic – that guy is brilliant!

As far as the echo cancellation stuff goes, the main difficulty isn't so much the identification of the echo delay as much as the actual removal process, which is why my efforts failed; it's not just a subtraction of one signal from the other, it's actually a process that involves iterative refinement and more academic papers than I felt like reading =) I recommend taking a peek at the Speex source for some inspiration (the comments also refer some papers on the subject) – I'd love to hear how you go. If you succeed, maybe there's hope for the rest of us!

It may be a large amount of work – it would be a very helpful piece of functionality though. Maybe it's something we could collaborate on somehow, since it would definitely benefit us both.

Anyway, let me know how you go (if you feel like doing so).

All the best!

Many thanks for all your efforts in putting all of this information together. Your writing is clear and your presentation is marvelous.

In the interests of full disclosure, I should start by saying that I came across your blog during a little preliminary research into writing a "loop pedal" app for the iPhone. So if you'd rather not reply to my comment because I might be a potential competitor, I'll understand. That said, I envisaged the focus of my app as being rather different to yours — the primary function of mine would be the equivalent of a single track in mix mode for Loopy:

http://www.youtube.com/watch?v=LxbfBRNY4M8

The interface I have in mind is completely different to yours, designed to facilitate jamming over a single loop, just as a traditional loop pedal does. Loopy is more powerful, but I want to make that common case more accessible (though I have considered multiple tracks).

But because I want to focus on the "jam", echo cancellation is quite important to me. You mention that you attempted a cross-correlation technique, but I'd have expected the latency to be pretty much constant, with the overwhelming component of "echo" being direct from speaker to microphone rather than via the walls of the room or whatever. You hard-coded the hardware latency for syncing record and playback clocks; is it not possible to do the same for the outputbuffer-to-speaker-to-microphone-to-inputbuffer round-trip latency?

I appreciate you spent some time on this, so there's probably something I'm missing. Obviously there's still the disparity between the original sound and the speaker's tinny reproduction to deal with, but it just struck me as odd that you needed anything more than a static technique to do the lining up of the signals.

I don't really expect an answer, though I'd appreciate a reply even if just to say you don't want to talk to me As I say, I just wanted to introduce myself and state my intentions, as I'm bound to get involved in conversation with you in threads about RemoteIO and I don't want to be disingenuous. And thanks again for all the information you've made available.

Best wishes, Hamish