Nice interview with good insights and the usual BS-less comments.
Very nice read!
Yes, I truly admire the BS-less-ness. Inspirational!
Thanks ! Good to read !
Very nice read indeed, inspirational indeed!
In fact It made me turn back to the factory original firmware for my Tides, Clouds and Peaks reminding me the true reason that made me buy them: The original modules! No hacks no alternates!
Thank you Olivier!
O&C mentioned in dispatches.
Japanese, then English.
Awesome! I’m particularly intrigued by the bit on prototyping/testing core module functionality on PC. (But not surprised, given how well written/configurable/modular/platform-agnostic the code is… I was able to take the reverb from Elements, change it to 32-bit, and apply it to the VST I was working on with next to no effort.)
Does anyone know is Olivier has elaborated on his setup for this elsewhere?
Or perhaps he would be willing to share more details… though I understand if a magician doesn’t want to reveal ALL of his secrets (since Olivier has graciously shared so many already).
Which details would you like to know?
There’s not much to it… textmate or vim depending on the mood…
make -f module_name/test/makefile && ./module_name_test… Audacity to play and inspect the generated .wav files; or sometimes python scripts to plot specific things. All kind of things exercising the DSP code in the “test” code.
While we’re at it: How do you measure CPU load on the final module? I have been using a pin and a scope so far. Set the pin to low on the beginning of the DSP routine, then to high at the end and inspect it with a scope. I’m sure there are better ways of profiling, though.
That’s what I do too, it’s not even a secret. I set the scope to display the duty cycle %, and show the waveform with persistence so that I can visualize the variability.
PC sampling would add overhead and wouldn’t provide such a nice real-time display. I’ve actually shown this to friends working on desktop or server-side software and they were jealous!
Thanks Olivier! Not sure how I’ve glossed over all the “test” directories in the repository thus far…
I guess I wondered if you had some system to run code in real-time on the PC, like a VST wrapper or something with the new Matlab audio system toolbox… though I guess this wouldn’t make sense for quite a few modules.
I tried wrapping Clouds’ code in an AudioUnit, but this was a strange middle ground - this was not good for very “technical” testing (which really requires programmatically generated CV and trigger patterns), and not good either for “musical” testing (which really requires hands-on interaction with the module and a couple of other modules).
nice read! i am happy to see modules with less hidden features, also i have to admit, it would have been easier to handle all those functions if i would have stopped buying new modules, befor i handeled the old ones properly (-: