We were all shocked when we heard GIGA was to be discontinued by TASCAM. But then, we really weren’t. Musicians who followed and used Gigasampler and GIGA format samples in their productions probably have been witness to the various ups and downs of the GIGA paradigm in general. 

Something that stands out, that writers and bloggers in the past few weeks have pointed out as a possible cause of the demise of GIGA, was the decision by TASCAM to disallow copy protection on GIGA-format samples. This peeved off many developers who were after ways of securing their sample libraries - stopping the naughty boys and girls out there from distributing libraries illegally.

Without a copy-protection system in place, developers started leaving GIGA in the dust and worked with other proprietary formats that could offer better security. Nowadays, developers like East West/Quantum Leap, SONiVOX and Vienna have developed their own proprietary samplers and formats - what better way to secure property by turning it into something that can’t be used by anyone or anything else?

Securing your property is obviously understandable from a developer’s point of view, but in the process are users being locked into a proprietary cage?

Business is Business

The whole idea of proprietary models makes good business sense:

• Libraries would be as secure as the developer chooses to make them. For example, EWQL recently released a number of libraries under their new PLAY system, which requires customers to purchase an ILok USB key to log software licenses and restrict usage. PLAY also uses a proprietary format unreadable by competing software titles.
• No requirement for licensing agreements with third-party developers like Native Instruments, or TASCAM on a continued basis. 
• There is no loss of sales to a third-party product - for example, samplers like Kontakt.

Portability & Flexibility.

We are stuck with what ‘they’ give us.

EWQL’s move to their PLAY system is a prime example. Before implementing their very own proprietary model, they were swimming around in Native Instruments’ pool, utilising the Kontakt sampling format. Their libraries generally were released with a cut-down sampling engine called ‘Kompakt’, which acted as a front-end for the library, as well as giving some tools to manipulate the instruments contained in the library. If the user felt they needed more power and control over their samples, they had the choice to go buy the fully-featured sampling engine ‘Kontakt’. 

Kontakt is indeed proprietary software of Native Instruments, so this model is far from being completely portable & flexible between other samplers and formats. But the power and ability for complex editing and scripting inside Kontakt makes up for this, allowing users copious amounts of control over the performance and articulation of samples in commerical libraries.

EWQL’s implementation of PLAY means a loss of that portability into Kontakt, and the lack of creative flexibility that using Kontakt enabled. This does not mean PLAY is useless, as it brings it’s own useful tools to the table. But it doesn’t take a genius to understand what you loose by moving away from Kontakt, especially for those high-end users who utilise Kontakt’s abilities to their fullest.

Redundancy.

As we saw with GIGA, it’s possible for even a giant of sampling to fall hard. So what happens if users invest in a developer’s proprietary format, only to have the developer fail in the future? Especially under more closed format’s like EWQL’s PLAY system, with a lack of portability to other sampling engines, such a failure could be dangerous for users.

Without continuing support from the developer and without third-party intervention to keep the system alive, it’s libraries would effectively become redundant.

Although the GIGA collapse was sad to see, it won’t be a huge blow thanks to many developers utilising many different formats in their releases - for instance Project SAM supports GIGA, Kontakt, HALion, EXS24 and MachFive formats - so if one format fails, the library will live on. But the GIGA format will inevitably fall out of favour. The danger of using a single proprietary format is simple… there might be no land to swim to when the ship sinks. 

Standardisation as a Model

If proprietary models cause problems for users, what other alternative is there?

Well, what if developers choose to agree upon a standard format that would embrace the ideas of flexibility and portability? An excellent middle-ground would be to develop an open-source format, or embrace an existing format like SFZ, which is already being used by Cakewalk & Garritan in a number of their products. 

Under such a model, it’s the users who win, but the developers don’t have to miss out either.

User Utopia

For the user, a standard model is quite beneficial. If an open-source format like SFZ was embraced by the greater developer community and was supported by the majority of samplers, then users wouldn’t be hogtied to a particular developer’s software, or a particular way of working - an idea that makes many musicians giddy with excitement.

A particular onus would be placed on the developers of the sampling software, who would be required to make sure their samplers supported a standard format. Stricter guidelines would be required during development to ensure compatibility across a range of platforms. We would basically create a level playing field in the process - less focus would be placed upon the development of proprietary systems and more on creating content and features that are high-quality and attractive to their customer base.

The idea of standardisation also combats redundancy due to a company collapse or product discontinuation - a user’s investment in their libraries would be protected by the fact that the format will still be supported by other developers even after the ship sinks.

But what about security? With embracing flexibility and portability comes the issue of ensuring that a library is protected from those bad boys and girls out there. This is something that can’t be answered directly, although there is no reason not to apply previous security concepts like the iLok, or some sort of online authorisation to log licenses and restrict usage.

So Whats Better?

Proprietary and standardised models both work differently for users and developers, and it’s hard to predict who exactly wins or loses if just one is embraced over the other.

Proprietary models immediately benefit the developers by protecting property, but users miss out on flexibility and portability, alongside the risk of investing in a proprietary format. On the other hand, standardised models allow for flexibility and portability, and with the possibility of added security, could also be attractive to developers under the right circumstances. 

Perhaps somewhere between the two would be most appropriate - a proprietary format that is made open for use, which could be used as a de-facto standard between developers, that wouldn’t require a conversion process to make the format compatible in 3rd-party samplers. An example of this is Adobe’s PDF document format, a proprietary format which has become widely used amongst 3rd-party developers. 

Interestingly, it could be the users who decide the course in which the industry sails. With developers listening to constructive criticism and opinions more and more, all it might take for a paradigm shift is for users to say ‘no’ to creative cages proprietary systems might construct for them.