PG Music Home Forums PG Music Product Forums Band-in-a-Box for Windows Not Buying Another Upgrade Until BIAB is 64 Bit.

I'm ok with 32 bit.
I have other 32 bit DAWs I just use VSTHost x64 with VSTHost Slavery Suite (LegreeI.dll VSTi or Legree.dll VST) but in BB/RB it just keeps Looping the 1st bar as so many other VSTi/VST do in BB/RB.
This prevents me from using them NOT the 32bit issue.
In Adobe Audition that has NO midi support anymore I can use EZDrummer now with VSTHost x64.
That would be a Fix before going to 64bit, but I don't know, maybe it is a long standing issue that can't be fixed easily ?

VST_Loop.mp4
VST_Loop.wmv

Thanks,
SR

Think about that for a minute; BiaB (MIDI based) has issues with some plugins.
The other (No MIDI support at all) can use these plugins.
Think there is a fundamental difference? Think this may be why the whole VST thing is an issue?
Nah, probably a coincidence.

No, BB/RB is the only Audio program that has this problem, other midi/audio DAWs don't have this problem, Audition 3 has midi and it still works in that, Reaper has midi and it still works in that.
Audition/EZD2 is just an example how VSTHost can save the day, nothing to do with BB problems.
Just try them, download VSTHSS Legree and try it.

So if vst problem fixed maybe it can save the day for BB.
If it gets fix you can add more tracks to BB with wav player VSTs also.

Installers can even detect the version of Windows you are using and then install the correct version of the program.

I read that also. Both is an option.
There are legitimate advantages to 64 bit. And every major audio software company out there has realized this. Also, since BIAB runs 100% in memory, 64 bit will speed up everything. Especially VST. Here's a quote from Microsofts site. "The 64-bit version of Windows handles large amounts of random access memory (RAM) more effectively than a 32-bit system."

The ability to HANDLE large amounts of RAM and the NECESSITY to do so are different things. The original BIAB ran in 64 MEGABYTES under DOS and performed quite well. Naturally, Windows programs are more needy, but I have never seen BIAB for Windows starved for physical memory beyond 4GB and need to start swapping to disk.

There certainly ARE large programs such as real-time databases that REQUIRE 64-bit, but this is not Oracle or SAP.

This is a pretty fair and balanced article: http://www.soundonsound.com/sos/nov10/articles/64-bit.htm

Point taken!

Its occurring to me, how many of the other music software houses are going, "OK we got Jbridge no need to join the 64 bit world, just make people buy that" as a business philosophy....

Just thinking...

Oops cat and pigeons..

Z

Again I see two different BiaB camps and both have different needs.

One is the RT camp. They get along just fine with 32-bit software. (I'm just waiting for them to start complaining about how much HD space they need, but that is another topic.)

The second camp is MIDI and this camp wants 64-bit software to run their ram intensive VSTis and plugins.

As most of you already know I am firmly in the second camp. I will not say that I will never buy another upgrade just because it is 32-bit but I'm beginning to wonder how many potential MIDI users PGMusic is missing out on by staying with 32-bit. I know a number of people who will not even look at a 32-bit program.

Jbridge is a work around not a solution to the 64-bit VSTi problem. I have Jbridge because I had a number of 32-bit VSTis and plugins when I upgraded my system and DAW to 64-bit. Sometimes Jbridge worked and sometimes it didn't; that depended on the VSTi/plugin. I just wonder if the same thing will happen in BiaB, i.e. some 64-bitters will work while others will not. Also will a wrapped 64-bit VSTi stay wrapped when used in a 64-bit DAW? I don't know.

Note that many of my 32-bit VSTis/plugins were replaced by 64-bit versions. The ones that didn't work with Jbridge were discarded. I only have a couple of 32-bit VSTis/plugins left in my system.

Well, I upgrade BiaB/RB whenever the new features and real tracks make it worthwhile to me.
That said, I would love to see 64-bit along with 32-bit, even if 32-bit is released first.
Because some people will need 32-bit for various reasons.
AFAIK 64-bit programs on 64-bit systems are faster and generally more stable.

I've been somewhat discouraged with BiaB when trying to run 32-bit Romplers as BiaB usually locks up when I try.
Sample Tank 2.5 works OK, but my good libraries are mostly in Kontakt or PLAY format.

Because of all that, I generally use BiaB as a midi generator, and RB as an audio generator.
All of this is imported into my DAW where I can use multiple 64-bit plugins without crashing.

>> I just wonder if the same thing will happen in BiaB, i.e. some 64-bitters will work while others will not.

I think they'll all work fine in BB Mario. Band-in-a-Box has direct support for jbridge, so it just works without you needing to do something ahead of time.
That makes it easier than other programs that don't support jbridge directly (if there isn't direct support, you need to make wrapped versions ahead of time). Band-in-a-Box and RealBand have jbridge direct support, as well as some software like Cakewalk Sonar 8.5.x, Cantabile 2.x, and VSTHost.

