IK Multimedia 64bit ?

[gustavokch]

Is there any advantage in having effect processors in 64 bit? I thought the only advantage was memory addressing space, and if that's the case, there's no point in having native x64 plugs if they work fine in jbridge...

This is directly from the other thread, from the creator of the Voxengo plugs:

I tend to think, there is advantage since 64-bit codebase plug-ins run in a 64-bit environment that by default works in SSE mode and have 16 XMM floating-point registers instead of 8 registers available in 32-bit execution mode. In most cases, 64-bit plug-ins never use old "stacked" FPU programming model thus enjoying a flexible floating-point XMM register usage and allocation. Also in SSE mode compilers can vectorize a lot of code parts (make use of SIMD parallel computations) without any additional CPU overhead and programming effort

However, that's not really my point. In addition to the efficiency gains that Aleksey talks about here, there's also the penalty of bridging. Extra CPU cycles are requied because the audio data is shuttled back and forth between two processes. And as great as jBridge is (I'm an owner!), it's still a bit of a hack that's unsupported by Steinberg.

Thank you, that (kind of) clears it up for me...
Pretty much the only thing that's clear now is that there's an advantage, technical terms aside

[UltraJv]

Is there any advantage in having effect processors in 64 bit? I thought the only advantage was memory addressing space, and if that's the case, there's no point in having native x64 plugs if they work fine in jbridge...

This is directly from the other thread, from the creator of the Voxengo plugs:

I tend to think, there is advantage since 64-bit codebase plug-ins run in a 64-bit environment that by default works in SSE mode and have 16 XMM floating-point registers instead of 8 registers available in 32-bit execution mode. In most cases, 64-bit plug-ins never use old "stacked" FPU programming model thus enjoying a flexible floating-point XMM register usage and allocation. Also in SSE mode compilers can vectorize a lot of code parts (make use of SIMD parallel computations) without any additional CPU overhead and programming effort

However, that's not really my point. In addition to the efficiency gains that Aleksey talks about here, there's also the penalty of bridging. Extra CPU cycles are requied because the audio data is shuttled back and forth between two processes. And as great as jBridge is (I'm an owner!), it's still a bit of a hack that's unsupported by Steinberg.

Thank you, that (kind of) clears it up for me...
Pretty much the only thing that's clear now is that there's an advantage, technical terms aside

There is a slight advantage - 10% speed :

1) Is there a performance advantage for x64 plugins? (compared to identical 32bit plugin)

2) Is there a performance disadvantage for a 32bit application running on 64bit windows? (due to emulation layer?)

I posted this in another forum to answer some questions about x64 and it's benefits. Perhaps you can find some info that is useful to you in these links.

Noel Borthwick from Roland/Cakewalk is probably one of the most knowledgeable guys out there when it comes to audio and Windows based operating systems. He has a blog that he talks quite a bit about the details and advantages of various configurations.

Check out the following articles:

http://www.noelborthwick.com/minidump/2 ... t-windows/ - in it Noel talks about the increased registers of 64-bit processors and the ability of 64-bit OS platforms to access them which will lead to faster execution of computationally intensive processes such as those found in audio applications.

The white paper he references in the previous article: http://www.cakewalk.com/x64/whitepaper.asp

http://www.noelborthwick.com/minidump/2 ... roduction/ - links to articles he has contributed to on audio with Windows 7.

Thought these might be helpful for some. Hope they are.

well, as you can see benchmarks are pretty similar (at least not so different, I don't think you'll sell more plugins just because they are 10% faster). The only real advantage is the memory management, and fault tolerance.

10% isnt going to change the world. You may see more advantage with multiple instances of 64 bit plugs but a test vs the same 32 bit plugs would have to be set up.

[lightsfadelow]

I think we keep diving into each individual beneit and forgetting the whole system at x64 not only has a speed performance benefit but also allows you to access massive amounts of RAM, which means you never have any disk-RAM thrashing, your read-ahead buffers for audio can be insanely long, etc. so the benefits of the overall system are far more than 10%. IIRC, the tests are for the same system on x64 versus x86, but once you go x64, you can address more RAM than God.

