# A simple, audio editing app: SynthaSIZER



## WhataSpaz (Feb 20, 2012)

First off, let me start off by saying there is no app (yet). I'm starting to get tired of downloading music on my computer, compressing it down to 224kbps and transferring that to my tablet/phone; it's an extra step I have to take. I managed to come up with a concept that's simple, on the surface. I even came up with the name and icon lol. Would anyone be interested in something like this?



















Main features include:

* Android 3.0 - 4.x
* In app audio editing with support for mp3, wav, flac...etc
* Ability to add more tracks, trim, increase volume, bass/treble of an audio file and save to a directory on your device.
* Variety of effects like slow down and change pitch, in time.
* Output that file to a different file type and data transfer speed if desired.
* Double as a ringtone maker.

I'm slowly learning java, the sdk and developing...very slowly. If anyone wants to start this project with me, pm me.

Edit: Feedback and suggestions appreciated!


----------



## yarly (Jun 22, 2011)

Simple app is kind of misleading about that, lol. It would take some serious time to implement all that in one app + make it user friendly, even for a seasoned developer.

If you're intentions are only making it for you + friends, then much less to worry about. If you're planning on selling it or whatever, then much more obviously (design, supporting more than 3.0+ which is only 15-20% of the market, etc).

Android also does not support MP3 (re)encoding, so have to use a third party library. Problem with that is any java only solutions will suck for performance + options so you're left with using LAME and/or FFmpeg (which uses LAME). That means compiling for ARM with the Android NDK and then creating a JNI wrapper around the binary in Java to interact with the native FFmpeg library. Dealing with that is a pain enough for someone that's comfortable with Java and cross-compiling.

I also recommend using Intellij IDEA over Eclipse for Java + Android. It's much more user friendly for someone just getting acquainted with programming and Java + Android (just assuming you do not have any sort of programming background already, but if you do, then obviously it should all come much easier).

I would start small and only get what is needed for the main goal (no matter how ugly/nonfunctional) versus trying to do too much right away and getting burnt out on the idea. That or start out with a smaller idea for an app that's has a brighter light at the end of the tunnel and put this one aside for later. Just saying Android's SDK + learning Java + learning to cross compile binaries (and maybe learning how to program) all at the same time is a huge undertaking and should be done with focusing on one part at a time if you're serious.

If you're more focused on just doing the UI and front end stuff and then finding someone to do most of the software side development, then that's an option, if you can find someone you can work with. Even if you go that route, it's still good to know somewhat of what goes on the development side of things so keep reading and studying those java and android development tutorials either way. Just a pet peeve from working with designers in day job is dealing with ones that have no idea how to build a UI/design that works well with the backend code. Although most companies and people treat them as two independent things, in reality, it just isn't that black and white and only really able to be seen if you have done both (I do maybe 20-25% design/user experience and the rest is all development on the code side). Mainly, it just takes the burden off the developer having to explain everything explicitly ahead of time for every task and speaking everything through metaphors/analogies (since the designer can ease some of the burden that a developer will have to work around if the designer knows what the developer has to deal with already).

That's just my take on it from building apps for Android, spending my undergraduate and now graduate years in a Computer Science Program at a University, as well as tutoring/mentoring a good friend from when they started to program a few years ago to now.

Good luck on your endeavors and feel free to keep posting questions. Another good resource is #android-dev on freenode IRC (or ##java for general, non android java questions), though don't ask them a billion questions at once "spazing" (pun intended...maybe?) out on them







. Also some other advice and resources/links listed in my rootz profile

Hopefully I didn't come off as too pessimistic. I just try to say things on realistic terms when I can, even if it sounds blunt or semi-negative to some.


----------



## WhataSpaz (Feb 20, 2012)

Very helpful! It was an idea I had, not planning on releasing it unless it was perfect, once everything was said and done. Do you think I should try something a little easier to start off? I've been bored with all the sms apps we have and I'm very picky since I spend a great deal of my day in my sms app itself. Maybe one of those?

Edit:



> [background=rgb(245, 245, 245)]Android also does not support MP3 (re)encoding, so have to use a third party library. Problem with that is any java only solutions will suck for performance + options so you're left with using LAME and/or FFmpeg (which uses LAME). That means compiling for ARM with the Android NDK and then creating a JNI wrapper around the binary in Java to interact with the native FFmpeg library. Dealing with that is a pain enough for someone that's comfortable with Java and cross-compiling.


[/background]

Now when you say Android doesn't support it, and I would have to use a third party library...are you saying taken off of a third party device?


----------



## yarly (Jun 22, 2011)

WhataSpaz said:


> Now when you say Android doesn't support it, and I would have to use a third party library...are you saying taken off of a third party device?


Not off the device or some other app. I mean compiled from the source and grabbed from the site that maintains the library project. FFmpeg is the main library for most opensource media stuff on Android, Linux or Windows (like VLC player). LAME, probably the best encoder for MP3 is part of FFmpeg, or it can be used separately (http://en.wikipedia.org/wiki/FFmpeg). Basically, if you want something not in Android, you have to get the source, cross compile for ARM using the Android NDK and then add it to the programming project. Then, you have to write a wrapper in java to access that code. This is only something that needs to be done for non Java libraries (which are referred to as native code normally as they have direct access to the underlying Linux kernel without passing through the dalvik/java virtual machine). Java libraries (jars) and source can be added directly to a project as if it were being used on a desktop pc.

To sum it up, it's basically like having a house (which you can consider an App) and you want to add a room (a third party library like ffmpeg) onto that house. To do that, you have to go fetch all the materials (ffmpeg source) and use the given plans (the make files for building and the NDK toolchain). In order to get working electricity and A/C to that room, you have to wire it up directly to the rest of the house (doing this in Java would be using a Java Native Interface Wrapper to access the library). Cross compiling has some other things to factor in, like the instruction sets the device supports (ARMv6 [not really a factor anymore], ARMv7 [nearly everything now], ARMv7 with NEON [not necessary, but makes devices that use it run faster], then Intel x86 devices), but the NDK can automate most of that if you configure it correctly.

I compiled ffmpeg once for something I was working on. It wasn't the worse cross compilation to deal with, but it had some annoyances. No weird dependency libraries at least, but again all this stuff takes place on the command line for compiling (either using cygwin on windows or linux/osx terminals). You could probably find a version already compiled, but it could be out of date, or not compiled in the most efficient way, so really best to do it yourself.


----------



## JBirdVegas (Jun 11, 2011)

And if you hit a bump while learning don't hesitate to post your code and ask us. I'm always happy to help people learn.


----------

