An open letter to Spectrasonics - Omnisphere 2 tags

[Guy Rowland]

nb - the following has come out of some forum discussion and private correspondance between myself and Eric Persing at Spectrasonics

Omni 2 tags – a few ideas of how to make them work better for everyone

With over 10,000 patches including Trilian and Moog expansions just of the core libraries, finding a quick way through them all essential. In Omnisphere 1, the tagging system was widely praised and quickly became best in class for virtual synths. The tagging in Omnisphere 2 has been substantially overhauled, and allows for new attributes such as mood which can only be a good thing. However, while there has been some that have welcomed the changes, a significant proportion of users have found them counterproductive. In a KVR poll conducted in August 2015, 47% of users describe their reaction as “so-so”, “not too happy or “very unhappy”. http://www.kvraudio.com/forum/viewtopic ... 1&t=444251

In correspondence with myself in January 2016, Eric Persing has more fully explained some of the rationale behind the tagging, and indicated some improvements would be forthcoming. However on some of the issues, it is obvious I did a poor job of explaining exactly why so many of us are having problems, and an even poorer one on what possible solutions might look like. This very short open document will attempt to address that, and hopefully start a better dialogue between customers and Spectrasonics on finding a way forward.

I first look at the current problems many of us find in Omni 2 and ways that they might work better, and then turn to how this might affect user and third party patches.

Categories

Categories are the most prominent tag, and the only one with a physical component – third party and user library patches are placed into category folders within the OS, which means that there can only be a single category for each patch.

At the moment there are nouns and adjectives both found in Categories. This gives rise to frequent clashes. If you want to look for a distorted texture, do you start in Textures or Distortion? Or actually Noisescapes, perhaps? The patch you are looking for can only be in one. This is one of the biggest problems with the current system – a user literally does not know where to start. It also affected Omnisphere 1, but has become more challenging in Omnisphere 2 with a much greater number of conflicts.

There are two possible solutions to this. The first would be to move all the descriptive terms to Type, so Distortion can be a selectable attribute for any noun. You’d still have all your distorted sounds easily searchable – you’d just click on Distortion in Type rather than Category (and likely then click the most appropriate category, be it a synth lead, texture or whatever).

The second solution was hinted at by Eric as a possibility, which would be to allow multiple categories – so our example patch goes into Textures AND Distortion AND Noisescapes. The obvious practical problem with this is that currently all third party patches are arranged into category folders, and it’s not obvious how one would put these patches into two places at once, but if that can be overcome and tagging updated throughout, then the system would likely work much, much better. It would no longer matter where you started, because your patch is in ALL the appropriate places, rather than the current lucky dip.

One more issue on Categories – for some reason Hybrid Instruments was removed. This is the most logical term for a large number of factory and third party patches, and its reintroduction would be hugely beneficial (indeed The Unfinished, who try to follow the factory tagging, did just this on the recent release, Colossus).

Types

This is a category that has mushroomed in Omni 2. Each category might have up to 30 types, which by design are often unique to that category. For example, ARP+BPM has types for BPM Analogue and BPM Retro, among many others. This works well for Omni 2 in helping Sound Match do its job, and also it’s clearly useful for users to subdivide into logical categories once they’ve selected a category. However, there are many unintended downsides.

First, there’s vast amount of tags which do the same job but for different categories – as well as BPM Analog and BPM Retro there’s also Bells Analog and Bells Retro, for example. This means that altogether there are hundreds of Types, making it difficult to search if you are starting with a Type before choosing a category. The obvious solution – rather than these 4 types, why not have just two that are simply Analog and Retro? When you’ve selected the appropriate category – say, Bells – ONLY the bells Analog patches will show up. So you’ve kept all the functionality you want to keep, but at a stroke eliminated a huge number of Types that perform similar functions. Although I don’t know the inner workings of Sound Match, I’d have thought the same applies to its algorithms – you still have exactly the same data (retro - bell), it’s just presented to the user in a simplified form. As well as being easier to navigate, this would mean you can work in new logical ways. If you are working on a retro project, you might select the Retro Type first, and further refine from there.

Second, there are types which actively conflict with categories. As well as BPM Retro and Bells Retro, there is a unique Category called Retro Land – meaning a retro patch might be in there, or in the ARP, or in the bells, or almost any other category, again making it difficult to know how to approach it. Retro, surely, is far more useful as a simple type which is applicable to a great many categories. Other generic terms it would be very useful to keep as simple types would be bowed, picked, plucked, sweep etc.

Third, there are currently inherent confusions – across the latest versions of All Spectrasonics products there are both types for Ambient Bells and Bells Ambient for example (how does one choose?!). A replaced tag which is simply Ambient would be clearer, more powerful and easy to use. Even something as esoteric as bowls has Bells Bowls and Bowls as two separate types. It’s hard not to speculate that the inherent complexity of the current system has led to increased mistakes even in the factory tags.

