Analysis & Iteration: The UVI Development Story

Attack editor Greg Scarth talks to UVI developers Olivier Tristan and Remy Muller to discover how they created their flagship virtual instrument, Falcon.

With a history stretching back over 20 years, UVI is one of the longest-established players in the competitive field of soundware. We spoke to lead developer duo Olivier Tristan and Remy Muller about their work, including the development of their flagship virtual instrument, Falcon.

 

Attack: First of all, let’s start with a bit of background. Can you introduce yourselves and tell us the quick version of the UVI story to date? How did you arrive where you are now?

Olivier: My name is Olivier Tristan, I’m a lead developer at UVI. I started here 13 years ago – it was my first job, actually. I was already doing some computer music and had a computer science degree; I came across an ad for a position at UVI and that was it, I’ve been here ever since.

Remy: My name is Remy Muller, I lead R&D at UVI. My first job was at IRCAM where I stayed for six years working on quite different projects, from gesture analysis for dance to refactoring IRCAM’s Spatialisateur from a huge collection of Max/FTS patches and externals into a modern C++ library. I’ve also been involved as mdsp from the smartelectronix group. I left for UVI because I wanted challenges on a bigger scale. I’m both deeply curious about research and strongly interested in making user-friendly applications from it.

The UVI story is longer than most people realise. The company was founded 20 years ago and originally focused on developing sound libraries for hardware samplers

Olivier: As far as the UVI story, it’s longer than most people realise, I think. UVI was founded 20 years ago and originally focused on developing sound libraries for hardware samplers. From there we expanded to software development with the UVI Engine, but still kept a focus on sound libraries with the PlugSound series and others. PlugSound was actually one of the first sample-based virtual instruments, with six versions aimed at different instrument types including keyboards, strings, drums, synth, etc. Around this same time we worked with Eric Persing on Spectrasonics‘ first plugin release as well. The UVI Engine was subsequently used by MOTU as the core of MachFive, one of the first software samplers, and we continued collaborating with them for versions 2 and 3.

We’ve continued developing sound banks and have over 40 available now, including hardware synth-focused releases like Vintage Vault and PX Apollo and acoustic instruments like Orchestral Suite and the IRCAM Prepared Piano. In the last few years we’ve started looking at effect plugins, releasing Sparkverb and Relayer. We released BeatHawk for iPad. And of course, there’s Falcon, which represents the latest iteration of the UVI Engine and was a lot of fun to bring to market.

When did the two of you first work together?

Remy: I started working at UVI eight years ago when Olivier was already in charge. My background is in signal processing, but I also do quite a lot of applicative and user interface coding. We’re very complementary – our main hobby is arguing with each other. I think pair programming has helped teach us to be both reactive and focused over the years.

Olivier: Remy is usually the more pedantic one, while I tend to be more on the side of compromise. Of course, the goal is to find a good mix between those two visions. We are code nerds from time to time as well.

Remy: I wouldn’t say pedantic, but I’m quite sensible about design coherency and minimalism, and that’s often hard to match with having lots of divergent feature requests. I usually hold back until we get the big picture before rushing to make a change. There’s so many ways to implement the same functionality, but in the long term they’re clearly not equivalent in term of usability.

Olivier: See? We love arguing!

https://www.youtube.com/watch?v=Y5zqgQoSQcs

So, Falcon is undoubtedly one of the biggest projects you’ve worked on and in many ways it’s the logical culmination of your work so far. When did the idea for Falcon first come about?

Remy: As long as I can remember, we’ve always been attracted by the idea of having a hybrid of sampler, synthesiser and open-ended semi-modular environment, and we’ve followed that goal step-by-step while working on the UVI Engine. The first appearance of synthesis within a sampler started with MachFive2, but the main focus was still on sampling. The engine was already modular, but the user interface didn’t reflect that. MachFive3 was an important milestone in this regard – we introduced many new synthesis modules, event processors, scripting, unlimited instancing, and we rewrote the user interface to better match the engine’s modularity and possibilities. With Falcon we completed the transition to a synth-sampler monster. We spent a lot of time changing things under the hood to enhance CPU efficiency, and also a great deal of time looking at usage and workflow.

How long did it take you to develop the idea into a finished product?

Olivier: The Falcon project itself took around two years to complete, but the engine used as its foundation is the result of nearly ten years of development.

As a user, I benefit the most when a product fills a void, when a program can take a complex but rewarding task and simplify it for me.