[gs06]

When people say "VST effects don't need to be x64 because they don't use a lot of RAM" that completely misses the point that they are just a part of the whole. UltraJV says that he doesn't use any samples, and I've listened to a bit of his music and it appears it's almost all synth-based, no live audio. So he doesn't need the RAM. But that's not true for a large number of DAW users today who live on big sound libraries.

This is where you loose me entirely. How does 32 bit T-Racks (or whatever) running via JBridge stop you from using samplers with large sound libraries? As far as I know, it doesn't.

If I'm right, and it doesn't impact the amount of total RAM available to your samplers and sample-based VSTi's, then why not just continue to use the bridge programs?

My own experience with IKMM products and Jbridge under 64-bit Cubase and Windows 7 are partly unsatisfying: While Amplitude and other effect plugins seem to work ok, that is definitely not the case for their sampler based products. I have just bough Total Studio 2 some weeks ago and can not make use of about half of the included products. While they start up with JBridge in 64 bit Cubase, they quickly crash the whole Cubase after loading and changing some sounds (not directly but after sounds have been loaded multiple times or trying to stack multiple sounds, e.g. in SampleMoog etc..

I have filed a support ticket with IKMM but their reply was rather lame: "did you try with the new Cubase 5.5?" And this at a time when there were already lots of posts in the Cubase forum that IKMM products even run worse or no more with Cubase 5.5. The support team does not seem to care that their paying customers can not use the products in 64-bit DAW environments, which is specifically sad with sample-based programs as they need lots of RAM which is only available in 64-bit DAW environments. I had the impression that the strategy of the IKMM support consists in just sending any reply and close the ticket. If the reply is of any help to the customer did not really seem to matter.

Of course, IKMM has never announced that Total Studio 2 will run with 64-bit Cubase, so it is my own fault that I did spend money on it. As Amplitude and other effects seem to run ok with JBridge, I only regret half of it, as those are really great products. What really annoys me, however, is that they do not seem to care for the obvious need of their customers to use also the sample based products in 64 bit DAWS. And I would really like to use SampleMoog and the like in my Cubase projects, as I love what I can do with the stand alone versions of the products in my experiments.

I can imagine that fixing these products so that they run well with JBridge might be a lot easier than porting them to 64 bit, and honestly I would not care if they run as true 64 bit or JBridged versions in my 64 bit Cubase, as I would neither care of any 10% performance loss because of JBridging or the like. However, I would love to be able to make use of these programs in my 64 bit DAW, as I will definitely not go back to 32 bit (I am using Spectrasonics and East West products together with BFD2 and all of these need lots of RAM, so 32 bit is simply not an option for me).

So, if any IKMM person reads this post and has a rest of interest for their clients of sampler based products, please make a statement if and when you will ever work on getting these products to run in 64 bit Cubase.
If anybody else in this forum knows about twists how to make use of SampleMoog, SampleTron, SonicSynth, etc. in Cubase 64 bit without having regular Cubase crashes, your advice will be highly appreciated.


Thanks a lot in advance! )

[lagavulin16]

The devs need to get their acts together and start releasing 64 bit plugs. I bet plenty of them are stalling so they can include it in the next paid upgrade. I've quit using 32 bit plugs in the meantime.

[hibidy]

Well, as far as the "next paid update" is concerned, I think it's been a long time that IK has had the sample stuff out there?? I don't think AT3 or the singles will be a paid update.

[Oscat01]

Having red Peters post I am very disappointed at IKMM's position on this issue.
Fivetowers.net ran a test for Cubase 5.5 and out of 45 systems tested so far 19 are running Cubase x64 and that does not include me ! this percentage is not going to shrink as time marches forward. All the reviews of new PC's in PC pro seem to run Windows 7 64 bit as standard. 64 bit plugs are begining to appear at an increasing rate and about time given I am using my 3rd 64 bit operating system and second version of 64 bit Cubase. Though it has only been used as my main DAW for the last 6 months and I can run more tracks than I can with the 32bit version.

