Bye bye VST2

[EvilDragon]

Most VST3i have their own preset management anyways (say Halion, VirtualCZ, Waldorf's stuff)...

[Richard_Synapse]

Sample accurate automation: VST3 and JS FX, in VST2 this is only possible by dynamically changing plugin's buffer size, I don't know which plugins do this in VST2, if somebody can tell me, I can try testing.

VST2 does have sample-accurate time stamps. We use this for all critical events, like Note on/off, Pitch bend, and the Modulation wheel. For everything else, say the Master Volume knob, it isn't really needed since we smooth such parameters anyway (plus if you really wanted sample-accurate automation on such parameters, there should be better ways to achieve it, requiring much less CPU - e.g. using an internal mod matrix if the synth has one).

Then there is FLStudio, a tick-aligned host, so in a sense any VST2 plugin would be sample-accurate there, regardless of its implementation.

Richard

[Tj Shredder]

I think there are two reasons for the epic failure of VST 3. It boils down to the needs of developers and their market, which is different than what Steinberg wants to see...
As developer you need to create cross platform, cross format. That is why you would use tools which take the cross xxx burden from you and let the IDE do its magic.
The success of Juce shows the direction...
The result is, if your plug-in can live with the smallest common denominator, that is what you use. That is the simple reason why there is no perceivable difference between VST 2 & 3 for endusers of plug-ins. In addition if the importance of a living standard like MIDI is underestimated and skipped, the failure is garantied... Steinberg can react as they want, they cannot overcome the failure of VST 3 and cannot stop the success of VST 2...

The only reason why AU together with Logic is still allive is that the VST SDK delivers a wrapper. I don't know if Apple paid for that... It was the only way to keep Logic on a proprietary path and garant that their wonderful plug-ins would not run in any other host.
Imagine that wrapper didn't exist, Logic would have to be opened for VSTs or it would be dead long ago...

AU could have been the solution, but proprietary formats are never a solution, they are part of the problem...

MAS, DirectX are acknowledged to be dead, AAX will rather kill ProTools than help it, ProTools would have been dead if there would not have been wrappers around...
They think they are too big to fail, but Reaper has the potential to make them fail...

[aciddose]

Sample accurate automation: VST3 and JS FX, in VST2 this is only possible by dynamically changing plugin's buffer size, I don't know which plugins do this in VST2, if somebody can tell me, I can try testing.

Every VST2 plug-in can have any length of buffer processed at any time.

In VST2 there is a "set buffer length" command sent by the host. This command defines the maximum length, but the minimum is always = 1.

So this means any plug-in can be made to use sample-accurate parameter automation by simply calling:

for (int i = 0; i < samples_to_process; i++) {
plugin->set_parameter(parameter, desired_value_at);
plugin->process(inputs, outputs, 1);
}

This is inefficient, but in reality only rarely do you have such automation taking place.

VST2 also supports "events". One of the event types is for MIDI, which means the plug-in can use its internal implementation (parameter routing) to convert from MIDI messages like a CC to parameters.

It's also possible we could simply use "set parameter" events and directly allow per-sample accurate set parameter calls during a block. How the plug-in might implement this is up to the plug-in author and nearly identical to using MIDI... the only difference being that set parameter uses float values (~25-bit) and MIDI is limited to 14-bit values with 7-bit being more common.

So the only advantage would be higher accuracy. Otherwise the implementation in the plug-in would be identical.

Why didn't VST2.4 implement this? Go ask the people at Stainberg.

You can literally just write it on a napkin in two or three seconds:

Code: Select all

	// abstract event
	struct event_t
	{
		enum class type_t : vst32
		{
			invalid = 0,
			midi = 1,
			audio,
			video,
			parameter,
			trigger,
		};

		void init()
		{
			type = type_t::invalid;
			size = 0;

			delta = 0;
			flags = 0;

			for (int i = 0; i < 16; i++) {
				data[i] = 0;
			}
		}
		
		// core data
		type_t type;
		vst32 size;
		vst32 delta;
		vst32 flags;

		// sub-type data
		vst08 data[16];
	};

	struct midi_event_t
	{
		void init()
		{
			type = event_t::type_t::midi;
			size = 24;

			delta = 0;
			flags = 0;

			note_length = 0;
			note_offset = 0;

			for (int i = 0; i < 4; i++) {
				data[i] = 0;
			}

			detune = 0;
			note_off_velocity = 0;

			reserved = 0;
		}

		// event data
		event_t::type_t type;
		vst32 size;
		vst32 delta;
		vst32 flags;

		// MIDI data
		vst32 note_length;
		vst32 note_offset;

		vstu8 data[4];

		vst08 detune;
		vst08 note_off_velocity;

		vst16 reserved;
	};

Here is an implementation for parameter_event_t:

Code: Select all

	struct parameter_event_t
	{
		enum class interpolation_type_t : vst32
		{
			// immediate jump, no interpolation
			step = 0,
			// linear or power curve (log/exp)
			linear = 1,
			// cosine curve combined with log/exp
			cosine,
			// while other curves are possible,
			// they are all redundant and can be synthesized
			// by the host using only these three types
		};

		void init()
		{
			type = event_t::type_t::parameter;
			size = 24;

			delta = 0;
			flags = 0;

			index = 0;
			value = 0.0f;
			interpolate = interpolation_type_t::step;
			coefficient = 0.0f;
		}

		// event data
		event_t::type_t type;
		vst32 size;
		vst32 delta;
		vst32 flags;

		// parameter data
		vst32 index;
		float value;
		interpolation_type_t interpolate;
		float coefficient;
	};

That's it!

[v1o]

VST2 and VST3 are so different in essence I can't really see how VST4 could be backwards compatible to both...


But yes. Thomas raised some very good points. VST2 doesn't need "support" (Steinberg's shit at it anyways) because it already works great.