So far every 64 bit VST we've tested works immediately, including Kontact and SampleTank (full list on pgmusic.com/jbridge.htm ).

>> Also will a wrapped 64-bit VSTi stay wrapped when used in a 64-bit DAW?
Yes the 64bit VSTi will work fine in a 64-bit DAW because then you are using a 64 bit VST in a 64 bit DAW, so no bridging needs to occur.

Thank you Dr. Gannon for your response to my questions.

Also, one very important point that Peter made in another thread and maybe he can restate it here is this:

Biab has it's own version of JBridge, it's not the regular one some of you are using now. Peter said that yes IT DOES access all of your memory, you're not limited to the normal 32 bit 4 gigs of ram.

IF that is in fact true then what other reason is there for insisting that the Biab program itself be 64 bit? IOW, what specific functions do any of you 64 bit supporters think you're missing?

Some say a 64 bit program SHOULD run faster on a 64 bit system. Ok fair enough but what causes Biab to slow down? It's the render time needed to create the Real Tracks because it's audio. Midi is processed in a few seconds and if JBridge allows you to access all your ram then those large samples in a synth like Kontakt for example will be in ram and should still be processed in a few seconds even if Biab is 32 bit, right?

A question for you PC gurus, would simply generating the RT's (audio rendering time) in an otherwise identical PC be any faster if the program was 64 bit?

I can't tell if some of you who are making a big case for Biab being 64 bit are really expert enough to understand all these issues or do you just THINK you're somehow missing something important?

Maybe some of you can address these things I brought up point by point to try to get to the bottom of this.

Bob

>> Biab has it's own version of JBridge, it's not the regular one some of you are using now. Peter said that yes IT DOES access all of your memory, you're not limited to the normal 32 bit 4 gigs of ram.

Biab has a newer version of jbridge (1.73b), but that is the same one that is available to anyone from jbridge. The 'special' thing that you are referring to is likely that BiaB has ** direct support ** for jbridge which means that it just works with 64 bit VST's without the user needing to do anything. Some other programs do the "direct" jbridge support like SONAR.

>>> IF that is in fact true then what other reason is there for insisting that the Biab program itself be 64 bit? IOW, what specific functions do any of you 64 bit supporters think you're missing?

BiaB has no need to access more than 2GB memory at a time, and if it did there are ways to do that in 32bit. The most we need is 0.5 GB and that's with maxed out RealTracks.
To be honest, the best reason for us to make a 64 bit version is that people want it. I can't think of other important reasons than that, but then again there doesn't need to be more reasons than that. But it does mean that we don't rush into it, because the downside is that it means the BiaB gets "forked" into 2 versions (32 bit and 64 bit), and we (and our users) need to keep updating both of them. So if someone asks me "why did you make BiaB 64bit, now there are 2 versions (32 and 64)", I need to have a better answer ready than "people wanted it".

