-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Welcome to the DialpadDeveloperKit wiki. This kit will allow you to make your own dialpad plug-ins for Ethereal Dialpad, the expressive touch synthesizer for Android. If you have any questions at all about Ethereal Dialpad or this developer kit, don’t hesitate to ask. You can figure out the email address…
To get started, download the source distribution of the developer kit https://github.com/rndmcnlly/DialpadDeveloperKit/archive/master.zip
If you make something cool, please share it with me so I can see what comes out of this simple sample code.
A dialpad plug-in is an independent Android application that you make which includes a special Activity which the the user may use to interact with the audio synthesis core of Ethereal Dialpad.
Conventionally, the purpose of a dialpad plug-in is to take some input from the user and feed it to the synthesizer service provided by the base app, Ethereal Dialpad, displaying some nice animation along the way. Though a dialpad plug-in can really be an arbitrary Android app, keeping the focus on interacting with the synthesizer is a good idea.
Dialpads can tell two synth lines to turn on and off, as well as set an x/y position for both of them (interpreted as either dual pitch controls or pitch and volume controls when “duet” is disabled). While the user can control the synthesizer settings from the main screen of Ethereal Dialpad, your plug-in can only read the synthesizer settings (to provide a more appropriate visualization). The complete interface to the synthesizer is provided by the ISynthService.aidl file in the developer kit.
Sure, do whatever you like. You control the distribution of your plug-in app just as you would any other Android app. If you do magically get rich all of the sudden, consider donating some back to me (paypal [email protected]).
Currently, any app in the Android Market which contains both “ethereal dialpad” and “plug-in” will be listed there. There is no formal approval process.
Making it from scratch is exactly what this developer kit aims to save you from! Well, anyway, the most important thing custom dialpads need to do is provide an Activity that supports a special action that the base app is looking for. Your dialpad activity should have an intent filter declared in the manifest that looks like this:
<intent-filter><action android:name=“as.adamsmith.etherealdialpad.PERFORM” /></intent-filter>
Beyond the ISynthService interface, plug-ins do not have control over how the synthesizer operates. If you are familiar with synthesizer design, contact me. Together we can figure out what should be added and what new interfaces exposed to support the functionality you would like to use in your plug-in. (Though, if you are this advanced, we may just decide making a whole new app is a more direct approach!)
See this gist for an example of the custom DSP processing used by the synthesizer service: http://gist.github.com/376028 Email me if you’d like to work with the library your self (or just steal the ideas any make something in your own).
Here is a little checklist of issues you should address before you submit your new dialpad to the Android Market. Consider double or triple checking it before submission.
The base app is required to use any plug-ins as each plug-in doesn’t show up in the launcher screen. The base app also provides the centralized implementation of the synthesizer service. You can find the latest version of the Ethereal Dialpad in the Android Market. If you want to install it on your emulator, use this direct download link in the browser: EtherealDialpad.apk
The Java package name must be unique across all Android apps. Follow the Java conventions and use a reversed domain name with your project name at the end. Example: replace “as.adamsmith.etherealdialpad.pads.example” with “com.example.zeropad”. Make sure your AndroidManfest.xml and your Java source files are updated. Leave ISynthService in the “as.adamsmith.etherealdialpad.dsp” package so that you can continue to interact with the base app.
In /res/values/strings.xml, edit the app_name key to easily change the name of your dialpad (this string is used as the label for your main activity). See the style guide for the dialpad naming convention. Feel free to be super cool and localize the name of your dialpad — I haven’t been so good as to do this for my own yet.
Change /res/drawable/icon.png to be a new square image to be shown next to your dialpad description in the dialpad selector screen. Fancy developer will want to provide the icon multiple resolutions using the normal means. (Again, I’ve been too lazy.)
Modify /src/as/adamsmith/etherealdialpad/pads/example/ExampleDialpad.java to build the dialpad the way you like it. Note how almost all of the code is dedicated to pushing information to the “synthService” object. Your diapad doesn’t need to be a subclass of the provided abstract Dialpad class; this class exists to speed up your development efforts, but you should feel free to refactor things as you see fit.
When building a dialpad that features fancy animations, remember that a lot of CPU effort is being dumped into rendering the real-time audio stream. Make sure to test the performance of your dialpad on real devices to get a feel for how much processing power is available to you. On low-end devices (ADP1 or ADP2 class), audio rendering takes up most of the CPU and even modest non-hardware-accelerated graphics will cause occasional skips in the audio stream. On higher-end devices (ADP3 class), audio rendering is no longer a bottleneck and even with optional synthesis effects turned on in the base app there is lots of processing power available for animation or other processing.
Really!
- Did you use any new APIs? If so, update the minSdkVersion.
- Does your dialpad use any special permissions? Make sure to declare the ones you really need and remove the ones you don’t really need.
- Does your dialpad assume any special input devices? (Most likely it does!) If so, add and tweak a uses-configuration tag in the manifest. Technically, even the example plug-in should declare that it requires a touchscreen, but I left it off to keep things as simple as possible. You should declare what you need.
- Does your dialpad make sense in multiple orientations? Even if it does, users sometimes complain about it shifting during a performance.
- … Yeah, read your manifest, and make sure you agree with what it says.
These items are not strictly required, however they will help the various plug-ins made by developers like yourself feel like parts of a cohesive whole.
- The main (and possibly only) activity should be full screen to offer the user maximum immersion in your interaction.
- The dialpad’s name should start with a simple name, a colon, then a more detailed description. Ex: “Gravitone: Dial with the force of an entire planet.”
- Allow the user to easily return to the dialpad selection screen using the back button; don’t use confirmation dialogs.
- Allow the user the save and record finger traces.
- Allow the user to draw out projections of finger traces in time and play them back in a looping manner (painting in a piano-roll view).
- Control the secondary synth line with a time-delayed version of the inputs to the primary synth line.
- Get the users physical location using GPS and map some interesting periodic function to their lat/long. Get them to exercise!?
- Transmit live or recorded finger traces to your central server and allow other users to tune in on others’ live activity!
- Use computer vision to track bright spots in a live camera image; allow users to dial by waving a flashlight! Alternatively, detect motion, hand gestures, face position, facial emotional expressions…