Looks how many updates have been made to AU standard. If it already worked great they would have left as is. In technology terms VST2 is now a dinosaur. Stuff like the Melodyne bridge should be a standardised part of the VST spec to enable better integration between hosts and plugins.

[v1o]

I think there are two reasons for the epic failure of VST 3. It boils down to the needs of developers and their market, which is different than what Steinberg wants to see...
As developer you need to create cross platform, cross format. That is why you would use tools which take the cross xxx burden from you and let the IDE do its magic.
The success of Juce shows the direction...
The result is, if your plug-in can live with the smallest common denominator, that is what you use. That is the simple reason why there is no perceivable difference between VST 2 & 3 for endusers of plug-ins. In addition if the importance of a living standard like MIDI is underestimated and skipped, the failure is garantied... Steinberg can react as they want, they cannot overcome the failure of VST 3 and cannot stop the success of VST 2...

The only reason why AU together with Logic is still allive is that the VST SDK delivers a wrapper. I don't know if Apple paid for that... It was the only way to keep Logic on a proprietary path and garant that their wonderful plug-ins would not run in any other host.
Imagine that wrapper didn't exist, Logic would have to be opened for VSTs or it would be dead long ago...

AU could have been the solution, but proprietary formats are never a solution, they are part of the problem...

MAS, DirectX are acknowledged to be dead, AAX will rather kill ProTools than help it, ProTools would have been dead if there would not have been wrappers around...
They think they are too big to fail, but Reaper has the potential to make them fail...

Apple has a large market share. Larger than the market for AAX. Quite a lot of major plugins are even written on Macs.

Are you assuming that 3rd party AU wrappers wouldn’t exist if there wasn’t one already in the VST SDK?

[aciddose]

I had no idea they included an AU wrapper in their latest SDK. I've always assumed the code is shit since I first saw it way back around 2001. Nothing has really convinced me to believe otherwise since then. I've looked over the VST3SDK (in 2009, working as an employee) and it was awful too. I believe for example they made a horrible mess out of the same parameter_event_t type structure I quickly wrote above and made it incredibly difficult to implement.

As far as I'm aware (IIRC) they also included a lot of implementation. So it isn't just an SDK or interface: it's actual implementation code!

The idea I guess is to "build it for an idiot" so plug-in authors don't need to implement anything... while the truth is this is only more easy for the SDK authors because they don't need to document the interface at all!

As I said before:
Design something for an idiot to use and only an idiot will want to use it.

[Tj Shredder]

Are you assuming that 3rd party AU wrappers wouldn’t exist if there wasn’t one already in the VST SDK?

