For Readers of "Designing Audio Objects for Max/MSP and Pd"
As some of you may know, I published a book on designing audio objects (externals) in 2012. Although most of the code in the book remains valid, there has been a change in the most recent Max SDK, version 6.1.4 that requires an update to all of the externals described in my book (and indeed to every third-party external written prior to SDK 6.1.4).
Put briefly, the declaration of the main() function has changed from:
int C74_EXPORT main()
Externals compiled with the old declaration will compile without error, but will not load into Max.
I have updated the book’s CDROM with new projects that will compile and load to any version of Max, up through version 6.1. The update is only for Mac, and has been tested with Xcode 5.1 on OS X 10.9.2. The same code fix should work on Windows, but I don’t currently have access to a Windows system to test it. The updated CDROM can be downloaded here:
Thanks for the update Eric. I still haven’t found time to read the book several months after having bought it however…
I downloaded the latest CD and tried the mirror~ example. While the code compiles correctly, the resulting object doesn’t work in Max. Here is everything I’ve tried:
(i) Using the old mirror~ Xcode project from the original CD with the included Max SDK. Result: Didn’t compile because I had the latest version of Max/MSP (i.e. 6.1.4) and the SDK that came with the CD was old.
(ii) Using the old mirror~ Xcode project from the original CD with the latest Max SDK (6.1.4). Result: Compiled correctly in Xcode 5.1.1 (on Mac OS X 10.9.4) with the only exception being the dsp_add warning (which, if I understand correctly, shouldn’t be an issue). When I tried using the result .mxo external in an example Max patch, it didn’t work (it wasn’t allowing audio through it).
(iii) Using the new (from the latest CD you posted above) mirror~ Xcode project with the latest Max SDK (6.1.4). Result: Same as (ii)
(iv) Using an example Xcode project (lores~) included in Max SDK 6.1.4 with lores.c replaced with the latest version of mirror.c, renaming the lores~ Xcode project to mirror~ (all these steps were followed from an earlier post of yours in another thread) etc. and compiling. Result: Same as (ii) and (iii). Note that I could compile lores~ as included in the Max SDK 6.1.4 and use the newly created lores.mxo file in a Max patch without issue.
I really don’t know what the problem could be. It’s quite frustrating. Although this may not be terribly useful, I’ve tried to attach the mirror.mxo file I generated if you think you’d like to test it on your computer. Other than that, I would be happy to try any ideas you might have.
Thanks for reporting this issue. I hope we will be able to get you on track to start using the book. Please report back here if the following does not solve your problem.
Based on your observation ii) here is what I think is happening: since you were able to load mirror~ to Max 6.1, your compile environment is probably set up correctly. As a bit of history, Max 6 had only just become available as my book went to press. I was able to put a chapter on the CDROM about writing 64-bit externals for Max 6, but the content of the book is based on Max 5. That was not really an issue for Max 6, which supports 32-bit objects, but as of Max 6.1, all audio objects need to be written for 64-bit processing. I’m guessing that that is why your compiled mirror~ loads, but does not produce audio on Max 6.1. You could try it under Max 6 and it should work.
The coding changes required to write Max 6.1-compatible externals are mainly local to the dsp and perform methods. Additionally, all float variables should be changed to double. So the long-term solution is to read the CDROM chapter on 64-bit processing, and apply those changes to the externals in the book.
The CDROM chapter on Max 6 provides a complete update to the multy~ object. Please compile and test that version of multy~ on Max 6.1. If that works, you can apply coding changes as necessary to the other externals of the book to get them to work on Max 6.1.
Thanks for the response Eric. I suspected that not using 64-bit processing might have been the problem but convinced myself against this by assuming that all versions of Max would be perfectly backwards compatible. As you point out, it looks like Max 6.1 and beyond requires audio objects to be written for 64-bit processing which, I suppose, is a good thing. Anyway, I first tried compiling and using the 32-bit version of multy~. It compiled but didn’t work, as expected. Then I tried the 64-bit version of multy~ (with the int main declaration appropriately modified) and, sure enough, it worked perfectly. Converting the rest of the examples to 64-bit shouldn’t be a problem with your guide included in the CD.
I look forward to reading the rest of your book which, so far, looks to be a useful resource for Max/MSP novices. I appreciate your prompt help. Keep up the good work.
Thanks for posting this update! I’m slowly getting the hang of things, just working my way through Chapter 3 for the umpteenth time ;-)
I just spent 3 hours trying to run a 64 bit updated version of multy~. My method here was to create a new Xcode project for creating the external with a different name (cm.multy~ in my case). The external would compile, but wouldn’t load. Until I realized that I need to update the first argument in the class initialization in the main function (from "multy~" to "cm.multy~"). If this doesn’t match the external name in the project settings (product), the external will compile, but won’t load in Max.
I’m sorry if that sounds random, but I thought I’d share this insight, in case another noob like me falls into the same trap. Just to save some frustration. And you don’t mention it in the book, at least not in the first chapter where I think it would be most helpful.
Apart from that, I love the book. I just recently completed a self-study C course just for learning to program externals, and from this perspective, the book is extremely well written.
I am glad to hear that you are finding the book useful. Thanks for mentioning the point that the object name in the initialization routine must be consistent with the project name. I didn’t expect readers to be renaming objects until after they had worked through all the book examples, at which point, having seen multiple initialization routines, it should be clear how the name is set. That’s an advanced topic, but you jumped in early!
It’s really helpful for people to bring up issues with the book as they arise. I’m going to keep links to relevant forum discussions over here.