A History of the Solaris

[John Bowen]

In the Facebook group called Solaris Synth, I've posted a bit on the 'history' behind the current Solaris product. I thought I'd post the discussion here for those who have not joined the group there, just for interest:

Post #1
John Bowen on April 18, 2009 at 10:59am
The Solaris was first developed as a DSP plug-in for the SCOPE platform from Sonic Core (formerly Creamware). It started out as an advanced version of my first plug-in, the Orion (the new plug-in was originally going to be called 'Orion Custom EX'). I had modified and extended the original Orion structure so much, that while in beta testing, I decided it would be better to name it as a new product. I introduced the Solaris plug-in January 2003.

Being in constant communication with the users of my products, over time I incorporated even more features that were either requested by the users of the DSP plug-in, or came to me in thinking about what else I'd do to expand the plug-in's functionality. After 5 years of this development, I decided that a hardware version, with superior sound quality and usability compared to the plug-in, would be the next logical step.


Post #2
Sven Hauck (Netherlands) wrote on April 26, 2009 at 2:18am
I think we all get the bit on why the sound quality should be paramount, from having listened to software synths where the developers had to cut corners to make them run on a large number of host computer systems. Can you give us an idea why you also placed equal importance on the usability of the Solaris? What can the future owners expect in terms of usability?


John Bowen wrote on April 30, 2009 at 10:45pm
Sven,
I wrote a rather lengthy response....hope that's OK.

When I started, synths had a fairly limited number of controls and parameters. The Minimoog had 27 knobs and 10 parameter switches. The Prophet 5 has 26 knobs in total, and 22 parameter switches.

With the advent of digital control, things got a lot more complex. The DX7 was most people's introduction to digital synthesis with lots of parameters, and as I see it, Yamaha had an easy choice - provide controllers for each parameter, or simplify things to the extreme, and allow editing of one parameter at a time. Obviously, it wasn't attractive or practical to have a front panel with tons of knobs (although there was a German company who showed such a controller panel for the DX7 at a Frankfurt Messe long ago!). Economics also demanded that the interface be simple, and this has continued to this day.

The problem with an interface like this is that it becomes rather daunting to grasp the form and function of the synth engine. Thank goodness Yamaha had Gary Leuenberger and Dave Bristow, professional musicians and programmers who were able to coax an incredible set of factory sounds for the DX7's debut. Very few sound designers took the time to delve into programming this synth, which created quite an 'after-market' for instructional books and preset sound library sets. Here's a quote from vintagesynth.com regarding the book, 'The Complete DX7 by Howard Massey': "Since hardly anyone knew how to program their DX7, you'd end up with the same presets used on every single album throughout the 80's. They should all have read THIS book."

I didn't get involved with digital synthesis until we started working on the original OASYS prototype at Korg R&D, from 1993-1996. Prior to that, we had developed the Wavestation, which was also fairly complex, although not really a digital synth. I had done a UI (User Interface) with a menu system approach for the Prophet 3000, and took a lot of that design into the Wavestation UI. I was fairly happy with how the Wavestation turned out, considering all of the layers of complexity it had, but obviously, it could have been better.

After I left Korg for Creamware, I found myself enjoying the absolute freedom of designing synthesizers in a software environment using the Scope SDK, both for the functionality as well as the surface design. The User Interface was so much more flexible - I was able to experiment with different ideas, try different interface approaches, and really go crazy with lots of options and so on, things that would have never been practical to do in hardware. And that is the great advantage to all of the software synth products out there now.

As I developed my Scope plug-ins (after leaving Creamware to start my own business as Zarg Music), certain design ideas remained consistent. In wanting to keep a standard approach to the UI layout of the early hardware products I'd worked with, I would set things up in a familiar structure that could be expanded upon without disturbing the 'left-to-right' flow of the signal path too much. The Solaris plug-in was an outgrowth of my first plug-in, called Orion, and it contained many of the ideas I had developed up to that point. With the layout arranged such that I could fairly easily expand each section, the Solaris plug-in managed to grow over the years (from 2003 to 2008) to have many different oscillator and filter types, as well as numerous LFOs, envelopes, and so on.

With this particular layout, I had kept it in mind that someday I might be able to return to hardware design, and so it was after some years as a plug-in that I decided the Solaris would make a pretty powerful hardware synth. Because it had grown to over 1000 parameters in the most recent version, I had to figure out how I was going to handle all of these in a way that still followed a functional layout, so that the user could grasp what was going on in the basic synth engine and signal path. I wanted to avoid layers and layers of sub-menus (as I had used for the Wavestation), but still provide the complexity the Solaris had become. The only way I could see was to provide multiple displays, breaking it into 5 or 6 groups of parameter control.

I asked Holger Drenkelfort and Juergen Kindermann to do the engineering for me (this was before Sonic Core existed), and we started by seeing what was the widest text display available. Once we found that, we determined that it provided optimal room for 5 knobs across, so I then had to reconfigure all of the sections of the UI to fit within a 5 knob layout. This was more challenging then I had expected! I still needed to have a number of 'pages' within each display, but at least the parameters were arranged across the surface in a somewhat logical signal path, reducing the complexity and providing the programmer a faster overview of the sound engine.

The other main thing that I wanted to keep in mind was that the Solaris needed to be easily expandable, without having to add new knobs or switches, and without the need to figure out some special key combinations (like Shift and Filter Select) to get to new functions or parameters. I think we've accomplished this 'future-proofing' with the current UI of the Solaris keyboard, and I hope the users will agree, once they've had some time to spend with a unit.

[francois]

Thanks John. You can change 'brief' to 'long' when you want to