Oh, they would, but a developer would, want to deliver all important formats as if they would be native... The end user would also prefer not to,wrap it up themself...

[aciddose]

Writing "as if they were native" is a pointless waste of time and effort since every plug-in format is identical in all core features.

When I first wrapped my plug-ins in VST back around 2002-2003 all I needed to do was write a simple "wrapper" since my code actually supported more features than VST already in its internal interface.

If you're forced to adapt your abstract code to a particular very finicky interface, that'll make authors a lot less likely to use it.

Where you can trivially write a wrapper to interface from your abstract interface to VST, AU, LV2 or so on this is far more easy to do in only a short period. Most importantly in these cases once you do it correctly the first time, you never need to do it again.

"Write once, run anywhere" and reusability principles are extremely important elements of any modern software.

We're not writing Atari 2600 carts here.

[ENV1]

We're not writing Atari 2600 carts here.

True, but its not a bad skill to possess.

Some of these guys back then have performed what today seems like miracles with regard to efficiency...take Eugene Jarvis for instance who squeezed an entire wavetable synthesizer including FX and modulation and whitenoise generator into an unbelievable 512 bytes of memory despite the fact that this was all there was for the entire pinball machine. (In other words he had only a portion of these 512 bytes to work with because the rest of the machine needed some too.) To put this into perspective; a standard average desktop shortcut (or even just an empty textfile) on a harddrive with standard formatting takes 4 kilobytes, i.e. 4 times as much.


In the mans own words:

At Williams, the sound system did not use a hardware synth as virtually all other game companies used, but rather a dedicated 1 Mhz 6800 micprocessor tied to a 8-bit DAC. Randy Pfeiffer pioneered this design and showed its power in the Steve Ritchie 1978 pin “Flash”. You could in principle make any sound possible, you just had to program it and fit all the data into 2 Kbytes of ROM, and 128 bytes of RAM along with all the other sounds and program. The obvious solution is to just record the desired sound effect and play it back – like todays IPOD. Unfortunately, at the standard sample rate of 44Khz, the 2 kbytes would last for about 50 milliseconds of sound. Good enough for one short bird chirp. So the trick was to create sounds that could be mathematically expressed into a very small amount of data, or a very compact algorithm. And this gets to the basis of what sound really is. It is just a string of numbers converted to audio energy. So the challenge to the sound programmer is to generate very interesting strings of numbers to the human ear.

Actually I started working with the Williams sound board on the pin “Lazer Ball”. On this game the memory was only 512 bytes for all program and data. It was this extreme memory crunch that inspired the Gwave wave table synthesizer. By storing a waveform (sine, square, triangle,etc.) in 4-64 bytes, and then a frequency table of 10-20 bytes, a sound could be characterized by a few bytes. To get further mileage, echo, distortion, LFO,and white noise systems were also employed at a cost of only a few extra bytes. Being the creator of Gwave, I was able to make some really cool sounds, but as skilled as I was, I was stunned to find out that the most brilliant sounds were often created by typing in random numbers for the parameters. Often incredible sounds were generated by inputting mathematically undefined values, such as echoing a sound “0” times. The crudeness and lack of bounds checking of the program allowed for mathematical wraparound and error accumulation that sounded ethereal. For Firepower, I also constructed a parametrically driven pulse width modulation synth – that was responsible for the background sounds and also several of the signature spacey type effects. This sound package went on to form the basis for sound at Williams throughout the ‘80s – powering the classic series of Defender, Stargate, Robotron, Sinistar, and Joust, as well as the pinballs all the way through High Speed, for which I added an FM synthesis module.

[AL321]

So if i was to uninstall a vst2 plugin and reinstall the vst3 version, would DAWS see a different plugin, or would it replace 2 with 3?

[EvilDragon]

Different plugin. You should keep all your VST2s in order to be able to load all projects that use them.

[_al_]

Different plugin. You should keep all your VST2s in order to be able to load all projects that use them.

Ok, thanks for the fast reply
Well wtf, this is not good to hear. Why can't we just have a dll that works on a fking computer. I mean 50 years ago people thought we would have flying cars by 2018, and we have to worry about a 200kb dll?
not amused

[EvilDragon]

Because not all plugins can be made fully portable for this or that reason.

[AnX]

Apple has a large market share.

5-7%