Dan Rosenstark, author of MIDI Designer, on Tech & Music

Swift 2 Calling Swift 2

Consider these two methods in Swift 2:

func doThis(thing: AnyObject) {}

func doThisThing(thing thing: AnyObject) {}

are called like this in Swift 2.

doThis("")

doThisThing(thing: "")

So:

• The first parameter in the doThis method cannot be named by the caller.
• Whether the method name ends in the first parameter name or not, the behavior doesn't change.

Swift 2 Calling Objective-C

Here are two methods in Objective-C:

- (void) doIt:(NSObject *)thing;

- (void) doThisThing:(NSObject *)thing;

Both of these methods get called without their first parameter name from Swift 2:

someObjcObject.doIt("")

someObjcObject.doThisThing("")

So:

• First parameter name is not used.
• The method name is the same as the method name in Objective-C.
• This is true even if the method end in an obvious parameter name, like "doThisWithThing"

Objective-C Calling Swift 2

The method name is the same as that seen in Swift unless you've doubled up on the parameter name as in the above example. So:

func doThis(thing: AnyObject) {}

func doThisThing(thing thing: AnyObject) {}

results in this calling code in Objective-C (note the altered method name in the second example):

[vc doThis:@""];

[vc doThisThingWithThing:@""];

The first method doesn't change even if we use an underscore in the Swift method declaration:

func doThis(_ thing: AnyObject) {}

So:

• The method names translate normally
• Doubled-up parameter names get added to the method name in Objective-C with the conjunction "with"

Changes in Swift 3

There is no automatic removal of the first parameter name, so:

func doThisThing(thing: AnyObject) {}

gets called like this:

doThisThing(thing: "" as AnyObject)

If you want to remove the first parameter label for callers, you can use an underscore, of course.

Weird Automatic Conversion to Swift 3

So this converted just fine:

func doThis(thing: AnyObject) {}

func doThisThing(thing thing: AnyObject) {}

// calling code
doThisThing(thing: "what")
doThis("what")

and became this in Swift 3

func doThisThing(thing: AnyObject) {}

func doThis(_ thing: AnyObject) {}

// calling code
doThisThing(thing: "what" as AnyObject)
doThis("what" as AnyObject)

So that makes sense.

Converting Again

Now you realize that your massive conversion needs to forward merge more Swift 2 code into the same target. Xcode warns you not to do automatic conversion again, but you do it anyway.

The two methods now look like this, which makes no sense (the second one has now lost its parameter label):

func doThisThing(_ thing: AnyObject) {
    print("doThisThing \(thing.hash)")
}

func doThis(_ thing: AnyObject) {
    print("doThis \(thing.hash)")
}

// calling code
doThisThing("what" as AnyObject)
doThis("what" as AnyObject)

In this simple case the callers get updated, but the Objective-C callers do not:

And in many cases, your calling code will be broken in Swift as well.

Calling Objective-C from Swift 2 vs. 3

The automatic madness deepens with Swift 3 interop.

Consider this signature in Objective-C:

+ (NSObject *)deserializeNewOrExistingObjectFromAPIV1JSON:(NSDictionary *)json

In Swift 2 you called it this way:

ThatObject.deserializeNewOrExistingObjectFromAPIV1JSON(json.dictionaryObject)

But this changes in Swift 3 to:

ThatObject.deserializeNewOrExistingObject(fromAPIV1JSON: json.dictionaryObject)

And now the result comes back as a forced optional, whereas in Swift 2 it came back as a non-optional.

Which may or may not get picked up by the automatic converter. The more complex your compilation target is, the less likely the automatic conversion is to succeed.

Some capitalization changes as Objective-C gets magically converted:

- (instancetype)initWithJSON:(NSDictionary *)messageBody

// Swift 2
ThatObject(JSON: dict)!

// Swift 3
ThatObject(json: dict)

And some stuff gets even weirder in Objective-C interop:

+ (id)findForUuid:(NSString *)uuid

// Swift 2
ThatObject.findForUuid(uuid)

// Swift 3
ThatObject.find(forUuid: tender.uuid)!

1. Type one line of text
2. Turn that into a code block
3. Replace the contents of that code block with code you paste from Xcode
4. That's it!

• You can add projects to projects (subprojects) or to workspaces
• Projects can be saved as workspaces
• Add a project to another project -- or a workspaces -- by adding the .xcodeproj file.

1. Create a new, Single View Application for iOS
2. Add the .xcodeproj for an Xcode project that produces a .a file
   
   In this example we're using GBDevice.
   
   
3. Set up the primary project like this
   
   
   

• Create a new header file called BridgingHeader.h
• Add it to the Build Settings for the Single Window App
  
  
  
  
• Utilize it in a Swift file
  
  let version = GBDeviceInfo.init().modelString
  print(version)
  
• That's it.

1. Add knob
2. Set Subtype to Presets
   
   
   
   
3. Tap "Yes" to create 12 presets
   
   
   
   
4. Add the four knobs as subcontrols of the Preset knob
   
   

1. Make each button a supercontrol of Knob 5
2. Verify the supercontrols of Knob 5
   
   
   
   

• Btn 6 = 0 ÷ 12 x 128 = 0, but we put in a MIDI On value of 1 so that it's not equal to the OFF value
• Btn 7 = 1 ÷ 12 x 128 = 10.6 = MIDI On Value of 11
• Btn 8 = 2 ÷ 12 x 128 = 21.3 = MIDI On Value of 21
• Btn 9 = 3 ÷ 12 x 128 = MIDI On Value of 32
  
  

1. Create a knob
2. Make it a supercontrol
3. Make the four buttons subcontrols of the knob
4. In Design Properties -> Relationships -> Supercontrols Options, turn BUTTONS ARE SEND ON ONLY to ON
   
   

• Left: 1, 3, 5 7
• Right ones cannot be configured separately: 2, 4, 6, 8
• You can rename the mix

• Analog Ins
  • from Front Panel: 1 and 2, 3 and 4
  • from Back Panel: 5 and 6, 7 and 8
• Daw Inputs: 1 to 7 (L) and 2-8 (R)
  
  These are your DAW output destinations, exactly as labeled.
  
  
• SPDIF and ADAT

• You can use the Mix Output dropdown to define where the Mix outputs
• Note for Headphone Outputs on Front Panel
  • Line H/P L and R are called "Output 3" and "Output 4" in the Routing Panel
  • Anlg Out 5 and 6 are called "Output 5" and "Output 6" in the Routing Panel

• You can use the routing panel to route individual inputs OR mixes to each output.
  
  
  
  
• Monitor Outputs 1 and 2 are in back
• The ones that show a little headphone are the front panel headphone mixes: 1-2 and 3-4

• Name your mixes
• Do not route inputs to outputs directly: instead, use mixes
• Do not use the Routing Panel: use the checkboxes in the Mix Output to define the routing
• Note: using the checkboxes in the Mix Output requires setting both L and R channels of the Mix Output, so you have to check all boxes separately.