Now I assume that most people who run Cubase x64 bit would prefer not to have to use bridging technology at all and given that, would choose to buy a 64 bit plugin over a 32 bit one given a choice, and I doubt whether the plugin needs the extra memory or not is relevant when removing the need for bridging is the main issue.

I myself find I prefer using Kontact player (64bit) as SampleTank bridged causes problems during loading of projects and wonder what GT 4 is like as a replacement for AT3. It is good that IKMM stuff works with jbridge but it is not perfect by a long way.
My investment in IKMM sort of shows that I have been a loyal customer who has in the past recommended others to try out IK's products and some have then gone on to buy the products, I don't want thanks but I did think I was supporting a forward thinking company who would not just ignore a major technical advancement such as going 64 bit and leave customers without any structured information. I thank Peter for at least having the balls to reply, but a forum on the IKMM site is long overdue

Amplitube3 and five of it's predessors, T-racks3 standard and five singles, SampleTank 2.5Xl and five expansiontank 2 libaries and CSR, and now find I cannot reccomend IKMM until there positive words on the 64 bit roadmap, the fact that one does not exist already is mind boggling and far from securing IK's financial security I would suggest that they are now so far behind the curve on this issue that it may indeed damage their business. 19 out of 45 systems surprised me and I really hope it shocks IKMM into action.

Please dont think I am not making music as I am, but I have been patiently waiting for news on this issue for a long time and feel thoughly let down as a customer by the stance they have taken, to me it seems completely unjustifiable.

[JasonSpatola]

Best wishes to all those waiting on the 64-bit versions. Threads like this make me all the more thankful for REAPER's flawless bitbridge.

[hibidy]

The IK stuff is working in sonar and reaper here (except for the mousewheel control not working in sonar)

But since this thing has been retreaded again, let's not forget that this was case back last year. It's conceivable that there is a different set of rules in place, and that IK is actually working towards x64.

[lightsfadelow]

I agree with the "rant" above. I own most of the t-racks singles but almost never use them these days as i try to stick with ONLY x64 plugs to reduce the risk of issues with bridging. I'm hoping IKMM gets x64 in gear. And there was a very recent mail from IK on Cubase.net where they still haven't committed to x64, so not much has changed in a year.

[eDrummist]

Just some clarification regarding the term "early adopter" which has been incorrectly used in this thread (regarding 64 bit computing). FTR, the early adopter phase isn't just some opinion people throw around, in the electronics industry (the industry where I have spent a good deal of my career); it is a critical method for analyzing and managing products and markets. The term comes from what is called the technology adoption model or technology adoption lifecycle (http://en.wikipedia.org/wiki/Technology ... _lifecycle).

