Build dirt binary for Mac OS X

[yaxu]

As a self contained package, both 32 and 64 bit versions would be ideal.

[bgold-cosmos]

I haven't gotten all the way there, but this info might be helpful:

On my machine, the libraries are:

    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
    /opt/local/lib/liblo.7.dylib (compatibility version 10.0.0, current version 10.0.0)
    /opt/local/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.25.0)
    /opt/local/lib/libsamplerate.0.dylib (compatibility version 2.0.0, current version 2.8.0)
    /System/Library/Frameworks/Jackmp.framework/Versions/A/Jackmp (compatibility version 1.0.0, current version 1.0.0)

Apple forces the System library to be dynamic, but it should be the same (I think?) across most Macs, at least as long as the OS version isn't too different. liblo, libsndfile, and libsamplerate all have static versions so packaging those should just be matter of using the right compile/link flags. The one I don't know about is Jack. I'm using jackdmp version 1.9.10 and I don't even remember how I installed it - I have multiple installs unfortunately.

I think the 64/32 bit thing is a nonissue for any Mac since less than 5-7 years old. In any case, Haskell Platform appears to be 64-bit only on the Mac.

[yaxu]

Hmm, does the portaudio version (I.e. make dirt-pa) work in Mac OS, in
terms of accurate timing?
On 14 Nov 2015 4:36 pm, "Ben Gold" [email protected] wrote:

I haven't gotten all the way there, but this info might be helpful:

On my machine, the libraries are:

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/opt/local/lib/liblo.7.dylib (compatibility version 10.0.0, current version 10.0.0)
/opt/local/lib/libsndfile.1.dylib (compatibility version 2.0.0, current version 2.25.0)
/opt/local/lib/libsamplerate.0.dylib (compatibility version 2.0.0, current version 2.8.0)
/System/Library/Frameworks/Jackmp.framework/Versions/A/Jackmp (compatibility version 1.0.0, current version 1.0.0)

'''
Apple forces the System library to be dynamic, but it should be the same (I think?) across most Macs, at least as long as the OS version isn't too different. liblo, libsndfile, and libsamplerate all have static versions so packaging those should just be matter of using the right compile/link flags. The one I don't know about is Jack. I'm using jackdmp version 1.9.10 and I don't even remember how I installed it - I have multiple installs unfortunately.

I think the 64/32 bit thing is a nonissue for any Mac since less than 5-7 years old. In any case, Haskell Platform appears to be 64-bit only on the Mac.

—
Reply to this email directly or view it on GitHub
#43 (comment).

[bgold-cosmos]

dirt-pa seems to run OK, I haven't used it much but I'll give it some stress tests. It might make my streaming setup simpler, actually.

[shawnlawson]

a dirt universal binary for /usr/local/bin or an Apple application that can be double-clicked to run?

[bgold-cosmos]

@yaxu Ugh, on further listen the portaudio version has terrible timing. Really obvious with stuff like echoing 16th notes. Wonder what's going on there...

[yaxu]

@shawnlawson I'm not a mac person but the latter sounds easier
@bgold-cosmos Yes the same happens under Linux, the portaudio, works fine under windows but seems the timing api isn't implemented properly elsewhere.

[shawnlawson]

I think the binary isn't too bad to create, it's simply adding a few c-flags to the build to make it universal (32 and 64 bit). I've built for my machine, but this may also want to be more backwards compatible aiming for 10.8 or 10.9, which may take a little digging to figure out how to do targeting on the CLI.

The annoyance I've found with apps is with Apple's security. If the app isn't released with an Apple developer key (potentially also through their portal and potentially costing an annual fee) then the OS will refuse to run it. There is a way to force run the app which requires going into system preferences's security settings. But it's not an obvious step and may hold back new users. Xcode is the easiest method of build, though it could be done by CLI.

I think an double-click-able applescript will launch a command in the terminal. Will see if that has the same security issues.

[yaxu]

Hurumph, that's annoying..

[shawnlawson]

Wrote a small bash script with the .command extension. Seems like double-clicking a file with that extension on OS X will create a new terminal window and run the script. No security issues. I need to check the if chmod +x permission adheres from user to user. Then if my dirt binary will execute on older OS's. There might still be a potential homebrew vs macports lib directory issue as well.

[telephon]

The annoyance I've found with apps is with Apple's security. If the app isn't released with an Apple developer key (potentially also through their portal and potentially costing an annual fee) then the OS will refuse to run it.

We never had the issue really with scsynth. Maybe because it is called from the IDE, which is in turn a GUI application?

I think mac users are now well accustomed to cmd-click on the application and then select open. No need to switch globally.

But yes, you may need a nibware gui to initiate this with a cmdline app.

[shawnlawson]

I think scsynth runs without issue because the entire contents of the SuperCollider.app package is "approved" to run once the user overrides Apple's default of "app is from an unidentified developer."

Generally speaking, it's a one time thing per application, and most OSS Apple users are accustomed to this extra step. It's the new users that may not be sure what exactly to do.

[telephon]

Yes, exactly. One very common way to deal with this is to tell new users what to do.