Taken together, one can see how confusion – and indeed near-paralysis – arises. Obviously this works against the user who is looking for useful terms to narrow a search.

One could go too far down that minimalist road and lose some of the spirit of Omni. For example, you could just have Guitars and Synth Mono categories, and then choose Bass if you wanted to find a bass guitar or a synth bass. That would work well enough, but Bass Guitars and Synth Basses are such large and useful categories by themselves (and likely so ingrained in Omni / Trilian users’ heads) that it would likely be counter-productive to remove them. The solution for these few cases would be pretty simple - all Synth Basses or Bass instruments could additionally be given a Type which is simply Bass. Note – this would not produce the same conflict and confusion as currently where a Bass patch would have to be placed in one category or another and thus be invisible to many searches. ALL bass patches would be tagged with the Bass type, and then also be in the most appropriate category. So of course you could start drilling with a simple Bass type, and work from there – with all the appropriate categories supplying patches. Another example - bells could also benefit from a Bell type – mono and poly synths can also be bells, for example. Indeed Synth could also be a type. All this would greatly expand the chances of finding an appropriate patch.

A more radical – and possibly even more useful - solution would be to divide the current Type into two separated attributes – the adjectives remain in Type, while the nouns go to a completely new attribute of Subcategory. String Machines would be a sub category of Strings, or bowls a subcategory of bells. But subcategories could attach to more than one category – so String Machines could also be a subcategory of Keyboards. If every patch had a subcategory as well as a category, this might in fact be a solution to the multiple Category problem mentioned earlier, possibly combined with a reduced number of Main Categories. Meanwhile all the really useful descriptive terms – Retro, Ambient, Pure, Aggressive, Distorted – are easier to find in Type.

One other note – Omni does not remember the user’s logical operator settings, and you are unable to set defaults – for example, AND instead of the default OR. This would be useful to correct.

How to integrate with old and third party libraries?

A real problem has arisen for users who use a lot of third party libraries. While it has always been a bit of a free for all, many of the most popular developers such as The Unfinished or Plughugger have tried to stay as close as possible to Spectrasonics conventions and provide as seamless a user experience as possible.

With the release of Omni 2, this has become massively more difficult – totally different standards, and a current standard that is itself confusing. So there needs to be a way for users to manage all the different tagging regimes they may have on their hard drive. There would seem to me to be 3 useful tools – 1) Library Management; 2) Batch conversion and 3) an unobtrusive visual way to distinguish between Spectrasonics standards and everything else.

1. Library Management.

Again, this is something that Eric Persing indicated might be a possibility, and would be extremely welcome. At the moment, a user can search All Spectrasonics, All or any individual library. There might be many different ways of improving this so users can group libraries together – all PluginGuru libraries (a developer who has their own idiosyncratic standards), for example or libraries that conform to Omni 1 Tagging. This would really help users manage all the different standards from different sources.

2. Batch Conversion.

A tool to batch tag and batch convert would also greatly assist in users trying to get their houses in order. A utopian tool would be able to at least partially auto-suggest converting a patch or library’s existing tags into one that follows Spectrasonics’ current conventions. An easy example is to recognise anything from Arp + Rhythm (Omni 1) would fit right into ARP+BPM (Omni 2). There would certainly be limits to what’s possible, but if the tool were powerful enough, IMO Spectrasonics could even justify it as a priced standalone product.

3. Visual help

At the moment, selecting All Libraries can result in a fairly terrifying experience depending on what 3rd party libraries you have a massive jumble of terminology and standards. There’s no way to distinguish what might just be an attribute property that is just used ad-hoc by one library even though it looks ostensibly reasonable, and what is likely to generate more healthy results by being part of the factory system. One nice option would be to have 3rd party tags at slightly reduced opacity or brightness. Another (again as an option) would be to list alphabetically, but also Spectrasonics A-Z first followed by everything else. Again, a useful visual way to help navigate through the minefield.

Summary

Omnisphere 2 is a beast. The problems users have finding their way around are nice problems to have – if the instrument was not so vast in scale and scope, none of this would be an issue. Yet problems they are, for at least a sizable proportion of users. Spectrasonics have led the way in the past decade for what a virtual synthesizer can do, it feels as if they are still running to catch up with the scale of their own ambition. Hopefully some of the thoughts here might help almost all users in some way shape or form to get the most out of this remarkable synth.

[JT3Jon]

GREAT post and I agree 100% I also feel the "projects" system is lacking as well due to inability to access the tag "categories." I made a youtube which better shows my issue with the system. Hopefully this can be addressed as well?

[Guy Rowland]

Thanks Jon - I never use Project so I wasn't aware of that issue, but what you say makes perfect sense (the video is very clear). If Spectrasonics can either somehow convert Categories to obey the same rules as Type etc, or add a new Subcateogy field, that would help your situation too.