Make multisamples on your iPad with SynthJacker

Featured

Picture this: a friend of yours has bought a nice vintage synth with great sounds, and wouldn’t you like to use those sounds in your own music-making? If only you could sample those sounds, but it seems like too much trouble… You would need to persuade your friend to let you borrow the synth, or you would need to visit them with your music-making setup, which nowadays is basically an iPad and an iOS-compatible audio interface.

Turns out that iPad and audio interface are just what you need for making multisamples of any MIDI-compatible synth, with very little effort. You only need to:

  • Find a cool sound you want to sample on the synth
  • Connect the synth to your audio interface
  • Connect your audio interface to your iPad
  • Start SynthJacker, select the notes and velocities you want to sample, and tap the Record button

SynthJacker plays the notes you selected, at the velocities you selected, through the audio interface and captures the result in real-time. But that is just the beginning: it then goes away and slices the audio into individual audio files, one for each note/velocity combination, and saves them on your iPad. When you switch to the iOS Files application, they are there, just waiting to be imported to a sampler or DAW of your choice.

Watch the SynthJacker demo video on YouTube  – it shows the app in action, and details the synth connections you need.

SynthJacker works on the iPad and on the iPhone, and requires an iOS-compatible audio interface (I use the Steinberg UR22mkII).

Why SynthJacker?

I developed SynthJacker for iPad and iPhone as a way to easily create a set of multisamples from my trusty old Kawai K4 and K5000S synths, but also the much newer KORG minilogue and IK Multimedia UNO Synth. With these, I have no shortage of great sounds on the iPad. Any synth you can get access to can be sampled in just a few minutes.

If you have a monophonic synth like the UNO, you can make it polyphonic (well, not actually) by sampling its sounds and using them in a DAW.

If you have a Mac, you can get Apple’s MainStage from the Mac App Store and use it to create sampler instrument in EXS format. However, it requires a Mac, and it can be difficult to retrieve the individual samples if you want to use them with other virtual instruments than Apple’s own EXS24mkII.

Coming soon: Inter-App Audio

The first version of SynthJacker is intended for hardware MIDI synths, but I’m also looking to add Inter-App Audio and/or Audiobus, and possibly also Audio Unit v3 support. This would allow you to sample the iOS synths on your iPad, which has been requested by many.

Let me know what you need from SynthJacker, and I’ll see if it can be supported. Many early adopters have already sent great development ideas, so please keep them coming.

Enjoy multisampling with SynthJacker!

Goodbye vCard, hello jCard!

The vCard format has served us well for encoding and exchanging contact information, but there is a better alternative – jCard. In this post I’ll describe why I think jCard can be better than vCard, and should be adopted by every software vendor who deals with contacts.

Both vCard and jCard are text-based formats, but whereas vCard has a unique legacy grammar, jCard is based on JSON. They both represent essentially the same data model that describes contact information: name, phone number, address, e-mail, and so on.

While vCard is widely supported, it is difficult to deal with. Being JSON-based, jCard has the advantage of being ready for use as soon as you parse it. You can even pluck values straight from the JSON object tree you get from the parser. Like vCard versions 3.0 and 4.0, jCard is an IETF proposed standard, RFC 7095.

Both of them represent a very complex data model, and both are semantically quite complicated. Still, I maintain that it is time to leave vCard behind and move on, because… well, read on.

vCard – hard to parse, hard to generate, almost easy to read

On the surface, vCard seems simple enough. It is a line-based format, where each line has a delimited format. Here is a simple sample of a vCard from randomuser.me, converted to vCard 3.0 by hand:

BEGIN:VCARD
VERSION:3.0
FN:Marilou Lam
N:Lam;Marilou;;Ms;
ADR:;;3892 Duke St;Oakville;NJ;79279;U.S.A.
EMAIL:marilou.lam@example.com
BDAY:1967-06-09T06:59:48-05:00
END:VCARD