It’s a hugely powerful instrument. As programmers, is there a temptation to push the technical capabilities of your creations to the limit?

Remy: It’s always tempting to add more and more features, to try and race to match what every other product can do. But I feel it’s more important to have a clear vision, to focus on the needs of the user and their experience and make each design decision as strong as possible. As a user, I benefit the most when a product fills a void, when a program can take a complex but rewarding task and simplify it for me.

Olivier: I suspect if we weren’t the ones designing Falcon it may have been more limited – but that wouldn’t be nearly as interesting. The scripting tools in Falcon represent a good compromise, allowing the user to push these boundaries without overwhelming the UI. Users can always create or use scripts to achieve a specific need, it can be a very powerful system.

How do you reconcile that with the more practical concerns of creating a tool for musicians? Do you have to take a step back and think of things from different perspectives?

Remy: One of the hardest thing to do is to pack in enough features to satisfy the power-user that wants to push the limits, while not overwhelming the occasional user. One of the ways we approached this with Falcon was in creating user interface layers to help focus workflow and mitigate complexity.

As daily users ourselves, launching Falcon a hundred times a day, we’re also very concerned about usability and workflow improvements, we want it to be fast to use, it needs to be fast to use. That’s one of the reasons we extensively support drag-and-drop, mouse wheel, and contextual menus. It’s a constant process of analysis and iteration, to find the most natural and reflexive ways of getting from A to B.

It’s a constant process of analysis and iteration, to find the most natural and reflexive ways of getting from A to B.

Were there cases where you simplified Falcon to make it more accessible for musicians?

Remy: What we try to do is to have as much visual feedback as possible so that the user interface is self-explanatory. SparkVerb, Dual Delay and Thorus are examples of what we’re aiming for in that regard.

Olivier: I can’t think of any examples where we simplified the engine so it would be easy to use, but we have spent a lot of time making this power easier to utilise; the Tree view and contextual modulation matrix for example.

Looking at it from the opposite direction, were there cases where you had ideas of things that would be useful to musicians but ruled them out because they’d be hard to achieve from a programming perspective?

Olivier: Yes, definitely. This is a constant struggle. Cross modulation between different oscillators and inter-module feedback would be very fun to use but it complicates processing a lot. There’s a tremendous amount of potential to be explored here, it’s just a matter of time.

As end users, one thing we don’t really get a sense of is which parts of the process take the most effort to complete. They might not necessarily be the biggest features that draw all the headlines, but I’m sure they mean a lot to the programmers. Tell us about the elements of Falcon that you’re proudest of from a programming perspective.

Olivier: Scripting support is a good example – it’s the kind of feature which is very simple to use for the end user but is very complex and can be challenging to implement correctly. Audio application development comes with hard requirements regarding high-priority/real-time computing and a no memory allocation policy, which is even more complicated to enforce in the script environment.

Remy: Indeed, we spent quite some time reviewing available scripting languages to meet our requirements: expressive, efficient, embeddable, real-time safe, easy to learn…. We finally settled on Lua. Python and Javascript were considered but they fell short in a lot of areas. It was a significant coding effort to find the best way to integrate it and get it right. But now that it’s done, it saves us a lot of time when debugging and making new products and it opens up a world of possibilities regarding algorithmic composition, arrangement or idiomatic instrument techniques simulation.

Olivier: On an unrelated note, lossless audio streaming looks trivial as you’re just reading data from a hard drive, but there are many way to do it and few bring adequate performance. Over time this aspect of the engine has been redone from scratch three times and we’re pretty happy with the latest iteration and its handling of the FLAC format.

Remy: The fine tuning of the streaming policies was the funniest part, playing huge MIDI files and gathering statistics about the most frequently used blocks of audio.

Finally, I’m curious about flipping that last question on its head: which parts were easiest to program?!

Olivier: Multiple oscillators in a single keygroup was a ‘why not’ feature that fit perfectly with the product vision and architecture, so that was an easy feature that greatly expanded the sound design features and allowed the sharing of per-voice filters, and made for quick and easy round-robins. Layer unison is another one of these ‘that could be fun to add’ things. I think it took us a day to make a working proof-of-concept. The possibilities for modulating unison encouraged us to add it to the end product – it’s a quick way to get that supersaw or choral sound using any source, like a granular or pitch-shifted sample.

 

UVI’s Falcon is out now, priced at $349.