Today I released my first sound making app for iPad!
WaveShaper is an app for iPad that allows you to load up any audio file and make crazy cool sounds with it. It’s a lot like record scratching, but totally maxed out. This video will do a much better job of explaining it than words ever will:
Visit waveshaperapp.com for more info, sound samples, and screenshots. Or just go buy it right now!
Things have been quiet around here, but hands have not been idle.
Anderson Mills has been hard at work on features for the next release of Minim. His project at Numediart to build a Unit Generator framework for Minim has made fantastic progress. On Tuesday, we plan to merge these changes back into the main Minim repository and release a Beta build. As usual, documenting is the hardest part of the job and we wanted to give people the chance to work with the new music programming features while we chew through that.
Meanwhile, I’ve created an app for the iPhone with Heather Kelley and Amanda Williams that is currently part of an art show in Hong Kong called Technosexual Bodies. The app is called Body Heat and I will be posting more news about that soon, I hope.
Finally, as hinted at in my previous post, I started work on a C++ port of Minim. It’s only in the beginning stages and it’s only functional enough to be useful for the iPhone app, but you are welcome to have a look at the repository. I’m making no promises about when the port will be finished, only saying that it will be finished at some point. If you’d like contribute to the port, make a fork at Github and have at it!
So I’m porting the graph packages from Ptolemy II to C++ and I’ve finally gotten to the point where I can unit test some of it. I was going to start writing tests for the Graph class but when I ran the suite I got errors about some missing implementation in the graph library. A couple of those were methods I did actually miss, but one of them turns out to be the result of multiple inheritance. When you read about multiple inheritance there’s always mention of the dreaded diamond. Well, after sketching out the inheritance tree I’ve discovered I have a case of the dreaded double diamond!
This is what the Java inheritance tree looks like. However, it should be noted that all of the Analyzer classes are Java interfaces, which means it makes perfect sense in Java. However, porting this over to C++ is a bit stickier. My initial response to it was “this is silly”, so I broke the Analyzer-Strategy connection and the CachedStrategy-GraphAnalyzer connection. This prettied things up quite a bit. However, now it’s come back to bite me in the ass!
Analyzer defines a pure virtual toString() method. CachedStrategy implements a virtual toSting() method but it is not overriding Analyzer’s because it is no longer deriving from Analyzer. SelfLoopStrategy also implements a virtual toString() method and I thought that this would work not only as an overriding method for the implementation in CachedStrategy, but also as the implementation required by Analyzer. But this is not the case. As it happens, elsewhere in the code, toString() is invoked on a GraphAnalyzer and it doesn’t know where to find the implementation. This makes sense after reading about the subtleties of multiple inheritance. The question I am faced with now is whether I want put the double diamond inheritance scheme back into the C++ code. It makes me a little uneasy is all, there’s this little voice in my head saying, “there’s got to be a better way!”
If I was to use the double diamond, I’m pretty sure the way to handle it would be for Strategy and GraphAnalyzer to inherit Analyzer virtually and then for CachedStrategy and SelfLoopAnalyzer to inherit from GraphAnalyzer virtually. This would give SelfLoopStrategy the responsibility of calling the constructors for GraphAnalyzer and Analyzer. Oh multiple inheritance gurus, have I got that right? Is there a better way?