With a PhD thesis on guitar amplifiers with IRCAM and 10 years experience in the audio software industry it’s easy to see why Ivan Cohen was the developer for the job when it came to the complexity of the DSP module in JUCE 5.1.
Ivan Cohen is currently a consultant for audio companies that require freelance plug-in developers. Ivan is predominantly a DSP Developer with an interest in audio effects algorithms and analog modelling. We sat down with Ivan to ask him a few questions about his work and future aspirations. Check out his work at http://www.musicalentropy.com/ and http://musicalentropy.github.io.
Who are you, what do you do?
My name is Ivan COHEN, I'm a freelance developer since 2013, and a JUCE user since 2003 or something ! I discovered it back in these days because I was a Tracktion version 1 user, the DAW Julian Storer designed, and I heard that the SDK Tracktion is based on became open source. That's how I get started with JUCE.
My main occupation today is doing consulting jobs for audio companies which need freelance plug-in developers, 95% of the time involving JUCE. I do also a lot of DSP for these guys since I have a lot of interest in cool audio effects algorithms and analog modeling, thanks to my PhD thesis about guitar amplifiers simulation made with the IRCAM and the french company Two Notes in my previous life.
What does your company do?
I do not own a company yet, it's in my plans to create one in 2018. Right now I have the status of « auto-entrepreneur » in France which is basically allowing me to work for other people. But I will release very soon my own commercial plug-ins, under the brand name Musical Entropy, that I have used already to release a few freeware plug-ins during events called the KVR Developer Challenges.
You worked with the JUCE team on the DSP module. What are you most proud of in the module?
Well, I think I'm mostly proud of the Convolution class since it's one of the most complicated thing I have ever coded, both in terms of pure DSP and organization of code + handling of threads. I wanted to write something with an API very minimalistic and easy to get which handles a lot of tasks under the hood to prevent the appearance of any audio artefact and to allow impulse response changes without any audio interruption. Then, I have to add the Oversampling class as well because basically I designed all the other classes (linear algebra, filter design) just to be able to have in JUCE a class for oversampling which doesn't rely on anything from the outside and as customizable as wanted.
What was your experience working with the JUCE team?
It was great and very surprising! I thought initially that I wasn't a developer that bad, trying to follow the JUCE coding standards as much as I knew them. But everybody in London was so much better, with a lot of knowledge about C++11 and C++14, ways to solve easily problems that I have to bear painfully all the time! Fortunately, Fabian told me it's normal to feel that way around Julian, and that he had to wait some time himself to start feeling better about his code in the JUCE team.
Anyway, I have learned a lot of things on the process, I can say that my every day code is already better thanks to that experience and having the guys answering in the real life my questions. I feel lucky for having met the new members of the JUCE team as well and for being able to work in the amazing Fxpansion headquarters, and for having been a part of all the talks we had there about what is the best for the DSP module.
What would be your advice to someone who's just getting started with JUCE?
A great part of JUCE today is the amount of locations to get information about how to get started. There are the example projects, the documentation on the website, the JUCE forums, the Projucer templates, even some videos… My advice for a newcomer would be to get the Projucer on the website, to try to get used to generate projects with it and add new code files inside. Then, he should follow one of the website tutorials, and have a look for all the information he could on the example projects, such as the JUCE demo application. I'm still copying and pasting code from this specific project when I need to learn how to do something.
What features would you like the JUCE team to work on next?
My main concern with JUCE nowadays is how the SDK handles graphics cards acceleration. I would love to see more work done on the OpenGL wrapper, and some support for other rendering engines like Direct2d/Direct3d for Windows, and the new Vulkan and Metal.
What can you tell us about your next plans?
Next year, my first Musical Entropy commercial plug-in will be released – using JUCE obviously. I can't tell anything about it yet, but it's the first part of a plan, about bringing new ways to do computer music. A lot of musicians, producers, sound engineers feel the same way than me, they think that most of the computer music software design is based on old paradigms, inspired from real analog mixing consoles, and that something needs to be done to help composers have fun with computers while doing creative tasks. I would say that this my main focus. And of course, I would like to continue working for other people on projects I'm interested in.
To learn more about Ivan’s work you can rewatch his talks from the Audio Developer Conference, Ivan has delivered talks for the past three years, available here: Virtual Analog Audio Effects Simulation with JUCE 2015, Digital IIR Filter 2016, Fifty shades of distortion 2017.