As software projects go, PaulStretch is rather a shadowy enigma. Since I did the initial Mac OS X port, I’ve had very, very sporadic communications with the author Nasca Octavian Paul about it.
Then there’s the issue of versioning. Paul started a github repository, but it hasn’t been updated since March. It’s currently at version 2.2.2, but the only difference between 2.2-2 and 2.2-1 is that the version number it reports has changed.
At any rate, today I did a new build which is 1) OS X 10.6 (forward compatible with Lion, but perhaps not backwards compatible to Leopard or Tiger) 2) Up to date build, incorporating all of Paul’s changes. I also spent some time playing with it to make sure it works properly.
It also has the latest refinements of the build scripts used to build PaulStretch from source. I use CMake, which is Kitware’s cross-platform build tool. CMake keeps getting smarter, and my CMake recipe for PaulStretch will download all the prerequisite libraries, build them, and then download the PaulStretch source, build it, and generate an Apple App Bundle.
And CMake really is cross-platform — the same build recipe will work unmodified on Linux (which I have tested) and possibly on Windows (which I haven’t tried).
The world of open source software development doesn’t sit still. A program that I rely on to build PaulStretch on OSX is CMake, which is an open source, cross-platform program that hides some of the complexity of building software on different platforms.
If you’ve built any software on OS X or Linux you’re probably familiar with the “./configure ; make ; make install” method of working with source packages. CMake does that but it goes out of its way to handle the low level crap that is a pain in the ass to set up program configuration with autoconf. On top of that, it will run on any Unix, OS X or Windows. And on top of THAT, it will generate Makefiles, or project files for any of the commonly used integrated development programs like Visual Studio (on PC) and XCode (on Mac).
CMake really is as close as you can get to ‘write once, run anywhere’ in the world of C and C++. Not that there won’t be platform-specific stuff you’ll have to do, but it’s a lot easier and more concise in CMake.
Anyway, as of CMake 2.8, there is a powerful new CMake Module called ExternalProject. It automates downloading, configuring and building open source packages. I’ve used ExternalProject heavily in my day job, so it seemed natural to use it to streamline building PaulStretch. The result is maybe just as complex as the original build setup, but it is a lot more robust. Reading through the CMakeLists.txt files I’ve set up will be a good introduction to how things work in CMake — I’ve done a bunch of things in there you’ll want to know how to do for your own projects — use ExternalProject_add to download and build libraries, do some platform-specific configuration, create an executable, etc.
You can download the new PaulStretch Build package here: http://www.cornwarning.com/xfer/PaulStretchBuild-2.1.tar.gz
The instructions are pretty straightforward:
0. Make sure you have the compilers and development libraries installed on your system.
1. Download the Tar file
2. unpack the tar file, somewhere you have write permission.
3. Run PaulStretch/BuildPaulStretch.sh
On OS X, this will create a paulstretch.app, that you can drag and drop wherever you want. On Linux, the executable will be in bin/paulstretch — it’s statically linked so it will run without needing anything besides the program file on your system. Or, for that matter, any other compatible Linux distribution.
The result is an executable program in whatever directory you’ve run this process in. The following commands would accomplish this whole process in a directory called ‘PaulStretch’ in your home directory.
mkdir -p ~/PaulStretch
curl http://www.cornwarning.com/xfer/PaulStretchBuild.tar.gz | tar xzf –
After running these commands, on OS X your PaulStretch program will be ~/PaulStretch/paulstretch.app. On Linux, it will be ~/PaulStretch/bin/paulstretch.
As an added bonus, I took the time to try building on a couple of different Linux systems, to verify it works there.
Once again, what will trip up the non-software-developer types in this whole process is step 0: making sure the dev tools are available on your system. That’s something I’m not going to explain here. Google it. You’ll need GCC installed, all the development libraries, and on Linux the development libraries for libasound — the ALSA sound library.
If you happen to be a Windows developer, you could take a crack at building using Visual Studio or MinGW. The CMake build files are theoretically portable, but you’ll have to download CMake for Windows (here: http://www.cmake.org/files/v2.8/cmake-2.8.3-win32-x86.exe)I haven’t done this, because I avoid doing development work on my Windows machines at home. If I’m at home, and farting around on the computer, I want to be able to just use music software, not build it. Plus you can download the Windows version of PaulStretch here: http://sourceforge.net/projects/hypermammut/.
Let me re-iterate again — I don’t want to be tech support for this — if you can’t figure out from this post how to use what I’ve put together, you probably shouldn’t even be trying to build it yourself. Ask your kid nephew who’s a big H4X0R to do it for you.
This will be my last post on the subject. It’s been fun to get a lot more site visits, but just for perspective, my friend Jerry’s Retarded Ravers Of America site was getting ten times the traffic ten years ago that my blog does today. It also feels a little weird riding Justin Bieber’s coat tails to this new level of web notoriety. As it happens the PaulStretch OS X posts consistently generate more traffic than anything else on this blog, which puts me in my place–doing a port of PaulStretch may be my most enduring Internet legacy, even if I wish I was known more for my own music.
Anyway, as regards the “Love U” stretched version, there was some speculation that it was a hoax, and then some speculation that the ‘group’ claiming they’d made the track themselves was itself a hoax. I decided to investigate, and came to these conclusions:
It was, in fact, produced using PaulStretch, perhaps even using my OS X port
The actual slowdown was actually on the order of 10x
It was pitched down a little more than a half-step.
Either it was MP3 encoded at a low quality/bitrate, or slightly lowpass filtered. My version (which is encoded from the raw output of PaulStretch) sounds noticeably brighter.
Well, someone may — or may not — have posted a slowed down version of Justin Bieber’s “Love U” and as a result my janky little blog is experiencing a 25-fold bump in traffic. I’m hoping the fine folks at Midphase don’t mind — I have an ‘unlimited bandwidth’ account, but I think it’s only unlimited until you start saturating their net connection.
Anyhow, if you’re here looking for Paulstretch, get it from this post — the new build can actually load MP3 files due to a new version of one of the libraries it needs. If you’re still on a Power Mac, go here.
The build scripts are Here, but don’t even bother unless you are an actual programmer, because I can’t troubleshoot your problems for you. What I wrote worked perfectly from a standing start back when I wrote it, but library versions change, source code archive links get moved, and you may not have all the build tools on your machine.
Let the stretching begin! EDIT: I listened again to the example I put up back when I first started playing with Paulstretch and I still really dig it. It’s the Bitone Troupe’s cover of Björk’s “All Is Full Of Love.”
This is supplied with no warranty, express or implied, and no doubt, it will NOT run on some PowerMacs. I have no idea how binary compatibility works OS X and the PPC chips, except that it does not, as Apple is wont to say “just work.”
Again, if you download either of the disk images and they do not work, feel free to follow these instructions in order to build things for yourself. According to the aforementioned Anonymous Benefactor — the instructions do, in fact “just work.”