Corpora Sonorus Blog

There is a new version of my Corpus-Based Processing Software available...

CBP_version_0_1_BETA2_app.zip

You can read more about it at the (currently untitled) research/software page!

The most significant updated feature is the fact that it is now available as a standalone application for Mac OS X.

Another (significant) update is coming in a few days...

I think that it's important to share my roadmap for development, at least in the near-term, so that potential users realize that this software is intended for real use and is not just a proof-of-concept:

1. Develop support for standalone versions (done)
2. Upgrade and fix import and segmentation (almost done: everything works despite a significant flaw in the design)
3. Develop support for Audiosculpt marker files (done, will be in Beta version 3)
4. Improve documentation and general web site material
5. Develop and clean up search/interaction methods
6. Develop more resynthesis/playback methods
7. Develop Windows versions (shouldn't be hard, except I have no access to a Windows machine at the moment)
8. Develop simple integration with DAW software using Soundflower (or Jack, ReWire, etc.)

Some other things on the back-burner, but still very important:

• Video Integration: This would be a great way to test the idea that a unit can point to any snippet of media, not just audio. The content and a lot of the meta-data would be different, but there could certainly be isomorphic (one-to-one) mappings between audio and video.
• Implementations in SuperCollider (and, eventually, beyond): It would be good to tap into the pattern processing powers of Supercollider. There is already an extension called "Geography" developed for SC3, which could form the model for a simple, efficient port. I suspect that a SC3 implementation would be fairly simple, efficient and straight-forward...
• Funding and other support: I am looking for funding and people who are interested in supporting or getting involved in development. While the current version of this software (and most of the software it is directly based on) is released under GPL licenses, this fact does not rule out a future version that is completely redesigned and developed into a commercial product. It also does not prevent me from earning some money developing customized software to earn a living or receiving grants or teaching or consulting or... Feel free to contact me!

The Jamoma system has been under constant development for quite a while. It works quite well in its current implementation in Max 5. One of the things that would be nice to do is make a standalone version of your patch, even if it is full of Jamoma modules. With the help of the jamoma-users mailing list and some experimentation, here's how...

1. Make sure that you have the latest version of Jamoma and Max 5 installed. As of [today] they are 0.5.17beta and 5.0.7, respectively.
2. Make a patch that contains some Jamoma modules. In the test example I use jmod.noise~ with audio connections to jmod.output~. I also include the standalone object, which is necessary so that Max knows to include helper files. Make sure you check the "Audio Support" box! The other settings are covered in the documentation.
3. Save the patch.
4. Select "Build Collective / Application" from the File Menu in Max. A window appears, with one line in the text area: "open thispatcher". The default behavior is to wrap up the currently open patch into a collective or app.
5. For a patch including Jamoma modules, there are a few more files that you have to include. FIgure 2 shows the Build window for your application.
6. I included the main patch, the Jamoma folder (via "Include Folder..."), the jamoma jcom.loader and jcom.remote (both via "Include FIle..."), and finally a folder called "lib" that contains any subpatchers and other files that are needed by my patch. [In this simple example there are none, but you may need it. See the notes at the end.]
7. At this point you are ready to make the app, but first you should save the script as a text file in case you ever need to run it again.
8. Click "Build". From the Save Dialog, find a place to save your app, either alongside the patch, or somewhere else. Make sure you choose "Application" as your Format!
9. The final step consists of copying the Jamoma frameworks to your new app's Package Contents. Digging around in an application's Contents folder is not too hard, but its something that you may not do that often. To get to the Contents folder, first locate your new app. Then right- or control-click it and select "Show Package Contents" from the pull-down menu. A new window should appear.
10. Every application that you build in Max will have the same basic folder structure. Figure 3 shows the structure of the Contents folder of the app I just created, with some of the folders expanded so you can see the structure better. We will be adding to the Frameworks folder in a minute, but first take a look around. The patch itself has been rendered as a .mxf file (see the notes). There are 2 executable files, one with the name of the patch and one called "MaxMSP Runtime". These are basically a portable, read-only version of Max. The resources folder has a couple icons that the OS may need. The support folder is basically a stripped-down version of the Cycling '74 folder in the regular Max folder.
    
11. In a separate Finder window, locate the YourHardDrive:/Library/Frameworks folder. This is the Library folder that sits on the top level of your hard drive, not the one in your Users folder. Here there should be a Jamoma.framework, a JamomaDSP.framework, and a TTBlue.framework. Copy these (option-click-drag) into the Frameworks folder of your app. If I understand correctly, the TTBlue framework is or is about to be fazed out.
12. Now you are done with a basic application build. Open your new app and take it for a spin. Then read some of the notes below...

Notes:

1. There are cases where I needed to add externals to a folder called "externals" that I had to create inside the "support" folder. There will soon be a post detailing the creation of a standalone that uses both Jamoma and IRCAM's FTM libraries.
2. If economy is your thing, then there are certainly ways to save space in your applicaiton. A future post will include strategies for optimization: files that can be left out when not needed. One obvious one is the Jitter framework that is automatically copied into the frameworks file by the standalone script. If you have no video in your patch/app, then there is no reason to include the Jitter framework.
3. This only works for Mac, but there should be a similar way to do this in Windows. A Mac app created with Max 5 on an intel machine should work on a PPC machine and vice versa. However, downloading the patches and attempting to open them in Max 4.6 or earlier will never work.

Stupid Mac Trick #1:
Adding/Editing Aggregate Devices in MacOS Audio MIDI Setup

In order to get audio to go between two applications: in my case, Logic and MaxMSP, there is a well known solution: Soundflower and an Aggregate Device (in Audio MIDI Setup).

What's less known (or seldom fully explained) is the fact that in order set up a new Aggregate Device, one must launch Audio MIDI Setup as the "root" user.

1. Using Terminal, type 'sudo /Applications/Audio\ MIDI\ Setup.app/Contents/MacOS/Audio\ MIDI\ Setup'

2. Supply your root user password. If you do not have one, follow these directions: http://support.apple.com/kb/HT1528

3. Audio MIDI Setup should launch. Some signs that it has been launched by the root user: it should pop up in the upper left corner, and there should be some options available that you are used to seeing grayed-over.

4. Make your new Aggregate Device(s) and quit the program before you screw something up.

5. At this point, you are no longer logged in as root (so nothing unexpectedly bad can happen 20 minutes later). You can now select your new aggregate device in the Audio MIDI Setup program or whatever program you need to use...

Notes: This process is cobbled together from forum posts and other helpful websites after spending some frustrating time trying to figure it out. The best part is that I know that I did this once before over a year ago, so now I can look here and remember when I forget again next year.

corpora = bodies, and sonorus = sound, in my creative interpretation of Latin.

These two words have very rich layers of meaning. Sonorus is somewhat self-explanatory. Corpus (the singular form) can refer to: the sounding body of an instrument, the human body as instrument, the internality of the space in which sound is experienced (e.g. the concert hall, the recording studio, or even a virtual space); or the term can refer to a collection of sounds grouped together as material for composition or improvisation.

Generally speaking, it is these collections that one works with (in the digital realm), and the term corpus-based sampling collectively refers to the whole process of storing sounds and data, searching and retrieving those sounds, and creating music out of such materials. The germ of the idea comes from several software projects (look at the links page), and through my work, I plan to build on these ideas, both in the narrow sense (by making software) and in the broadest sense (by exploring and extending the underlying concepts and theories...