GTK @ 10 years

August 15th, 2011

Computer music is a discipline that has always relied on people sharing the software tools they create with the larger community. There are many well known examples: Max Mathews & MUSIC, Barry Vercoe & Csound, Miller Puckette & Max/PD, Tom Erbe & SoundHack. Although my own contributions have not had nearly the impact of these gentlemen, I like to think that I have made a small contribution to the community over the years through this website.

By far, the most significant piece of my overall contribution has been the Granular Toolkit.  This collection of Max objects and abstractions was born 10 years ago during a summer research grant that I received during my graduate studies at Northwestern. The plan from the very beginning was to build a useful collection of high-level granular effects and low-level external objects, then give them away for free from my website.

What I got back from the Max/MSP community was amazing! I have met so many great people, heard so many great pieces and read about so many great projects that used the toolkit over the years.  I have also had a few professional opportunities come my way, such as the Hipno plug-in collection.

Although the Granular Toolkit is still working 10 years later with only a few tweaks along the way, new developments have admittedly been sparse these last few years. The toolkit never fully took advantage of some of the big innovations in Max along the way, such as [poly~] or attributes. The biggest reason for this is that I have honestly not always been able to make the GTK a top priority because other projects have demanded my time. I have also tried to maintain the toolkit primarily by myself, which was not easy in retrospect.

Second, the source code for the externals was not designed to maximize the benefits of object-oriented programming.  I was an admittedly naive programmer when I developed the GTK, having learned Java just two years prior to the start of development and teaching myself C as I went along.  Changes to these externals would now require some major surgery on the code to get new features working.

Lastly, the GTK is heavily tied to the Max environment and there is almost no way to use the code in the externals apart from it.  As much as I love working in Max and think it has a long life ahead of it, it would be nice to have the freedom to use my code as the basis for projects in other host environments such as DAW plug-ins and mobile apps.

Over the past several months, I have been taking steps to address these three issues by getting involved with Jamoma, an open-source platform for art and computer music projects that I believe addresses the three issues I outlined with my own GTK:

  • Jamoma exists as a software library that can work within the Max environment, but it also has hooks into other host environments and programming languages (things like Ruby, AU, VST, & PD) without being tied too closely to any one of them.
  • The code makes use of object-oriented design patterns so that it can be more easily updated as changes are dictated by the circumstances.
  • Perhaps best of all, it has attracted a growing list of talented developers from around the globe who are collaborating to ensure that the project is continually maintained.

So I am writing this blog post to announce that GTK will eventually be superseded by new granular components in Jamoma.  While this work is still in its early stages and no release date is immanent, I wanted to put the idea out there for public consumption and comment.

What has already happened?  In November 2010, Tim Place and I had a brainstorming session during his visit to Stetson.  We developed an outline of how to merge my granular work into the Jamoma DSP framework and began laying the foundation for this goal in January.  This meant working on boring things like window functions and buffer support. It’s not very exciting stuff, but it is necessary to support our concept for these improved granular operators.

What is happening soon? Although the Jamoma team completes significant work via email and web services, they occasionally get together for face-to-face meetings. In October 2011, I will be joining Tim, Trond Lossius and Nils Peters for a Jamoma Workshop in Kansas City. This will actually be my first time meeting Trond and Nils in person and I look forward to seeing what progress we make as we put our heads together for three days.

What is happening now? After giving it some thought, I am releasing the source code for the externals in the GTK collection under a BSD license. This will help ensure that if folks absolutely need to maintain these objects, they have the materials to do so. Of course, the abstractions have always been “open source”, as one only needs to unlock the Max patches to see how they are built.

So what are your thoughts?  Are you a GTK and/or Jamoma user?  What are some advantages/disadvantages you see as part of these changes? I welcome your input and look forward to keeping you posted on the progress via this website.

A screenshot from a GTK abstraction

5 Responses to “GTK @ 10 years”

  1. [...] will involve significant updates to my previous work with granular processing (plans that I have previously written about here).  I’ll be working closely with Trond Lossius, who works at the Bergen Center for Electronic [...]

  2. Is this something I can do something about?

    phasor.shift~: unable to load object bundle executable
    2013-08-06 16:11:12.747 Max[3850:c07] Error loading /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/phasor.shift~.mxo/Contents/MacOS/phasor.shift~: dlopen(/Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/
    ift~.mxo/Contents/MacOS/phasor.shift~, 262): no suitable image found. Did find:
    /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/phasor.shift~.mxo/Contents/MacOS/phasor.shift~: no matching architecture in universal wrapper
    grain.phase~: unable to load object bundle executable
    2013-08-06 16:11:12.761 Max[3850:c07] Error loading /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.phase~.mxo/Contents/MacOS/grain.phase~: dlopen(/Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.phase
    ~.mxo/Contents/MacOS/grain.phase~, 262): no suitable image found. Did find:
    /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.phase~.mxo/Contents/MacOS/grain.phase~: no matching architecture in universal wrapper
    train.shift~: unable to load object bundle executable
    2013-08-06 16:11:13.431 Max[3850:c07] Error loading /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/train.shift~.mxo/Contents/MacOS/train.shift~: dlopen(/Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/train.shift
    ~.mxo/Contents/MacOS/train.shift~, 262): no suitable image found. Did find:
    /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/train.shift~.mxo/Contents/MacOS/train.shift~: no matching architecture in universal wrapper
    grain.pulse~: unable to load object bundle executable
    2013-08-06 16:11:13.470 Max[3850:c07] Error loading /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.pulse~.mxo/Contents/MacOS/grain.pulse~: dlopen(/Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.pulse
    ~.mxo/Contents/MacOS/grain.pulse~, 262): no suitable image found. Did find:
    /Applications/Max 6.1/Cycling ’74/externals/GranTK_1.49mac/externals/grain.pulse~.mxo/Contents/MacOS/grain.pulse~: no matching architecture in universal wrapper


    Sorry for the mess. I tried to find an email address but couldn’t.


  3. My apologies. My MAX installation was opening in 64-bit mode in spite of the Open in 32-bit flag being set in Get Info. Again, sorry for the noise. …edN

  4. Ed –
    Thanks for the comment. As you have figured out, my GTK externals are not compatible with the 64-bit version of Max 6.1. You will need to launch in 32-bit mode, the process for which is described here.

    I am not sure when/if I will update these objects for 64-bit. I am trying to keep my development efforts focussed on Jamoma these days. The source code is available here if you know what you are doing. I suppose I could move to Github if some are interested. Is that of interest?


  5. Ed (and others who might hit this old post):

    If you are still interested in using the GTK objects in 64-bit mode, I have now migrated my externals to GitHub. Visit the project page for download instructions.


Leave a Reply