The "early adoption phase" for 64 bit versions of Windows was passed some time ago. Now, that is not the same as saying that 32 bit is more popular. Just a hint: when you can walk into Wal-Mart and purchase a 64 bit, Windows 7 PC, you can be certain 64 bit Windows is NOT in the early adoption phase (in plain, non-MBA bad English, Wal-Mart ain't exactly a hang out for the digerati). The current phase of the 64 bit PC adoption cycle could be considered the "early majority." Even value PC makers like HP, Acer and eMachines have offered Win 7 64 bit models throughout 2010. I am certain if you did an analysis of DAW-related purchases of PCs this year, you would find a significant percent -- perhaps even the majority -- are 64 bit. While a significant (but still not the majority) of general use home PCs purchased in 2010 have also been 64 bit.

Anyhow, I understand and empathize with the dilemma faced by developers in a world where users are divided between 32 and 64 bit OSes. Plain and simple, it's costly and more complex to develop and support both than it is to stay 32 bit. However, 64 bit is clearly where the market is shifting (for new purchases) and not adapting does create risks and opportunities for competitor developers. I am confident that a number of developers who are slow to adapt will lose market share, while more progressive and even new entrants, will gain market share with 64 bit offerings. It's a very challenging time for both developers and users. I do agree with consumers who are making their voices heard to let developers know that they want 64 bit versions of their products. I am a long time IK customer and find it disappointing that they have been a laggard in moving to 64 bit and it does mean that I am withholding future purchases from IK until they adapt (and believe me, I would love to have Amplitube 3 -- it sounds great). There are other products, like Addictive Drums, that I simply will not purchase until there is a 64 bit version. On the other hand, I have been even more loyal to developers like ToonTrack and Native Instruments, who have made the leap to 64 bit native versions of many of their products.

[Oscat01]

Whoops, I did not see the date on Peters post, sorry about that. hope their position has changed since then.
I think that when 64 bit versions of Win 7 were included with the 32 bit version and Cubase 5 came with both versions on one DVD as well "the writing was on the wall" as far as the future of 32 bit was concerned.
I mean it's the shinny new thing syndrome, we humans seem to go for it every time, all that ram and a 64 bit operating system. You can try and hold out against it but you will be in a minority eventually. I Know this to be true as last year I finally succumbed and got a mobile phone.

[hibidy]

Whoops, I did not see the date on Peters post, sorry about that.

Yeah, I made a kinda grumpy statement, it's all good. I'm one of those that has needled IK about it quite a bit.

[androidlove]

i'm always fashionably late to the party. i get the best deals that way. i do things like buy my 1st n64 after the cube comes out. i am intentionally behind the times. through a series of events, i wound up with win 7 far earlier than i normally pick things up. i installed the 32 bit version on my 32/64 cpu (are all the new cpu's like that?) due to all the incompatibility issues with 64 bit. i'm happy with 2 gig o ram. i might get 2 gig more on a whim someday. it'll be a very long time before i go 64 bit. i don't want to format the drive for the install. i have win 7 pretty close to how i want it, and it was a LOT of work to get it that way

[jancivil]

x64 conversion not being simple is no excuse. x64 is the future, get onboard or fall behind.

Bear in mind that Apple hasnt gone 64 bit for DAW work yet (very few 64 bit apps/plugs) - PC users are priviliged to try 64 bit DAW attall currently. Yes, 64 bit is the future, but for DAW - its not now. perhaps people expect too much too soon?

I'm using Vienna Ensemble Pro (as a LAN host) which is 64-bit, with VSL/Vienna Suite and Kontakt 4.1; on a Mac. I have 10 or so things from IK, which I'd prefer to use in my ah, preferable working situation. Logic 9.1.something is a 64-bit app. I haven't had much call to use Logic as the AU protocol is hurting in terms of midi channels in their sequencer, but there's that for many people. The plugs I have cover my gamut and three of them aren't 64-bit: BFD2, Kore2, and all of the IK. Wait, EWQL Play works here now, so that's 4 that don't, 3 that do.

Not going to spring for AT3 etc if not x64 capable. At some point soon it looks like I'll be setting up 32-bit instances as a workaround for this one plug. As it is, not that big a deal, but I'm seeing a BFD3, a Kore 2.5 in a not-at-all distant future... 'Very few plugs' is all I need as VSL, Vienna Suite and K4.1 are the workhorses. I can instantiate IK in Cubase 32-bit on the master machine, as well, but if I get into Logic x64, IK gets to where it's holding everything back soon enough I feel.

The things I have described install once, on an OS that doesn't require dicking around with, simply boot the x64 kernel and you're in there. The VE Pro 32-bit server works fine, which is to say all of the above do, in x64 mode. It's a slave workhorse machine and there are no drivers outside of Kore's to worry about. So someone else's 'future' should be my present, wholly, and sooner not later IME. Bigger orchestrations are a PITA in terms of creating templates in 32-bit application, that's the direction I need to go, like last year.