Doesn’t seem to bad, does it? Well, I’ve written my share of ad hoc vCard parsers and generators in the past (in Objective-C, Java, and C#), and never went all the way, because when you start looking into the corner cases and the special handling required for many fields, you want to run away and hide.

First of all, the lines are not just lines. They could continue on to the next, and the process of continuation is complex, but not as complex as joining them back together, so most naïve vCard handlers just ignore continuation. By the way, according to the specification the line delimiter is a CR-LF pair.

The properties are separated from the values with a colon. Some properties may have multiple fields, so those need to be separated with a semicolon. Some properties may have multiple values, so those need to be separated with a comma. The fun begins if you need to have any of those separators in a value (it could happen, you know). They need to be escaped with a backslash. If you need to have a backslash, it’s time for another backslash. And newlines in values need to be expressed just like in many programming languages, with \n. It’s complicated.

So vCard may be quite human-readable, but that is neither here nor there, because vCards are not meant for eyeballing. They are meant for information exchange between computer systems. That also brings up the not insignificant issue of character encodings.

Y U NO I18N?!

There are several versions of vCard out there. The latest version, 4.0 (which jCard is also based on), sensibly mandates UTF-8 as the character encoding of the vCard. Unfortunately nobody seems to support vCard 4.0.

Version 3.0 of the vCard specification says the character encoding must be specified in the Content-Type MIME header field, using the charset parameter. That is fine, unless you don’t use HTTP to transmit the vCard, at which point you either agree between parties or guess.

Poor old version 2.1 from 1996, still in active duty, has the ASCII character encoding as the default, unless you specify something else with the CHARSET parameter. For every property. As you can imagine, nobody does that, and then we get stuff like “Käpyaho” for my last name (and I really resent that).

The default character encoding for JSON is UTF-8, which is really nice. If you don’t trust your endpoints, you can always \uXXXX escape everything beyond ASCII in your JSON string values.

jCard – easy to parse, fairly easy to generate, hard to read (except when pretty-printed)

Consider the jCard equivalent of the vCard above. Because it is JSON, it has a uniform syntax, so that you can feed it into any JSON parser and reap the rewards. It looks something like this:

["vcard",
  [
    ["version", {}, "text", "4.0"],
    ["fn", {}, "text", "Marilou Lam"],
    ["n",
      {},
      "text",
      ["Lam", "Marilou", "", "", "Ms"]
    ],
    ["adr", {}, "text",
      ["", "", "3892 Duke St", "Oakville", "NJ", "79279", "U.S.A."]
    ],
    ["email", { }, "text", "marilou.lam@example.com"],
    ["bday", {}, "date-and-or-time", "1967-06-09T06:59:48-05:00"]
  ]
]

(Sorry if the formatting is a mess, I’m trying to figure out how to present it. If you see code tags, they are not part of the jCard.)

As you can see, the jCard has a standard JSON syntax, but the content itself is not typical JSON. It is a polymorphic array, containing string and arrays. The top-level object is an array, so that you can have multiple contacts in one payload.

All the vCard properties are arrays where the first item is a string identifying the property. The rest are objects, simple values or arrays, based on the property. The jCard specification goes into great detail explaining how they are constructed.

The JSON example above is verbose, because it has been pretty-printed to be eyeballed by a human. If you were to condense it for online transmission, it would be like this:

["vcard",[["version",{},"text","4.0"],["fn",{},"text","Marilou Lam"],
["n",{},"text",["Lam","Marilou","","","Ms"]],["adr",{},"text",
["","","3892 Duke St","Oakville","NJ","79279","U.S.A."]],
["email",{},"text","marilou.lam@example.com"],["bday",{},
"date-and-or-time","1967-06-09T06:59:48-05:00"]]]

I only cheated a little by inserting a couple of newlines, but otherwise it’s tight, no-nonsense JSON.

The devil is in the details

So, vCard is difficult to parse, but jCard is not, at least for a JSON parser. However, semantically jCard is still just as complicated.

There are obviously inherent difficulties in representing contact information, and while jCard sidesteps the obvious issues of parsing and generating, the semantics are still there to be dealt with. Some might argue that it would have been better to create a whole new data model for jCard, instead of defining a JSON-based equivalent, but I don’t think it would have made much difference, going by the low adoption rate of jCard by major vendors.

Depending on the programming language, it is relatively easy or quite painful to deal with the results from a parsed jCard. If you have dynamic typing, you can just skate away. But if you have a strongly typed language like Java or Swift, you will need to be creative.

I want/need to parse jCards in an iOS application that I’m in the process of converting to Swift from Objective-C. Last time I got all the way to Swift 2.2, but then the work on the app stalled for a while, and in the meantime, Swift 3 happened. Earlier I had written some helpers to get from jCard to the iOS Contacts framework, but they did some naughty things which are not allowed in Swift 3 anymore.

So I decided to bite the bullet and create a proper library for dealing with jCards in Swift, called ContactCard. It is open sourced under the MIT License, and is up on GitHub if you would like to have a look or contribute. It’s very early alpha, so I expect it to improve a lot in a short time as I prepare it for the app. I intend to eventually publish it on CocoaPods too, and I hope to write some more about how I intend to solve the problems of polymorphic values in jCard properties.

 

HipStyles End Of Life

On August 15, 2014, HipStyles will be retired from the App Store.

I have decided to end the development of HipStyles, for good. In practice it was on hold for a long time due to other commitments, but after long last, version 2.0 was released in April 2014. Now it’s time to finally close the curtain on this act.

Since November 2012, HipStyles has tracked the new gear in Hipstamatic, and provided an easy way to find shots, or HipstaPrints, taken with a specific combination of lens, film, and flash. Some iPhoneographers have found it useful, since it provides a function Hipstamatic itself doesn’t.

Here’s a summary why I think HipStyles failed to make a dent in the universe:

  • Lack of initial validation of the product idea
  • Premium pricing probably alienated many potential customers
  • The execution failed by some accounts: too many or wrong features, with bugs

Continue reading