KVR Audio

arguru · Post by **arguru** » Fri Jan 20, 2006 4:11 pm

------------------------------
4.5.0.0 Beta Developer Release
------------------------------

- Unclipped (Save Capable) Beta release (supports loading/saving projects),*,**, so this
  release could be considered as freeware.
  (Althought there's no 2.4 VstSdk plugins to play with yet, hope it will change soon).
- !Only! supports VstSdk2.4 plugins ("VSTPluginMain" export).
- !Only! supports VstSdk2.4 64-bit processDoubleReplacing function.
- VstSdk2.3 or below plugins, aswell "deprecated vst" functions and definitions -are not supported-.
- 32-bit processing -is not supported-.
- Intended mainly as a start for devs releasing VstSdk2.4 / 64-bit process plugins.
- Improvements and fixes a few bugs of aodix 4.2.0.0, nothing relevant.

*   : This wont interfere with next 4.2.0.1 update (shareware).

*** : The official 64-bit release(s) aswell forthcoming 4.2.0.1 release will be 
      exclusive to registered users only.

Download link:

http://arguru.free.fr/fichiers/aodix_45 ... _64dbl.rar

Argu.

liqih · Post by **liqih** » Fri Jan 20, 2006 6:43 pm

thanks!

Karbon L. Forms · Post by **Karbon L. Forms** » Fri Jan 20, 2006 6:46 pm

so whos doing the first 2.4->2.3 wrapper then?

arne · Post by **arne** » Fri Jan 20, 2006 7:37 pm

arguru wrote:

Code: Select all

- !Only! supports VstSdk2.4 plugins ("VSTPluginMain" export).
- !Only! supports VstSdk2.4 64-bit processDoubleReplacing function.
- 32-bit processing -is not supported-.
[/quote]
I'm not sure, but the SDK documentation states :
[quote]
Double Precision Processing

A new process function has been added to support 64 bit (double precision) floating-point audio samples. Please note that this function is optional, whereas the processReplacing function for 32 bit (single precision) floating-point samples is mandatory!
[/quote]
So you may not advertise it as a VST host.

cheers
arne

odo · Post by **odo** » Fri Jan 20, 2006 7:45 pm

it works to on my intel 64bit thingie

odo · Post by **odo** » Fri Jan 20, 2006 7:50 pm

or is it not the program thats 64bit ?
i have a 64bit intel but i tried some software and it didn`t work

arguru · Post by **arguru** » Fri Jan 20, 2006 9:38 pm

arne wrote:

arguru wrote:

Code: Select all

- !Only! supports VstSdk2.4 plugins ("VSTPluginMain" export).
- !Only! supports VstSdk2.4 64-bit processDoubleReplacing function.
- 32-bit processing -is not supported-.
[/quote]
I'm not sure, but the SDK documentation states :
[quote]
Double Precision Processing

A new process function has been added to support 64 bit (double precision) floating-point audio samples. Please note that this function is optional, whereas the processReplacing function for 32 bit (single precision) floating-point samples is mandatory!
[/quote]
So you may not advertise it as a VST host.

cheers
arne[/quote]

I think you didnt understood well or I didnt explained it clear. This beta version is -freeware-, and focused more for developers who want create VstSdk2.4 plugins and test exclusive 64-bit processing, [i]not 64-bit Platform plugins, wich is something different[/i]. This is a win32 application.

This version will have an update aswell in a few days that will support old processing mode (float-point 32 bit plugins), and the infamous 'main' (old vst sdk) function import name.

Anyway, imho, all developers should stick for now to exclusive 64-bit double process/mix as is future inminent and let the old stuff reap in peace.

Mike from reFX · Post by **Mike from reFX** » Fri Jan 20, 2006 9:46 pm

There are still a LOT of applications (means 'uses') for 32bit processing, but still developers might wanna test their plugins with a true 2.4 host. No main, function etc. but at least the specs should be respected, so developers can actually test their plugins.

arguru · Post by **arguru** » Fri Jan 20, 2006 10:00 pm

Mike, I agree in one side and in other not, there's uses for 32-bit processing yes, but I see it more the 'business/marketting' perspective.

I'm very sure as it happened with processReplacing/process battle.

I predict that most plugins will support really one or other mode of process (32-bit float or 64-bit float) and then wrap the not-implemented one with some cast operation, wich is perfectly valid, but things are quite obvious, most future plugins will just worry about 64-bit 'double precission' processing, and cast to 32-bit float to feed the old 'processReplacing' function.

Reasons: easy of handling (doubles w/o typecast), maths / dsp precission, marketting hype, 64-bit platforms coming very soon, etc, etc. After all is quite in performance par with float 32-bit processing (x87 operates w/ 80-bit precission anyway).

If any considerable disadvantage could come from SIMD (SSE2) and memory usage/bandwidth (wich should be not much if we're talking of mere processing/mix and not storaging).

The same goes for hosts, so why worry?.

I think processReplacing will be 'deprecated' quite soon.

Mike from reFX · Post by **Mike from reFX** » Fri Jan 20, 2006 10:17 pm

arguru wrote:Mike, I agree in one side and in other not, there's uses for 32-bit processing yes, but I see it more the 'business/marketting' perspective.

I'm very sure as it happened with processReplacing/process battle.

I predict that most plugins will support really one or other mode of process (32-bit float or 64-bit float) and then wrap the not-implemented one with some cast operation, wich is perfectly valid, but things are quite obvious, most future plugins will just worry about 64-bit 'double precission' processing, and cast to 32-bit float to feed the old 'processReplacing' function.

Reasons: easy of handling (doubles w/o typecast), maths / dsp precission, marketting hype, 64-bit platforms coming very soon, etc, etc. After all is quite in performance par with float 32-bit processing (x87 operates w/ 80-bit precission anyway).

If any considerable disadvantage could come from SIMD (SSE2) and memory usage/bandwidth (wich should be not much if we're talking of mere processing/mix and not storaging).

The same goes for hosts, so why worry?.

I think processReplacing will be 'deprecated' quite soon.

Because I wanna test my stuff! And I don't think that hosts will simply support the 64bit version only when that is the only version that is OPTIONAL whereas the 32bit version is MANDATORY. If my plugin doesn't really need double precision, I rather let my plugin use processReplacing() and never set the double-flag, so the host has to do the conversion himself.

You don't offer a choice, you try to FORCE developers into your way of thinking. To keep CPU/RAM usage to a minimum, I would only use 64bit precision when absolutely necessary (probably never for my products). I can't even fathom a real use for 64bit audio precision. Can someone share an audio-example where it really makes any sense at all?

kurasu · Post by **kurasu** » Fri Jan 20, 2006 11:07 pm

arguru wrote:I think processReplacing will be 'deprecated' quite soon.

I'm quite sure steinberg have better judgement than letting their marketing department decide the SDK spec.

arguru · Post by **arguru** » Fri Jan 20, 2006 11:09 pm

Can someone share an audio-example where it really makes any sense at all?

Believe me, we'll have people/companies claiming "64-bit sounds better", or even brighter! =) (Michael, not me, i think exactly like you too), despite you can argue whatever, probe that 32-bit float is enough with blind/test examples,etc (wich for most task, audiowise, it's), you'll always find users / companies claiming the opposite, and blaming X application to sound mudder than other because no-64 bit mixing...

We have Cakewalk per example, recently adverting their forthcoming host w/ 64-bit double precission mixing, etc.

You have to admit audio market is usually not about the true facts but who has the numbers bigger, with a big golden-ear-gifted audience to support it.

Mike from reFX · Post by **Mike from reFX** » Fri Jan 20, 2006 11:17 pm

So you think that 32bit-float is more then enough, but still you behave as if 64bit is the ONLY way to go. Please simply stick to the vst-specs and make it 32bit compatible again. The 64bit should be optional and the user/developer should be able to choose which path is taken, so the user/developer can test both paths.

plughead · Post by **plughead** » Fri Jan 20, 2006 11:39 pm

I'm quite sure steinberg have better judgement than letting their marketing department decide the SDK spec.

Technology companies (all companies really) are always absolutly driven by marketing sensibilities, it's just the way the world works. Marketing managers have a big say. 64bit is the new flavour and anything that does not does not support it will be seen as inferior, so get on board folks!

kurasu · Post by **kurasu** » Sat Jan 21, 2006 9:04 am

Yes, double support was included so marketing could have their checkbox-feature, but removing float support would just be idiotic. There's a big difference between adding minor features to satisfy marketing and letting them decide the direction of development without any technological merit.

Aodix 4.5 (VstSdk2.4/ 64-Bit Process Host) Developer Release