5 Ways Apple Could Improve iPad, iPhone & iPad Touch For DJs

You’ve read the benefits and pitfalls of DJing on Apple iOS devices, so in this final “State of the Nation” piece we come to consider what can Apple do to improve its devices and mobile OS for DJs.

Exactly what amendments to iDevices or the underlying code could further unlock the potential of DJing on a portable Apple device? Here we list our top five…

1. Improve the audio output

As we’ve mentioned before, audio output is better from the 30-pin connector because it doesn’t perform the additional processing that occurs with the headphone jack. It also means that you can bypass the internal digital to analogue converter (DAC) chip of the device to use an external DAC of better quality.

So that bypasses the sub-standard headphones socket. So far so good, but the more pressing issue for DJs is the current single stereo output situation. Apple need to alter either the devices or iOS to allow for two independent stereo audio streams, one sent to the headphone jack and another (but different) to the 30-pin connector.

Resolving the single stereo output is the most important area to address. If Apple did nothing but provided dual stereo audio stream functionality, a lot of consumers and app developers would be ecstatic. We know of several app developers and hardware manufacturers who have put pressure on Apple for a solution to this issue, and with improved specification for iDevices with each iteration, the hope is that this will come soon.

Interestingly, the latest incarnation of the iPad has the capability to output Dolby Digital 5.1 surround sound. Maybe this multi-channel capability could be utilised in some way by DJ app developers?

2. Remove restrictions on files in the music library

At the moment, for an app to play or manipulate a track in the music library, a local copy must be made. This leads to duplicate files across the device, eating up valuable storage space.

Ideally, Apple would lift this restriction. I’ve put the audio files onto the device already, so why can’t the apps I purchase access those tracks directly?

Of course, there would need to be some restrictions on what those apps could do, to ensure the audio files are not corrupted and the files are still playable in the default music app.

This would allow DJ apps to set the BPM tag against the file directly rather than storing the BPM data in a local file specific to the app.

The storage of BPM metadata isn’t the issue here, it’s the duplication of files across the device. If Apple can overcome this in a sensible way or at least provide a mechanism for clearing out the audio file cache per app, then the storage space may stretch further.

Remember, what we’re after here is the clear down of the music file cache; we still want to keep the local database/file containing the BPM, waveform and beatgrid data to save the app from recalculating on the next load.

3. Improve the generic music library API

The majority of app developers are using a standard piece of code to give users access to the tracks in the music library. The generic approach is fine for casual browsing but when you need to access a track quickly then it is less than ideal.

My suggestion would be to still allow the current approach, but develop a new “pro”-style streamlined interface focusing on data, sorting and searching. The track screen of DJ Player is a perfect example of how this could be achieved.

The music library must display the usual detail of Song Title, Artist and perhaps Album Title, but should also include BPM, duration and comment (for harmonic mixing).

Tip: If you’re using a DJ app which doesn’t provide sorting by BPM data, then I recommend sorting the music library (of your iDevice) by BPM in iTunes while connected to your host machine – the generic library screen seems to display the items in the order which they were last listed in iTunes.

4. App Store refinements

Since the App Store is likely to be the method by which a user locates the app of their choice, the search, sorting and categorisation could do with some fine tuning. The “Music” category covers a multitude of flavours from music making to music playback but also fan-related apps. Perhaps a sub-category would be useful?

Navigating the App Store is less likely to feature high in a customer’s mind, however it does affect developers greatly. Understandably, Apple wishes to control the apps loaded onto its devices to ensure a level of quality is met and that malicious code is not implemented, but unfortunately, sometimes the manner by which Apple manages changes in core code can result in functionality becoming obsolete and apps getting rejected during the approval process without much warning.

For example, iOS 5 Apple depreciated a piece of commonly used code (Unique Device Identifier or UDID) and replaced it with a centralised object (CFUUID), to address privacy concerns. Apple is now using the app approval process to instantly reject any app which is still using the old code. The communication of major changes like this could be improved, minimising the resulting effects.

5. Allow access between apps via a shared area

I’m going out on a limb with this suggestion since it only applies to those with more than one DJ app on their device. Music-making apps have the ability to use audio copy/paste and Virtual Midi as a means of sharing data, so why can’t DJ apps share data too?

For instance, if I load a track on a DJ app, the process tends to calculate BPM, waveform (for display), and beatgrid. If there was a generic and approved way of doing this, then the data could be stored to a central file on the device for recall by any other DJ app when loading the same track.

The data would only be calculated on the first load of the track by any DJ app (using the agreed approach). It would save recalculation of the same data over and over again. This idea could be extended to cover the storage of cue points and loops; again it would require an agreed approach to work.

It would need Apple to sanction a “sandpit” area for apps to share access to the central file, but would also take a change in mindset between app developers to employ a centralised method of vital metadata calculation, storage and retrieval.

Conclusion

While tablet devices are not currently the most obvious choice of technology for the digital DJ and also not suitable for all DJ styles, with a few tweaks to the underlying code and possibly the product as described above, I believe the adoption of iDevices for DJing purposes would increase.

After all, laptops aren’t made specifically for DJing, but digital DJing has done well enough so far. Are you listening, Apple?

Do you think Apple will address any of these issues? Is the situation on Android any different? Please share your thoughts in the comments.