>> Some say a 64 bit program SHOULD run faster on a 64 bit system.

The tests I've seen have shown no difference in running time on 32 bit vs. 64 bit. There might be specialized applications that would run faster (or slower) on 64 bit, but for an app like BiaB, I wouldn't see much difference. Audio is 16 bit for example, hard to see how 64 bit benefits things there.

There'd be all kinds of ways to speed up things in BiaB, they'd mainly be related to optimizing screen redraws or loading of files etc. None of those are 64 bit vs. 32 bit issues though. On a fast machine, BiaB is quite fast already. BiaB 2015 still runs fine on my Windows XP HP AMD Laptop (2003), with a Geekbench of 1,100. I currently program BiaB on a 2010 MacBook Pro under bootcamp Windows 7, with a Geekbench of 3,300. New machines can be screamers with Geekbenches of 9,000 or more!

Bottom line, the day will come when we'll make a 64 bit version, it’s getting closer, but the main reason for it is that's what the customers want (and the future is 64 bit) as opposed to some technical reason that will make things faster. The transition from 16 bit to 32 bit was a totally different story - huge advantages.

This is partially true imho, it's not the "whole VST thing". Note the quote is talking about EZD. The VST problem here is specifically plugs that require a tempo sync with the host like certain drum programs where the plugin itself can generate a drum part. That requires the plug be tempo locked with Biab/RB and that can't be done so yes, there is a VST problem as far as that goes. Note EZD will play fine in Biab as a drum synth playing back midi drum parts. Again this is playing back midi parts NOT creating them. Since Biab itself is one heckuva "creating" program I don't see that as a big issue.

Very few users care about that because Biab has literally thousands of midi drum parts already and then there's the Real Drums. Who needs a third party program to generate a drum part? If you take that out of the equation we're left with "regular synth" VSTi's. The "i" stands for Instrument. Completely different thing, there is not a big problem with VSTi's. All of the big commercial VSTi's like Sampletank, Kontakt, Garritan etc. work fine with Biab/RB unless you need the extra memory that can be used by 64 bit. I just posted about that part of it.

Bob

Thanks Peter, great response. You do realize you double posted but since you're the boss...

One point you didn't answer is I believe you said earlier that JBridge does allow one to use more than the basic 4 gigs of ram if necessary. This seems to be the big kahuna in the room. If you have 24 gigs of ram and you're running a plugin that needs that much can you use it?

Bob

>>> JBridge does allow one to use more than the basic 4 gigs of ram if necessary. This seems to be the big kahuna in the room. If you have 24 gigs of ram and you're running a plugin that needs that much can you use it?

Yes, with jbridge you can use a 64 bit plugin that uses 24GB of memory if you want.

Peter, any chance of a VST version of BIAB/RealTracks?

I'm okay with the jBridge solution, as it does allow use of 64-bit VST(i)'s. I don't believe that a vendor has to develop every aspect of the application in-house and agreements between companies is okay, as long as the support continues. I purchased jBridge awhile back just for the capability to use 64-bit VSTi's and conversely, to use some 32-bit VSTi's in a 64-bit DAW. With BIAB supporting it natively is awesome.

However, I have also run into some problems rendering files, specifically using 64-bit Kontakt and Session Brass. It works fine for playing a MIDI rendition (playback mode), but trying to get it to render the available riffs based on chords (performance mode) just doesn't work. I can hear the riffs playback fine; it just won't render properly (all I get are sporadic notes). Someone commented that this may be a tempo lock issue, which it may be. Don't know.

The interesting thing is that it "plays" those riffs, it just won't render them. Hmmmm...

The tempo sync would also allow the use of such VSTi's such as JamStix and as Bob mentioned EZD, but won't allow those VSTi's do what they are designed to do because of the tempo sync. Other DAW's support that. This would be a nice capability for RealBand/BIAB to have.