G-Stomper Drum Machine/Groovebox for Android

[planeth]

Hi all.
I've just released my first android audio app a few days ago. First of all I want to thank you for this great resource, reading the postings helped me a lot getting into the dsp stuff.

I've used the Electribes for many years, which definitely inspired me the most for this project.

It's a stepsequencer (max 128 steps) based Drum Machine/Groovebox with 11 Tracks, equiped with a chainable 3 Effect Processor rack. It's specially designed to perform live sessions. So you can record modulation curves on the fly, for effect parameters as well as the usual sample parameters (startpoint, pitch, etc.).

I started G-Stomper, since I did not find that kind of app for my new android phone. The main goals were .. having fun, don't stop the sequencer for anything and having high quality audio output.

Hope you like it.. (demo and paid version available)
https://market.android.com/details?id=c ... tomperdemo
https://market.android.com/details?id=c ... h.gstomper

[kuniklo]

This looks really well done. Congrats.

Did you write most of this in java or did you use the ndk?

[planeth]

Thank you .

It's all pure java, no ndk used.

[kuniklo]

Very interesting. I wouldn't have guessed that the Dalvik VM would be fast enough for that. Good to know. Thanks for the info.

[planeth]

It is fast enough, yes, but you have to optimize it to very last bit of performance.. (same for memory usage).

[SingleCell]

It is fast enough, yes, but you have to optimize it to very last bit of performance.. (same for memory usage).

Wow, I'm impressed! No NDK

Tried the demo today as it was recommended by one of my users. Very impressive sound, the stereo panning is great too, something I really need to add soon.

I've only been around the scene for a few weeks myself but I'll wish you luck with this one. The more quality audio apps on Android, the better.

[planeth]

Thank you, cool that you like it

I've only been around the scene for a few weeks myself but I'll wish you luck with this one. The more quality audio apps on Android, the better.

I absolutely agree. There is still a hole in the android market of audio apps. So I think we made a good start to fill it.
I wish you the same for yours.

[kuniklo]

It is fast enough, yes, but you have to optimize it to very last bit of performance.. (same for memory usage).

Can you elaborate on this without giving away any secrets? Great to see another good audio app on android.

[planeth]

It's not a big secret. Most of the information is in the web. A very good start is the following link which helped me a lot:
http://developer.android.com/guide/prac ... mance.html

Take as much work as possible away from the device. Do never instantiate anything within loops, best would be not to instantiate anything at all during runtime. Pool and reuse all instances, that you need at runtime. Do never use getter/setter methods, or anyway use as less methods as possible. Put everything that is used multiple times into local fields. Use always the smallest possible datatype you can. Find the fastest loop notation for every single loop (and do not use Collections or Iterators). Do not use inner private access, use package scope instead (see the link above).

Short: You have to do everything by yourself, what normall the JIT does.
20 years ago, developing must have been very similar to that..

I found a great resource on the web for android performance tuning, but I haven't the link with me. Gonna post it tonight.

[nikolatesla20]

Wow all Java, pretty good job! Although I do hear some crackle distortion when I change the volume of a sample while playing. That was on a Galaxy Tablet. You could experiment with increasing the audio thread priority if you haven't done so yet. Otherwise has good sound, running at 44Khz stereo is never a bad thing Good work so far!


-niko

[planeth]

Thanks a lot Niko.

You could experiment with increasing the audio thread priority if you haven't done so yet.

Yes, I did already, it's absolutely on the limit. If I give a higher priority to the audiothread, the gui will be uncontrollable.. unfortunately.

I'm thinking about reducing the amount of events send by the faders. That would definitely reduce the cpu usage.

The fastest way to get some performance headroom is to turn off the track pads flashing with the button right beside the track pads.

Andreas

[kuniklo]

Thanks for the details. Writing really high performance Java sounds kind of tedious but probably still easier than bridging into the NDK.

[planeth]

Writing really high performance Java sounds kind of tedious but probably still easier than bridging into the NDK.

Yes, it is actually tedious sometimes:). On the other hand, it gave me a complete new view on java programming, since it's truly the opposite to my normal job, where I have to write high structured, human readable code (where performance and memory issues are very rare). And it was a great fun getting all this stuff running:).

Here are two sites that helped me a lot:
http://blog.javia.org/assembly-java/
http://mindtherobot.com/blog/

[kuniklo]

I know what you mean. I've been writing iOS apps lately and it's been very refreshing to have to think about low-level performance again after spending so many years writing very high-level business code.

Thanks for the links!

[SingleCell]

planeth, have you tried running it on tablets yet?

I just tried on my NookColor (1024x600) and the control layout is really weird.
(can post screenshots if you'd like)

I'm not familiar with Android's layout stuff so I'm not sure why it's doing that, but it definitely doesn't look the same as my NexusOne.

Not a dealbreaker of course, but just wondering if you'd seen it...
I guess you could probably create a 1024x600 test device in the emulator to see since you're 100% java.