I purchased BIAB upgrade 2014 last year. I have been using BIAB since it was on floppy disks and I have upgraded every year or every couple of years since then.
I have decided I will never purchase another upgrade of BIAB until it is 64 bit. This should have been done a long time ago. When I saw the 64 Bit VST bridge thing in BIAB 2015. I said to myself, enough is enough. BIAB is not an inexpensive piece of software it should have been 64 bit a long time ago.
I know, some of you are going to defend pgmusic and say you really don't need it. But you're wrong. Especially in light of the VST 64 bit bridge software. More of the program could run in memory ect... 64 bit cpu's have been out for over a decade. I think it's time to make the switch to 64 bit pgmusic.
mj

[Edited]
I want to be clear about something. I think BIAB is a wonderful program. At this point (2014 Version) BIAB does all I need it to do. It is great software, and I am glad I own it. I use it almost everyday.
The point of my post is that, I am very satisfied with BIAB as a product and the only thing that would tempt me to update is a 64 bit version of the program.

I remember back in the day when I could upgrade BIAB for $39.95 (or something like that?) and there was no copy protection key stuff. With that business model I put no expectations on pgmusic. But today, things have changed. With the higher prices of the software and all the copy protection stuff I guess I have raised my expectations a bit.

Fully agree .... and especially counting all the dough i paid up since Atari days. I run a 64bit system for over 3 years now, and BTW own a licensed Jbridge already ..... there's something serious missing with this 2015 update. Also to think that BIAB still is not able to sync in slave mode to f.i. cubase causes a lot of extra time for up and down transfers of generated wav files when composing stuff. - F

))) More of the program could run in memory etcetera

The program already runs 100% in memory, that wouldn't change in 64 bit.

What is the "etcetera" reason you are referring to. The only reason I know of is to support 64 bit plugins, and BB 2015 now does that with jbridge.

Of course you don't need to tell us a reason, but people like me looking for reasons to make BIaB 64 bit someday, would like to see a reason more than "etcetera" . Many people don't understand what a 64 bit OS is, and when they see etcetera listed as a reason, they think that there are lots of important reasons.

BiaB 2015
- runs on 32 bit and 64 bit OS. If it was 64 bit, this would be 64 bit only.
- supports both 32 bit and 64 bit plugins
-64 bit programs have to use 64 bit implementations of hosts, plugins, drivers etc., and these are rather new, and typically not as stable and mature as the 32 bit ones. This same point is made by Ableton on their discussion of the issue. https://www.ableton.com/en/articles/64bit-myths-facts/

Thanks Peter for your clarification !And I understand your point of view.

One mans meat -- etc.
Go to 64 bit and keep MJames as a customer but lose me??
I'm not about to change my XP based PC any time soon - too many "old" programs that work perfectly and won't on Win8.
Peter, no matter what you do, you won't please all of the people all of the time.
Ian

Thanks Peter and for the link to explain.
+1 to you.
-1 to those who complain without the full facts.
Hope everyone takes the time to read Ableton write up.

Cheers

Peter,

FINALLY, I'm glad to see you jump in here on this.

I am not as hard over as either Sixchannel on the 32 bit side (but like him I have some of the same HW/SW issues - that's why my desktop is still dual boot from separate HD's Win 7/Win XP with a Win XP VM plus keep running my WIN XP laptop), or, clearly, as much as MJames on the 64 bit side.

You won't lose me as customer either way, but I am just one vote.

Frankly I have yet to NEED 64 bit or have a work stoppage in BIAB, RB, PT (or Sonar X3 Pro - I've only installed the 32 bit version) due to inability to run 64 bit APPS.

So, I won't jump on the "64-bit or death" bandwagon (but then I still shoot cap&ball black powder muzzle loaders, as well as that newfangled smokeless stuff like .338 Lapua)

BIAB/RB/PT is not perfect no single app is or that app would have already cornered the ENTIRE music making/production market.

I really think with all the yap, yap, yap last few years about 64 bit BIAB what they REALLY want is the DAW portion (RB and/or it's parent PT) to be 64 bit, but in PG's case I guess it's "in for a penny in for a pound."


Larry

Everyone is certainly entitled to their opinion, and most people on this forum are far more technically and musically sophisticated than me, but my humble opinion based on my own needs and abilities is that I am very fortunate to have this program, and each year I jump sight unseen at the chance to get whatever extra icing on the cake is offered. I run 64-bit applications like Sonar Producer X3e and SampleTank 3 on a power system, and I'm able to do what I need to with what BIAB presently provides. I can ask/"wish" for things, but I would never not upgrade.

I read it. Bottom line; Live provides both the 64-bit version of Live for machines with a 64-bit operating system and a 32-bit version of Live for the 32-bit operating system. As does Reaper and many other music apps. Just sayin...

+I for 64bit, it is the 21st century now.

I have no issue with asking for 64 bit, and you/we can all vote with our Dollars/Pounds/Euros/Pesos/New Taiwan Dollars,...and I hope next year you all see, at a minimum, a 64 bit version of RB (and PT).

But sorry the "21st century" thing is not an argument, in fact it is an non sequitur, it is as logically consistent as saying that "it snows somewhere in December so get moving on 64 bit."

We are living in the 21st century and XP is dead now and needs upgrading for MANY reasons! I've been servicing XP since it came out.

I recommend Windows 7 over Windows 8 and it is still available to buy.

Regarding 64 vs 32bit. The fact that its only a memory issue, what is the big deal here? You can see from my computer spec listed below that mine is a Hi End PC yet I have no problems at all. So whats the big deal with 32bit BIAB?? Storm in a teacup comes to mind.

I'd like Sizeable/Movable/hideable toolbars
32bit or 64bit either way is fine

Actually, Win XP was not released UNTIL this the 21st Century! (August 24, 2001)

Hope people take the time to read this:
https://www.ableton.com/en/articles/64bit-myths-facts/
Repeating what Peter wrote earlier.
PS: -1 for 64, staying with 32.
Cheers

Your right about that Larry of course, what I mean, watching my p's and q's is that this is the 21st century, 13 years since 64 bit,. Now there is Android, tablets, phones, touch sensitivity and a whole lot more slick a feel to a program of this price.

The program needs a reconceptualization and a rewrite, there needs to be a sixty four bit and a 32 bit edition. I really want it to succeed and I don't think doggedly hanging on to 32 bit architecture, some of it built decades ago, is going to do PG's future any favours.

Yes, your old trousers will do, they have got a lot of life in them yet, your familiar with them even comfortable in them with all their quirks and funny buttons, but would you go out and buy old trousers?

If there were competition I don't think PG would be thinking this way- ah well...

Z

Trouble is, of course, to dump my XP I would have to buy all new softwares (recording for instance) that cost good money on Day 1, work perfectly, give me what I need. All that starts to look like another Money Pit, especially as one can't trust Microsoft to put out a system that isnt riddled with issues.
Maybe some Clever Soul can come up with an Emulator (is that the right word?) so I could use my beloved old Progs on WinWhatever.
And I just wonder what the End Of Support Date is for Win7. There will be one.
Ian

Z

Don't get frustrated, I'm sure PG is looking at this from a sound business perspective and that ALWAYS includes satisfying as many customers as possible, irrespective of OWS propaganda about business!

But as you so rightly pointed out, at least for the BIAB portion: there is NO COMPETITION. And frankly and factually, there is no real burning need for 64 bit for BIAB. Yes, nice to have and maybe even lead to a few less hic cups here and there.

It could much more easily be argued that RB and PT will soon need to be 64-bit for the ever increasing complex productions and/or multiple memory heavy synths & FX - if they want to keep that business, but even Apple Logic and Pro Tools HAVE LIMITs!

Also If/when (?) PG wanted to expand BIAB to a full 16, or 32, or 64 and beyond "band" instrument set then they WOULD need to go 64 bit, memory alone would clearly become an issue otherwise.


Sixchannel

You are so right at some point WIN 7/8 (and their offspring) will have an end of life support date and this will start all over again.

Every time there has been a major change (DOS to Win 3 to Win 95/98 (not so much) to Win XP (a lot) to WIN 7/8 (modest cost hits) has been a freaking money pit of new HW and SW - not to mention the wasted time reinstalling, reconfiguring, re-learning, and re-hacking to get work arounds for the inevitable gotcha's.


BTW that's why I STILL use mostly external synths, like my guitars and amps they don't care what OS I run!



Larry

If there were a compelling advantage to re-writing BIAB as a 64-bit app, I would jump on the bandwagon, but actually I see none (except for plug-ins) which appears to be inexpensively rectified. I am not a big plug in user, personally.

I would prefer to see resources spent on modernizing the UI, and making it more cutomizeable , adding Music XML or enhancing the notation (which Music XML would satisfy.)

The new Realtracks, etc. are great, but I don't consider them FEATURES per se compared to changing the functionality of the base code. I would really never tell the difference between running 2014 and 2015.

Demanding 64-bit just because this "is the 21st Century" is not a valid argument IMO. If it does not enhance the speed or usability of the base program, it is nothing more than "bragging rights." I never see BIAB swapping to disk because it is running out of RAM.

Really, the program does more than I ever need (for its intended purpose.) Again, all I would ask is more user-customization to fit various scenarios (live performance vs. composition etc.)

+1. And fixing the bugs!

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.

Thanks Bob Love ya man. You are so inspiring and supportive of new ides and suggestions, not to mention all those great ideas you have suggested.

What?? What are you talking about?

I said most don't care, that's an opinion, so what?

The point I was making is except for that one VST tempo sync issue, Biab doesn't have a problem with most VSTi's and since Biab itself is a great drum track creation program 'most' don't care about using a 3rd party drum synth to create drum parts within Biab. Have you seen people clamoring about that in the Biab forum? I've seen that point mentioned once or twice in the last few years, that's it. I think me saying "most" is a fair statement.

Now, Real Band was a different story before all the Biab features were added. I was the guy who every year was asking for them to fix that problem and Peter said they were looking into it and then nothing. It's obvious it can't be fixed at least in RB. I still think it would be great to use Jamstix, EZD and the others in RB but Biab? Not so much but that's just me. Opinion.

I was simply using that as an example to point out to people that Biab doesn't have some systemic built in VST problem except for that one thing.

Back to the original point of this thread, since Peter confirmed that JBridge does access whatever memory you have installed the 64 bit issue is over. Peter who as the developer of Biab certainly knows more about it than any of us ever will validated what I said to the 64 bit guys over a year ago and that is the only real reason to do it is because people think they need it. There is absolutely zero technical reason for having 64 bit now that is is integrated with the new JBridge unless of course it turns out it doesn't work as well as Peter says.

Bob

When the discussions first started about wanting a 64 bit version of BIAB, I was a proponent and supported that request. However, when I saw that jbride took care of the 64 bit VSTs/VSTIs with version 2015, my mindset now is: take your time, PG. ALL is WELL now.

Just my 2 cents.

So has anyone tried ST3 (which is only 64bit) with BIAB 2015 and jbridge?? The sound files are huge and without the available RAM afforded with 64bit would likely be a problem. So anyone...?

yes.

I have ST3, JBrdige and BIAB 2015 (and it all works just fine) but not sure what you mean by

"...without the available RAM afforded with 64bit would likely be a problem"

Anyone owning and trying to use 64 bit VSTi softsynth plugins (virtual "ROMP'lers" if you like) already know they are are memory pigs (or will learn it soon enough) so they better have the

"available RAM" you mention.

However, I think what you meant/implied was that since BIAB is still limited to less than 4 GB (~3.5GB) workspace due to its being a 32 bit app then a users favorite "composite band" of instruments totaling more than 4 GB wouldn't work?

Peter says they will since BIAB uses Jbridge directly the limit is YOUR VSTi your physical memory - NOT BIABs being 32 bit (see his reply a page back)

http://www.pgmusic.com/forums/ubbthreads.php?ubb=showflat&Number=273194&page=4


While I have tried (quick checked) BIAB + JBridge + ST3 on my PC I have not torture tested it's limits.

Larry

I am getting rather tired of buying a new "upgrade" every 6 months. Here is a thought, how about I buy an upgrade and PG music makes it good for the next couple years. BIAB is the only software I own that upgrades more than Windows...

Droot, welcome to the forum.

BIAB has had only one upgrade (paid) per year for the last two years. Updates come as needed when bugs are fixed (and those updates are free).

Droot, welcome to the forum. I see you've been a member for a number of years but have waited some time to make your first post. So I'm guessing you have strong feelings about upgrades.

2013, 2014 & 2015 were annual upgrades. There hasn't been a .5 upgrade since 2012.5

While the programs are improved each cycle, some years the upgrade will be more about program enhancements such as the UserTracks and the (GUI) interface enhancement for 2014 while other times may focus more on content such as RealTracks and UserTracks.

If you compare PG Music products to soft synth companies (as they are about the only other music related companies providing content and programs) they relaease new product year round.

https://www.youtube.com/watch?v=4MbiDGAUkic&feature=youtu.be

Link to video from the post pinned to the top of the BiaB Forum ..

Thanks Rharv, Very Cool. Gonna have to give that a go.

I have J bridge 1.65c, officially the latest on 12-12-2014, ALREADY bought it, and Sampletank 3 installed. Does not work with BIAB ....

- speed is what we need, as BIAB with all the styles i have collected over the years loads quite slow on my system, 64bit win 7, and takes about 15 to 20 seconds, but maybe that's "normal". I also like to have more programs and plugs loaded in RAM together, and especially Cubase can be a memory monster already. - F

So who we gonna believe?

Hi Fiddler,

It's good to see you again

PG Music have said a few times that you have to get JBridge version 1.7b for BIAB. I had a look on the JBridge site and it's there.

Regards,
Noel

Peter. He's already answered all these questions and apparently some in this thread are not paying attention.

C'mon somebody can't even see 1.6 vs 1.7 when it's written right there??

Bob

>>> I have J bridge 1.65c, officially the latest on 12-12-2014, ALREADY bought it, and Sampletank 3 installed. Does not work with BIAB ....

You need jbridge 1.73b or higher. So if you have an older jbridge, you need to update it. Of course the jbridge that you can get with Band-in-a-Box is the new one, and you don't need to update jbridge, as it works great with BB 2015.

********* THE INFO BELOW ONLY APPLIES TO PEOPLE WHO ALREADY HAD AN OLDER JBRIDGE, NOT THE PEOPLE WHO GOT IT WITH BAND-IN-A-BOX ****

You can update your existing jbridge here: http://jstuff.wordpress.com/jbridge/betaupdates/
Note the list of fixed issues for the jbridge update:

- Several minor crash / bug fixes.
– experimental audioMasterSetTime implementation.
– experimental speed improvements in some IPC structures.
**** – fixed an issue where bridging files would not be loaded when using Band In A Box. ****

Not been around for a while but must add some input as I believe I was amongst the first to request x64 bit versions.

Thanks for your input Peter. May I hold you to your comment.

"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."

I'm happy to wait a bit.

Just don't let me die of old age first please.

Mal :-)

Now that Peter says BIAB works with 64 bit VSTis with jbridge, is there any other reason for BIAB to become a 64 bit app? Ray

raymb1 ...... May I offer another question sir.

Why does any company compile 64 bit versions of their software?

Mal. Please. We're specifically talking about Biab, nothing else.

To throw it back to you: What other reason is there for Biab to be 64 bit?

Name the reason and let Peter answer it since he's monitoring this thread.

Bob

The answer has been given quite a few times Bob already.

There is an increasing proportion of users that want to be able to use BB as their sole piece of creative outflow. The main reason has to be the utilization of memory on Windows Ultimate. Ok, I have used jBridge for ages and it works, but this is a 'stop gap' only.

With an increase in the availability of 64-bit processors and larger capacities of RAM, Microsoft and Apple both have begun to develop and release upgraded versions of their operating systems that are designed to take full advantage of the new technology. In the case of Microsoft Windows, the basic versions of the operating systems put software limitations on the amount of RAM that can be used by applications, but even in the ultimate and professional version of the operating system, 4 GB is the maximum usable memory the 32-bit version can handle. While a 64-bit operating system can increase the capabilities of a processor drastically, the real jump in power comes from software designed with this architecture in mind.

I have a question related to all this about stability.

In the file cited by Dr. Gannon, the discussion of Ableton Live https://www.ableton.com/en/articles/64bit-myths-facts/ , there was this statement about using JBridge in a 64-bit host to run a 32-bit plugin:

"It is to be expected that a plug-in translated in this manner will never run as dependably as a 32-bit plug-in in a 32-bit host or a true 64-bit plug-in in a 64-bit host."

Following up, I could not find a statement specifically about the stability of the reverse, namely running a 64-bit plugin using JBridge and a 32-bit host (in this case, BIAB). It is great that JBridge now allows BIAB to use 64-bit plugins, and absolutely magnificent that more than 4GB can be accessed by the plugin in this way (that was a real surprise). So, the only thing remaining to justify BIAB going to a 64-bitm app seems to me to be increased stability, if the Ableton statement above is accurate:

"a plug-in translated in this manner will never run as dependably as a 32-bit plug-in in a 32-bit host or a true 64-bit plug-in in a 64-bit host." (emphasis addded)

It seems to me that the percentage of BIAB users who could take advantage of a 64 bit system would be very small. There are a lot of BIAB users (from reading a lot of the posts), who are still using 32 bit Win XP and Win 7 machines. Would it be profitable for PG Music to maintain 2 separate apps? I can see that a few years into the future everything will be 64 bit, but for now PG can't leave the older systems in the dust. Ray

Hi Noel, Peter; Right, but at first i only saw a demo version 1.7beta there, and mailed J about updates, since i already licensed it ... no reply for a few days yet ... i mailed him again today -F

And:



Mal, I don't believe this. What is it with some of you guys?

If you have 24 gigs of ram, you use all 24. There is no speed difference in running 32 bit vs 64 bit. Peter says Biab is using JBridge just fine. WHAT ELSE IS THERE? It's like you're stuck in a rut, saying the same things over and over regardless of what the one person in this thread who really knows everything there is to know about Biab is saying.

You are ASSUMING that just because Biab is 64 bit everything will be mo' better. You have to have some technical evidence of that other than just guessing that it's so. Peter said earlier he doesn't see a concrete reason to go 64 bit yet. He also made the point that audio is still 16 bit. Do you have an answer for that? Sounds like a good point to me. Give him a real, solid, technical reason to do it, not simple stuff like "everybody else is doing it so it must be good".

Bob

I just want to be able to run quite a few large programs in RAM together in Windows Ultimate, like cubase, biab and realband, video editing stuff and more when working on something without having to boot each program or even OS separately ... all the other stuff is 64bit, only PG stuff not. - F

@jazzmammal

You seem to be confusing things and please don't attribute comments that I have not said, to me.

I am not referring to speed. I am referring to stability.

Permit me to use a Wiki quote:

"A 64-bit processor performs best with 64-bit software.
A 64-bit processor has backward compatibility and will handle most 32-bit software.
A 32-bit processor is not compatible with 64-bit software.

A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of random access memory.[29] This is not entirely true:

Some operating systems and certain hardware configurations limit the physical memory space to 3 GB on IA-32 systems, due to much of the 3–4 GB region being reserved for hardware addressing; see 3 GB barrier; 64-bit architectures can address far more than 4 GB. However, IA-32 processors from the Pentium II onward allow for a 36-bit physical memory address space, using Physical Address Extension (PAE), which gives a 64 GB physical address range, of which up to 62 GB may be used by main memory; operating systems that support PAE may not be limited to 4GB of physical memory, even on IA-32 processors. However, drivers and other kernel mode software, particularly older versions, may not be compatible with PAE.
Some operating systems reserve portions of process address space for OS use, effectively reducing the total address space available for mapping memory for user programs. For instance, 32-bit Windows reserves 1 or 2 GB (depending on the settings) of the total address space for the kernel, which leaves only 3 or 2 GB (respectively) of the address space available for user mode. This limit is much higher on 64-bit operating systems.
Memory-mapped files are becoming more difficult to implement in 32-bit architectures as files of over 4 GB become more common; such large files cannot be memory-mapped easily to 32-bit architectures—only part of the file can be mapped into the address space at a time, and to access such a file by memory mapping, the parts mapped must be swapped into and out of the address space as needed. This is a problem, as memory mapping, if properly implemented by the OS, is one of the most efficient disk-to-memory methods.
Some 64-bit programs, such as encoders, decoders and encryption software, can benefit greatly from 64-bit registers, while the performance of other programs, such as 3D graphics-oriented ones, remains unaffected when switching from a 32-bit to a 64-bit environment.
Some 64-bit architectures, such as x86-64, support more general-purpose registers than their 32-bit counterparts (although this is not due specifically to the word length). This leads to a significant speed increase for tight loops since the processor does not have to fetch data from the cache or main memory if the data can fit in the available registers.
Example in C:
int a, b, c, d, e;
for (a=0; a<100; a++)
{
b = a;
c = b;
d = c;
e = d;
}
If a processor only has the ability to keep two or three values or variables in registers it would need to move some values between memory and registers to be able to process variables d and e as well; this is a process that takes many CPU cycles. A processor that is capable of holding all values and variables in registers can loop through them without needing to move data between registers and memory for each iteration. This behavior can easily be compared with virtual memory, although any effects are contingent upon the compiler.
The main disadvantage of 64-bit architectures is that, relative to 32-bit architectures, the same data occupies more space in memory (due to longer pointers and possibly other types, and alignment padding). This increases the memory requirements of a given process and can have implications for efficient processor cache utilization. Maintaining a partial 32-bit model is one way to handle this, and is in general reasonably effective. For example, the z/OS operating system takes this approach, requiring program code to reside in 31-bit address spaces (the high order bit is not used in address calculation on the underlying hardware platform) while data objects can optionally reside in 64-bit regions.

As of June 2011, most proprietary x86 software is compiled into 32-bit code, with less being also compiled into 64-bit code (although the trend is rapidly equalizing[citation needed]), so most of that software does not take advantage of the larger 64-bit address space or wider 64-bit registers and data paths on x86-64 processors, or the additional general-purpose registers.[citation needed] However, users of most RISC platforms, and users of free or open source operating systems (where the source code is available for recompiling with a 64-bit compiler) have been able to use exclusive 64-bit computing environments for years. Not all such applications require a large address space or manipulate 64-bit data items, so these applications do not benefit from these features. The main advantage of 64-bit versions of such applications is the ability to access more registers in the x86-64 architecture."

Having offered that ..... All I really would like to see is 64 BB for my 64 bit system. Peter has said that it will come and I hope it does for all of us that prefer to work in that environment. It would simply be far more convenient to work in BB than to keep switching over to other software.

We have our 32 bit BB .... Great. Now let us have 64 bit BB as well, for those of us that want it.

Mal

Ok Mal. Another highly detailed non-answer answer.

So you're saying Peter is full of crap, right? He says according to his testing there's no, repeat no advantage to converting Biab to 64 bit. Again, you pasted in a highly detailed description talking about how running a 32 bit app on a 64 bit system is memory restricted when Peter specifically said as far as Biab and JBridge is concerned, that's not an issue.

This whole thing you just posted is irrelevant unless you're saying Peter doesn't know what he's talking about. Forget all these posts of yours and simply say what's on your mind.

You don't believe Peter Gannon.

Bob

Did I say all that that Bob?

I did not say 'Peter is full of crap'. Nor did I offer a 'non-answer answer'. Is that English even? Nor did I say that I don't believe Peter.

I know I said this.

All I really would like to see is 64 BB for my 64 bit system. Peter has said that it will come and I hope it does for all of us that prefer to work in that environment. It would simply be far more convenient to work in BB than to keep switching over to other software.

We have our 32 bit BB .... Great. Now let us have 64 bit BB as well, for those of us that want it.

Why resort to using a partnership with jBridge? jBridge has been around for a long time and it's great ....... It doesn't make Band In A Box a 64 Bit program. It makes Band In A Box a 32 bit program that utilises jBridge, to appease those of us that would prefer the choice of 64 bit, rather than 32 bit.

Maybe I should resort to an Americanism.

Get real man.

Oh ..... and further back I suggested.

Why does any company compile 64 bit versions of their software?

That wasn't meant as a joke ..... Maybe you could provide an answer Bob.

The wiki quote is outdated and provides humour for those that like or appreciate it. Some things are facile, some things are complex.

Edited to provide the correct spelling of facile.

I'm a different Bob, but ..
From your Wiki quote -
"Not all such applications require a large address space or manipulate 64-bit data items, so these applications do not benefit from these features."

I think maybe that is what PG was saying; at this point in time BB would not benefit.

Bob, I think that your comments are subjective, not constructive, and possibly based on high emotions rather than fact.

This is an extremely well conducted forum, where members can offer constructive comments in a civil manner. I didn't read any statements by the other forum member that they suggested the somewhat derogatory statements you have now made.

I think there is disappointment that there was anticipation that a 64 bit version might be delivered this time around. The topic has been discussed and wished for endlessly.

PGM might have approached this more effectively if they made a statement mid term that the next release would have a lot of new features, but it would not yet be 64 bit, and the reasons why. Instead, there was loads of anticipation and hope, and then sudden disappointment. That disappointment was avoidable in my view.

Let's all sit back, calm down a bit eh? That will really be more objective, and we can all maintain the high standard the forum members continually deliver.

Regards

Trevor

If the only guy who matters says there's no benefit from Biab being 64 bit and the memory issue is solved with JBridge, and you don't even have to do anything, you install it then it's integrated inside Biab, then what else is there?

Comments in this forum are not simply for the one guy I happen to be talking to. It's for noobies, potential customers and anybody else who's reading this. To me it's very unfair to keep harping on this issue when Peter has categorically said there's no problem.

If or when Mal actually uses all his 64 bit VST's with Biab and JBridge and reports specific issues or problems then we can discuss that but right now he's talking for the sake of talking, he isn't saying anything.

Is he saying he's having a problem with Biab? No. Is he saying he's tried using more than 4 gigs of ram with one of his VST's and and it didn't work? No. So what exactly is he saying? He just wants PGM to create a 64 bit version with all that complexity that Peter talked about with no solid reason other than he wants it. But to someone who doesn't understand this stuff it certainly looks like Biab is missing something important when it isn't.

This isn't personal to me, I just think it's an unfair slam against PGM.

Bob

One theory on the 64 bit thing;

One benefit may be the ability to run multiple apps at the same time .. in RAM.
If they were 64 bit you could probably run RB and BB (or for that matter any two or more 32 bit apps) at the same time with very little issue concerning resources, due to additional RAM. While they run at 32 bit they share the first 4 gig RAM. At least that's my understanding. Correct me if I'm wrong.

So while BB may not see any improvement itself from 64 bit, a given system may (depending on the apps being used simultaneously).
Just one theory.

Peter said it would be coming .. I'm patient. It's not been an issue here yet, due to work flow.

I believe you are correct, rharv. Actually I believe the programs would have at most 2.7 or so GB to share, after the overhead of Windows is subtracted from 4 GB.

So, in reality, there's really no argument here other than someone wanting 64 bit. Ray

My understanding is that each 32 bit app gets it's own separate space, and for practical purposes, it is 2GB of space. If necessary a 32 bit app can get more than that, using some tricks. Band-in-a-Box currently doesn't come close to needing the 2GB.

It is discussed further here...

http://www.brianmadden.com/blogs/brianmadden/archive/2004/02/19/the-4gb-windows-memory-limit-what-does-it-really-mean.aspx
"In the 32-bit Windows world, each application has its own “virtual” 4GB memory space. (This means that each application functions as if it has a flat 4GB of memory, and the system's memory manager keeps track of memory mapping, which applications are using which memory, page file management, and so on.)

This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space."

Please no 64 bit before genuine 6/8 & 12/8

Well said.

And count-in's that count in at the same time signature as the first bar of the song...

Peter are you absolutely certain about these facts? For a start I think that Windows used 1.3 gig approx., not 2. I am also very suspicious that 'each app gets its own 2 gig' is not exactly as it seems. I have always heard that 1.7 gig is the max with 32 bit architecture.

Another Reason to design in 64 bit: If there is going to be a future development of BIAB (beyond surface tweaks) , why do this in 32 bit? If, at some point in the future 64 bit coming (sometime, someway - like the song) better to develop in 64 bit sooner. Unless your thinking 64 bit is not the future, or we will never need it.

I would want to see a slick and powerful presence of "Son of BIAB" flexing its muscles in the big boys world, showing its impact as a VST/DXI. Your way ahead of the market in so many ways - check out Cubase 8's 'chord pads' trumpeted as a big feature - it's a toy in comparison with Band in a Box, but some of the visual ways it uses to display chord options are way ahead of you. There are so many potential uses in these pro sequencer pools that you are simply not reaching - good users, long term, dedicated, knowledgeable.


https://www.steinberg.net/en/products/cubase/start.html check out the Chord Pads video


Its not infeasible that 32 bit may go the way of 16 bit.. we get these surprising leaps sometimes.

I always had trouble with my 32 bit sequencer, on ten or so different PC's as soon as I loaded orchestral stuff. Then, as soon as 64 bit came along, everything stopped stuttering and just works. Simple.

Z

You folks are much more knowledgeable than I in these technical matters and ,as a result, perhaps you could clarify a point for me.

In in Peter's post there is a quote: "and the system's memory manager keeps track of memory mapping, which applications are using which memory, page file management, and so on".

One of the advantages to a 64 bit system, to my way of thinking, is that a 64 bit, using more RAM, allows a system to have less dependency on swapping to the page file on the hard drive. Is my thinking correct?

I agree with sixchannel.
I've got too many old programs that would be too expensive to replace.
The jump to 64 bit would be too costly for me.
You'd lose my yearly biab upgrade if the 32 bit biab disappeared.

FYI- 64-bit Win 7 Pro has a 32-bit emulator. Every old 32-bit program that I tried with it works, including Windows Office 97 and Corel Photopaint 7. Corel Photopaint 7 is a Win 95 program.

It was because of the emulators that I chose Win 7 Pro.

As most of you know I am a big proponent for 64-bit and in fact BiaB is the only NEW 32-bit program on my system. I am going to speak for myself but I do believe that many others wanting 64-bit feel the same way I do.

I do not want the current BiaB/RB just converted to 64-bit. I would like a complete rewrite in both 32 and 64 bit that includes but not limited to real support for time signatures other than n/4 (6/8, 12/8, 5/4, 7/4 etc), a better GUI, improved VST and VSTi support, chord input every 16th note, using all 16 MIDI channel as I see fit (MIDI, RTs, thru, MIDI guitar, etc), etc.

I know that this may be impossible with the current PGMusic staff at this time. However they do allow me to respectfully wish for such a rewrite. Thank you for that.

+1

Ok I'm late to the party on this one but I have a couple of questions. Is the current bar limit in BIAB which I think is 255 (correct me if I'm wrong) a limit imposed by the 32 bit architecture and thus memory limit? Or is it just that the programmers haven't figured out to do that yet? The track count we can currently have playing at one time is I think 7 if you count the melodist and soloist. Is that limit based on 32 bit architecture limitations or just a programming decision.

I ask these questions because everyone is debating whether or not there is any benefit going to 64 bit. If the answer to these questions is the limits are imposed by the 32 bit architecture than I would say yes there would be a benefit. Particularly the bar limit which has been a frequent request over the last few years.

If it's programming then how about we get these done before adding some fancy video editor. Also is the ancient UI (yes its still ancient) a limit of the 32 bit architecture? These are legitimate questions. These are things people have been asking for and since no reason has been given why they have yet to be implemented I think most people think it would take a 64 bit rewrite to get them.

Now in all honesty the program works for what I use it for and if I'm honest with myself I probably don't need a 64 bit version. I will say this though. Despite all the wonderful things this program does it looks old. There are a lot of people who will not buy it because it looks old. The fact that you can't buy a new 32 bit computer by perception alone makes this program old. How many more units could PGM sell if they addressed the UI alone? How much more legitimacy would they gain in the professional audio market?

I love this program, it has allowed me to create music I could never do on my own. If the questions I posed can be addressed in the current 32 bit system then lets get this done. If it requires a 64 bit rewrite to get them then lets get it done and quit moaning about it. Everybody benefits.

The 32 bit version is great and if they stopped developing it today it won't effect any current user. Why all the 32 bit guys are afraid a 64 bit version will somehow change the 32 bit version to no longer work or be available I don't know. It is what it is. The 64 bit would be a new product ( a stand alone product) or at least it should be.

Jeff, I could be completely wrong, but I don't think either of the first two examples you gave are related to the difference between 32-bit versus 64-bit architecture of the application program or operating system.

255 is actually an 8-bit concept. The range from 0 to 255 is 256 total values, expressed as 2 raised to the eighth power. The architecture of the program or operating system has not been the limit for that for many decades, and the answer to why there is the 255 measure limit lies elsewhere.

As for the 7 usable channels, I believe that limit is related to one bank of MIDI that has 16 channels. You may only see 7 but there are more used when you have the guitar broken out into separate tracks for export, and/or use the MIDI harmonies available in BIAB from the pull-down menu. For example, take a look at Preferences, Channels and then click on Harmony. You will see channels 11 through 14 used for harmony. In other words, there goes four more tracks in addition to the more obvious seven that you thought were the limit. MIDI channel 1 used to be commonly used by some programs for control information, so there goes one more...

Exactly. Outstanding summation, Mario. To me, this one would be the most important:


"...chord input every 16th note..."


I must say that I find it amusing that with a program that does all this one can do, people constantly complain about bit depth, graphics, menus, etc. Sure, every user has a wishlist of changes that would benefit him/her personally. Chord input every 16th would would make BIAB 500% more useful to me, but to someone else? Who knows?

I lack the technical knowledge of the computer experts here (Like Dr. Gannon), so I'm not qualified to voice an opinion on 32 vs.64. In fact, reading this thread gave me a headache.

I have been using the program for a few years now though, and I've barely scratched the surface of it's capabilities. It is the greatest songwriting tool every invented.

Now, if it only had chord entry every 16th, it would be the greatest greatest songwriting tool ever!

Aaarrrggghhhh!! (not you 90 DB, you are just the last post I'm attaching to)

I worked with a guy who is famous (in very small closed circles) for saying:

"There is no horse so dead it can't be beat some more"

but even he would think this thread is now bordering on the absurd.

So may as well jump in here - but first let it be known I am above all an unabashed free market capitalist pig (who would have pulled out finger nails - not water boarded), but I digress.

Back to BIAB: that crappy, slow, dodgy, never runs, can't possibly make any music with it (because it looks ugly, duh? Susan Boyle is no model either), POS software which, can't even load ubiquitous terabyte and awesome unlooped side stick rim shots or petabyte sine wave flutes.


OK here's what you do to fix PG's wagon:

1. First, and this is important: only those experienced programmers, who are obviously working on bleeding edge classified real-time SW for LM, Boeing, Raytheon, other, but unnamed, corps., etc., and who have hands-on expertise in AdA and other real-time critical appropriate languages (C++ is NOT - but pretends to be) force PG to go public. (with those qualifications and being tops in your field of writing RT SW - how you folks also have time to write Grammy, CMA, … winning songs is beyond me).

2. Now this group needs to pool your money and buy at least 51% of the now public stock.

3. Then get seats on the board and fire the President (wish I could fire MINE), and fire the CEO, CFO, COO, CPO, CM(usic)O, and all other PG staff.

4. Then hire all new staff (but I guess you do not really need to; because, you are already better than PG staff)

5. Then do a slick re-write so that BIAB looks shiny new like polished chrome and glass. Also make it web based, think first "Open Web DAW" (analogous to Office 360, etc. ). And since you are all that good you can even make it run real-time over the web to sample accurate timing levels so all users can jam together with no lag time (unlike us mortals who can't do this on high speed data links).

6. Also we don’t want to leave anybody out or hamper their ability to modify at will and "have it their way" so may as well make it open source code as well. The plus here is that you have bragging rights over the much vaunted an oft pointed to Reaper because even they don’t have open source code (those money grubbin' has beens).

7. Don’t want to be "behind the times" so this flawless, bug free, complied code should require MINIMUM PC specs (for this 21st century AHAB[iab] "Acerbic Human Arranger of Bands [in a box]) of :"

i7-5960x or better (min clock 4ghz), 32 GB DDR4 3333MHZ RAM, Win 9 (since it's almost here), with MINIMUM HDD access times no less than SOTA solid-state drives (using CY 2014 reference period).


8. Now sell it for a break-even price of (to the scores of users who buy it)? This is all altruistic right?

Larry

Larry, I love the "Windows 9" part, as Microsoft skipped right over it! [I think 10 is great so far]

Ditto that!

Thanks for the clarification Matt. I don't use midi very much and rely on real tracks almost exclusively so I was operating under the assumption there are only 7 tracks.

Jeff, you're welcome (assuming I was even correct). I've long ago come to the conclusion there is an awful lot we users do not know.

JC, this is a good question, but deserves it's own topic rather than simply tagging on to the subject of 64 bit programs.

Why did I know there would be ANOTHER Donnybrook on the 64 vs. 32 bit saga.

Lots of interesting posts but I just have to say that the "etc." and "21st Century" comments are unhelpful to say the least.

Given the significant size of this thread and the massive aggregate size of similar threads, comments and explanations of SPECIFIC "A vs.B" examples are all too rare.

BIAB works fine for me but I must admit I've not attempted to configure the software so that songs could be written during the 3g phase of the next spacecraft launch.

Such a pitty.

Or maybe we should have an interface so that we could attach a biab hard drive to a Drone and write songs while the HD is on its way to a collaborator. Think of all the bandwidth we'd save not having to e-mail the file!!!

(-:

Jim

Ok, that was a good old chin wage, served zero purpose, now lets get back to PG DOS in 2016.

Reviving this tread from a year ago doesn't take ANYTHING away from me enjoying the goodies in BIAB 2016 32 Bit one BIT!

'nuff said....

TBH, I am a dedicated 64bit PC person, however I don't really have any issues with BIAB being native 32b. I have not come across any problems caused directly by this. And using external 64bit applications is well covered by J-Bridge.

I guess from a "purists" p.o.v. it might be important, but from a real world perspective, and jmo of course, all runs as it should.

Gentlemen,

Not wishing for a pillow-fight with anyone here, but I think I have a new point to make.

I read through this thread fully, to be sure whether my following point – about a very specific, useful, real-world benefit which a 64 bit BIAB would bring, for me and I suspect many potential new users as well – had been dealt with squarely and decisively before posting here.

I believe it has not – although it has been mentioned a few times, sometimes as though it were a settled question.

In summary: Having tested this, I believe – correct me please if you've actually experienced otherwise – that while you can, within BIAB, use jbridge to run a 64 bit VSTi like Kontakt, you cannot load that instance of Kontakt up with more than a couple GB of of libraries, the way you can with a 64-bit host.

In detail...

I have invested a lot in some very nice Kontakt libraries. I am not being snooty here, but they sound simply worlds better, in my opinion, than SampleTank or any of the other things in 32 bit BIAB through which we can play out midi. I think this is the reason that Kontakt is, I understand from other forums, very commonly used as a staple tool by professional composers, whereas Sampletank, well … a lot less so.

Some of these Kontakt libraries are hugely RAM-intensive. I have had multis (or collections, in Kontakt-speak) of orchestral instruments going fine in 64-bit Sonar, where around 9 gb of samples were employed. I went 64-bit, when I got a PC with 16 GB of RAM, so I could do just that.

Yes, when j-bridged, 32 bit BIAB will let me load up and play libraries in 64 bit Kontakt – but only if the Kontakt instruments stay below the memory limits imposed by BIAB's 32-bit design.

But I cannot load that same 9 gb multi into Kontakt when using it as a VSTi within BIAB. Someone in this thread mentioned that they had not “torture tested” this. Well, I have. It triggers “Kontakt out of memory” errors. As you'd expect. Jbridge allows 32 and 64 bit software to communicate, but it does not give BIAB the RAM “heavy lifting” power imposed by its 32-bit design. It doesn't suddenly suspend the memory “law of gravity” which, as I understand it, constrains all 32 bit programs.

I know there are workarounds. For example, I can load the best midi playback device available in BIAB, then start creating a song, browsing styles etc – but in the end, I have to imagine, when auditioning things, how it would sound through my ultimate intended soundset (i.e. Kontakt). If I want to hear it through Kontakt, I have to stop, export my all my candidate arrangements, load them into Sonar, play them, then decide if I'd chosen well … if not, then back to BIAB. This sometimes takes many iterations.

This works, but – apart from being a bit of a pain in the old rump roast – it deprives me of something very powerful – when inspiration strikes, the ability to hear the intended result while composing. Because what you hear in turn affects what you compose (which includes, in BIAB, which styles you pick, what variations you apply, etc). We all know this virtuous feedback loop.

Now, imagine, for some bizarre reason, you wanted to write a Hendrix-style guitar part, but restircted yourself to doing it on an acoustic, imagining how it would sound after being run through the magic pedals and amp and played with a whammy bar.

Or it's just like in Photoshop, you expect to be able to see the changes you've instructed as you make them. Imagine if Photoshop permitted you only to specify changes (for example, adjust contrast by x%, saturation by y%) but you'd have to view the results in other software. You'd do a lot of back and forth, wouldn't you? And maybe murmur “h-e-double hockey sticks, why is this necessary” a few times, I'd suspect.

That is exactly what I do when I want to use BIAB's midi styles for multipart compositions written for my preferred Kontakt libraries. The workaround is not only a pain, but it is just not the same. I lose the feedback loop.

Moreover, as nice as some of the Sampletank patches are, they sometimes sound so different from the Kontakt ones that I'd use, that the Sampletank patches are not a useful guide to me when I am auditioning styles. Sometimes something will sound great in Sampletank but not Kontakt, and vice-versa. For example, I have a Kontakt cello with programming which permits very expressive legato playing. Sampletank's cello (even from Miroslav) will shed little light on what the midi it's playing within BIAB will sound like through the Kontakt cello.

For this reason, I don't use BIAB near as much as I'd hoped to. For RealTracks it's brilliant, and fine in 32 bit. For midi, when using large libraries, it's off-putting. It's a genuine obstacle to music- making, not some groundless whining about 64 bit for its own sake.

It's been mentioned here that it seems most BIAB users don't care about 64 bit. That could well be true, if we are just talking about present users, and we assume they are fairly represented on this forum.

But if you want to talk about additional, new users – you know, the ones who aren't here yet? – well, could it be that they are not here because they never got past the – to many, now ancient historical – “32-bit only” drawback. Outside this forum, it does seem pretty horse-and-buggy, an easy reason for folks to not even investigate.

Think about it. BIAB is so powerful – it could easily could be, say, a professional composer's best friend, or at least one of them. But professionals these days use 64 -bit, and have for quite a while, so they can access the power of Kontakt, UVI and other RAM-hoggy but top-flight virtual instruments which they have come to take for granted. You're not hearing their voices here, because they're not here.

The realstyles are wonderful, but that forces you to work entirely within BIAB, and that is just not a platform that makes much sense for any professional writer/arranger.

I do use BIAB quite often to create a starting bed for arrangements. This is always a MIDI -based process because that is the only practical way to get the material to line up in the notation program. The end result is a notation file that can support playback that sounds realistic enough for demo purposes.

I don't see the lack of 64 bit as being as much of a problem as the general lack of priority on MIDI-based styles. Most of the newer BIAB styles cannot be saved to MIDI. They added 201 RealTracks and 3 MIDI tracks in this release!?

I really don't get the obsession with RealTracks in a world that is moving so quickly to DAW / VST technology.

All I could add to that is that I have used ViLabs Ravenscroft Piano (32gigs) and 64bit version, with no issues, along with a couple of instruments in Sampletank 3 (also 64bit). Maybe I was lucky, but I didn't notice anything crashing - although maybe those two are not really pushing the limits..?

Don't get me wrong, I'd LOVE BIAB to be native 64bit , all I'm saying is it seems to work okay with J-bridge for me.

Lingyai, I'm in the same boat!

I did not test the limits as you have because I found that using jBridge to be a PITA (no hate mail please this is just my opinion and YMMV).

Because of BiaB is 32 bit I do no editing in BiaB. I just find a style I want, move tracks to Sonar and do all of my editing and sound selection there. I also have a lot of excellent Kontakt sounds as well as a number of other 64 bit VSTis. I would love to do a lot more work in BiaB, it would be easier in the long run for reasons that you have mentioned, with these 64 bit VSTis.

RTs are the main stream of BiaB now. They are excellent and have their place, I use them almost exclusively for clients who want to do a CD for family and friends, but I rarely use them myself. MIDI is the main stream for the rest of the music business.

Although I find BiaB very limited because it is 32 bit I also find it very useful and in fact virtually all of my songs start in BiaB. I will upgrade again but probably just the program upgrade. I wish that BiaB would put more emphasis on MIDI and 64 bit because like you I can see a much bigger market for it, again just my opinion.

I agree that

-- the RealStyles are superb (unlike you, I do find they definitely work in some of my own stuff, in fact in some cases really push it to a next level); they are a truly unique selling proposition for PGM, deservedly so, for me they are up there in the Pantheon of Innovations alongside the likes of Melodyne, just revolutionarily great. So I will be upgrading just those for those. (Actually, I wish there were a way I could just get the new styles instead of updating the whole app, but I digress)..

but

-- yeah, midi opens up the doors exponentially in terms of what you can do with the results. So, as a tangent, I wish PGM would beef up the library of the various midi-based styles, it seems they are like the poor cousin. The apparent success / popularity of VSTIs like EZKeys shows there is demand for well-executed chord and style-based midi composition software.

>> Yes, when j-bridged, 32 bit BIAB will let me load up and play libraries in 64 bit Kontakt – but only if the Kontakt instruments stay below the memory limits imposed by BIAB's 32-bit design.

Kontact is a 64 bit VST - it is using the memory, not jBridge or Band-in-a-Box (have a look at Band-in-a-Box memory use when you load that 9GB VST- it won't budge - because the VST is just passing it buffers of audio during playback that are then discarded by Band-in-a-Box after use.

So if it (the VST) is telling you that it is out of memory, then the 64-bit VST is out of 64 bit memory. There is no 32 bit limit for VST's jBridged to a 32 bit app like Band-in-a-Box. Perhaps you could be more specific than "out of memory", such as what app gave the message, and what did it say exactly.

If you're using a 9GB sample library, you're already over the memory limits of Win7 64-bit Basic, and it of course depends what other apps you have running, and how your VST manages memory when loading in different VST's - if it keeps them in memory, then you could easily get "out of memory"

Physical Memory Limits: Windows 7
Version Limit on X86 Limit on X64
Windows 7 Professional 4 GB 192 GB
Windows 7 Home Premium 4 GB 16 GB
Windows 7 Home Basic 4 GB 8 GB
Windows 7 Starter 2 GB N/A

The next time you get an error message about out-of-memory, open task manager and see what-memory us being used by what-program

Thanks Peter for your response. In this case I am using Windows 7 64 Pro ; and as I mentioned, the very same 64-bit Kontakt multi which works fine in 64-bit Sonar won't in 32-bit BIAB.

Do I understand you correctly to say that this being the case, it should run from within BIAB ? Have you or your colleagues actually seen this happen in a test?

Just to clarify -- you had all 32 gb loaded and used within BIAB, and it worked fine? Or is that the total library size, only a portion (for example, with only certain .nkis loaded and / or unused samples purged) actually resident in RAM?

That's physical memory. Aren't VSTs concerned with VIRTUAL memory?

64-bit apps can default to the old 2-GB address space. Maybe that is what has happened here. A 64-bit app should have access to 8 terabytes of virtual memory.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384271%28v=vs.85%29.aspx

Regarding the copy protection... I had never been a fan, but understand that an audience of musicians (being a particularly impecunious one) means the likelihood of piracy is much higher than an Accounting program for example. I have had a few cases where re-installs of my OS have chewed up my licenses, and PG Music has always been gracious and fair about restoring my lost ones.

Were this not the case, I'd be upset, but we are dealing with a highly ethical and customer-focused company.

Lingyai,

There is another approach to the issue of hearing a composition as intended without having to switch back and forth between programs: ReWire. Following are the beginning paragraphs of the linked Wiki entry.

"ReWire is a software protocol, jointly developed by Propellerhead and Steinberg, allowing remote control and data transfer among digital audio editing and related software. Originally appearing in the ReBirth software synthesizer in 1998, the protocol has since evolved into an industry standard.

"Currently used in Mac OS and Microsoft Windows 32-bit or 64-bit audio applications, ReWire enables the simultaneous transfer of up to 256 audio tracks of arbitrary resolution and 4080 channels of MIDI data. This allows, for example, the output from synthesizer software to be fed directly into a linear editor without the use of intermediate files or analog transfers. There are also provisions to remotely trigger actions, such as starting and stopping recording."

I have successfully used ReWire to link Steinberg's Nuendo DAW and Propellerhead Reason 3, which was then only a soft synth and effects suite, before it became a true DAW in its own right. Most major digital audio software incorporates ReWire, but not PG Music products. I and others have been requesting it for many years, believing it to be the solution to many issues.

I urge you to read the linked Wiki piece and consider whether it might address your needs.

Richard

But again, if you want to synthesize in a different program / space, you need to get the MIDI from one app into the second app. Rewire can synchronize the timing, but a problem here is that PGMusic seems to be moving IN THE OPPOSITE DIRECTION strategically. The early versions of styles were all 100% MIDI based. Now virtually all of the development is on proprietary sounds that can only be synthesized from inside the PGMusic products (RealTracks, RealDrums).

In short, BIAB simply doesn't play well with other products any more. That seems an awful shame because BIAB is such a wonderful tool

AFAIK, Ravenscroft, Sampletank and others (probably Kontakt too) with these large sample libraries actually stream from disk, they are not loaded into RAM...it is the "modelling" VSTi's that use RAM exclusively. I have not heard of a modelling VSTi that uses more than 4gig of RAM at any one time. Streaming VSTi's, well at least to my way of thinking, have, relatively, very little effect on RAM.

So I would tend to agree perhaps with PG, that your "out of memory" problem could indeed be coming from somewhere else and not BIAB/J-Bridge....btw what version of J-Bridge are you using? AFAIK, you need at least 1.7b for 64bit bridging to be successful. I had some issues when I was using a lower version of J-Bridge, but once I updated it, no issues at all.

Not saying you are incorrect in your experiences, all I can write about is mine, and maybe it might help "jog" something you recall about your system which may help.

With Kontakt, you can watch it loading the samples. If you use Session Brass in performance mode, for example, it takes a long time to load and it loads about 2GB of data before you can use it.

Pumps2, I'm not sure the "direction" is relevant. Each program does what it does best, but operate from a common transport control.

It is true that one program must be designated as a Master and the other as a Slave. Most ReWire-equipped programs can act as either (although, oddly, Propellerhead's flagship product, Reason, cannot). At any rate, as I envision this, audio and MIDI would be moving from BIAB into another DAW, which itself could also record audio. That's how it worked with the Reason/Nuendo lashup.

Richard

For the 32 vs 64 bit discussion ... it doesn't have to be one or the other. Most every piece of music related software I own has an install option for 32 or 64 bit. And in most case, you can install twice to have both versions available.

…Except PG Music products, which is where this conversation started.

No 64 Bit for BIAB 2016 is very disappointing. I'm still not upgrading.

My point was that having a 64 bit version of BiaB doesn't have to mean an end to 32 bit versions ... which some folks have expressed concern about.

I'll use more words in the future

Good answer!

Ditto that!

Oh for goodness sake, let it go

Wait - I saw it move!!

I Can't Go For That (No Can Do)

What your saying is? Getting PG Music to support 64 bit is like beating a dead horse.

Ouch. I'm not sure PGMusic would be proud of that statement? Especially in the software world where things are always changing fast. To imply that a software company is unwilling to move forward is a great insult to the company.

In the end it really doesn't matter. Laptops and personal computers are becoming less popular every year. I have several musician friends that don't own a tradition computer.

If iRealPro keeps developing it's software PGMusic will have to play catch up in the portable device market. I purchased both the BIAB android apps. They are a joke. I use iRealPro for my portable devices.

Check my understanding:

"BiaB Android apps are a joke." is better than "Getting PG Music to support 64 bit is like beating a dead horse."

Is my understanding correct?

I now believe the 64 bit support is like beating a dead horse.

A fully functional Android option "without the clumsy sever stuff" is still a viable market that PGMusic would be wise to jump into early.

iRealPro as good as it is, doesn't sound nearly as good as BIAB. Then again it only costs $12.00. But, it has a much friendlier user interface and you have 1500 songs "chords only" in a matter of minutes downloaded from the iRealPro forums. You also never have to pay for upgrades.
The reality is, most people just need this kind of software for practicing and iRealPro works great for that.
But for people wanting high quality play along tracks that can be made without the confusing server option "I feel the server stuff defeats the purpose of having a portable device." I think would be willing to pay upwards of a $100.00 for an Android option that sounds better than iRealPro. Especially people who want to perform with a BIAB Android option.

But then again. If PGMusic isn't willing to compile their current code to work in 64Bit, then I'm guessing making a great Android OS version is out of the question.

I think it's ironic. We first pay for many upgrades that clutter the user interface, then we have to pay/upgrade to get a friendlier user interface.

Just so you all know my purchase history. I have been using BIAB since 1998. On average I skipped an upgrade once every three years. I have willingly given thousands of dollars to PGMusic.

I'll say it again. I will not purchase another upgrade until they release a 64Bit option. There is no excuse at this point. Windows 7 was the first stable 64Bit Windoes OS "XP 64Bit had issues" that was released in 2009. Almost seven years ago now.

I'm wondering if a new 64 Bit Band-In-A-Box is coming in 2017? I'm still using my 2014 version of BIAB. It works perfectly and I have no reason to upgrade unless 64 bit is implemented. BIAB one of the last audio apps made that doesn't offer a 64 option. So far I've saved around $450.00 in upgrade charges. Either way I win. If 64 bit is implemented I will be the first to buy it. If no 64 bit, then I get to keep my money.

Me too now believe the 64 bit support is like beating a dead horse me too saving $$$ so I can buy new Behringer UFX1604 direct to disk 16 ch recorder/mixer

http://www.pgmusic.com/forums/ubbthreads.php?ubb=showflat&Number=376200

43993 hits on this post ???? no we don't need 64bit.

As I said before, I would prefer to see resources spent on fixing old bugs, modernizing / flexibilizing the GUI and enhancing existing features (music XML, notation, layers, proper support for all time signatures, help system, hold / shot / slash chords, endings, undo command, etc, etc, etc...)

I'd like to start saying that I don't have any insider info.

But, having said that, I don't think that BIAB 2017 will be a 64-bit app.

And, as all my other music-making apps they've been 64-bit for some time now, I'll most probably skip the upgrade.

HTH,

And it begins

I've seen this topic come and go over the years and I've tended to ignore it. Mainly because I have no need for 64 bit. I suspect that it becomes an "economy of scale" issue for PGMuaic, much like the PC/MAC issue of some years ago.

At that time, there just didn't seem to be enough Mac users of BIAB for PGM to devote resources to its development. When there finally WERE enough of these PGM began their mid-year release of an upgraded Mac version.

So, PGM looks at the sales volume increases over the last several years (I'm assuming there's been increases), and compares that to the amount of resources it would take to develop a 64 bit product vs how many users WON'T upgrade if there's no 64 bit.

It all comes down to the numbers.
Of course all of this is merely conjecture, and I may be way off base. It's just the way I would look at it from a business point of view.

My 2cents CDN.
LLOYD S

I could care less about 32 vs 64. As long as it works on my machines I'm happy. I upgrade every year for the additional real tracks. In the past upgrades cost $100 for everything and I get 201 new RT's 50 cents apiece. How can I go wrong? Everything else is just more candy!

If there is just one really useable RT in the bunch it means I don't have to pay $50.00 an hour for that paticular studio musician, The third hour and beyond is free!!

The issue here is not 64-bit per se because every "Windows 64 bit" machine has lots of stuff running in 32-bit mode. I believe the issue is in being able to use one's full collection of VSTs with BIAB directly. That is more than just 64-bit support. PGMusic should be looking at evolving the mixer section to not be a full-function DAW, but to be a bit more flexible in the use of VSTs. BIAB should support less limited effects chains.

Most VSTs are shipped with moth 32-bit and 64-bit versions. However, BIAB is one of the few music/sound oriented programs to not provide 64-bit support, so many of us would consider it a real nuisance to maintain 32-bit VST libraries just for BIAB.

Regarding the market, I have trouble believing that any XP or Vista user would be interested in paying hundreds of dollars for the latest BIAB release. Windows 7 is about half 64-bit. Windows 8 and 10 are almost entirely 64-bit. I guess there would be a few users who have not invested in 32-bit and still want to spend hundreds of dollars on BIAB software, but not many, IMHO.

Obviously PGMusic could support both flavors for a couple of releases if they were really concerned about that. It isn't such a big deal. Many other software suppliers do that.

My feeling is similar to Pumps2. I like the stability of my all 64-bit plugins and wouldn't consider purchasing new software that wasn't 64-bit. However, since there are so many aging PCs out there, I think it will be quite a few more years before 32-bit apps disappear; maybe decades.

Windows can check online for a solution to the problem:
Windows found I was trying to run 64bit dll's in an old 32 bit application...to solve this error please consider updating to a 64bit version of the application.

If PGMusic is genuinely concerned about the cost of maintaining parallel 32-bit and 64-bit versions and is genuinely concerned that eliminating the 32-bit option would cut off too many users, it seems to me there is yet another option.

Most users are interested in the additional styles more than the somewhat limited enhancements in the base engine. So PGMusic could freeze the 32-bit path at 2016, but continue to offer styles to the 32-bit community, as these styles should work with either platform.

Why.....!

Radio stations across the world now play Mp3.

The sound is absolutely terrible...till I get home and play the same song on my 1982 separate hifi system on cd.

What good would 64 bit give us as biab users ?.

Because I pop in to this forum listen to the tracks posted and they sound as good as the .....60s...70s...80s..after that they compress it down to a fuzzy rabble.

I am really wanting to know what would be the gain...other than a number.32 or 64....?

Feel free to enlighten me Thanks

There are lots of threads here that could help you with that. My main interest is accessing more RAM and benefitting from the stability of all 64-bit plugins.

Sound "quality" involves a lot more than bit depth and compression levels. There is a whole universe of technology that can do amazing things to enhance the overall impact of the sound. When I take BIAB tracks into a DAW where I can use the full palate of tools, I can create a much higher impact product. In most cases, if I could simply use some of those effects directly under BIAB, I could get close to the same results with much less work.

In short, the sound coming out of BIAB today might sound pretty good compared to the days of tinny sounding GM softsynths. But it is an UNPOLISHED sound, clearly inferior in a world that raises the bar every year. PGMusic really needs to play better with others. Their strategy of ignoring the rest of the music technology world and trying to lock their users into a walled garden is just not very appealing to me.

And for the same reason, I have very little use for the PGMusic realtracks. Give me great MIDI lines and I can run that through the best VST instruments out there.

We made do with 16bit that was ok we got by with it, was going to 32 any better ?
Was windows 7 64 any better than Windows XP 32 ?

Render track 32bit




Render track 64bit less than half the time

PUMPS2 Sound "quality" involves a lot more than bit depth and compression levels

Exactly what I was saying..!

PUMPS2 When I take BIAB tracks into a DAW where I can use the full palate of tools..

Do you mean you can use 64 plug ins...?

PUMPS2..I can create a much higher impact product

For if and when you are a producing artist the radio stations would turn it to mp3...what bit rate then...?

PUMP2..In short, the sound coming out of BIAB today might sound pretty good compared to the days of tinny sounding GM softsynths. But it is an UNPOLISHED sound, clearly inferior in a world that raises the bar every year

What bar we are going back the way with recordings not tinny synths...No to the way we listen to music...android ...ipad ...cmon you know fine what im saying.


And for the same reason, I have very little use for the PGMusic realtracks. Give me great MIDI lines and I can run that through the best VST instruments out there.

PUMPS2..And for the same reason, I have very little use for the PGMusic realtracks. Give me great MIDI lines and I can run that through the best VST instruments out there.

Can you put your chords and do all those things we do in BIAB..THROUGH your VSTI out there...


PUMP2...This sounds a bit dated your own words.... Give me great MIDI lines and I can run that through the best VST instruments out there.

pipeline +1

Yea thanks Matt its like the microwave against the conventional oven. Only worse...

Take care

I mean when I want something to actually sound presentable -- something better than I would use for strictly basement practice purposes, I either pull MIDI from BIAB or else I render WAVs for EACH INSTRUMENT from BIAB and then run it into a full-blown DAW environment. And yes, these DAW environments are almost exclusively 64 bits these days -- have been for most of a decade.


I don't think you understand what I am talking about, or I am doing a very poor job of explaining it. MP3 is irrelevant. I can give you a great sounding MP3. Chances are it will be 320 kb/sec. I don't often use anything less these days, and increasingly people are using FLAC, which has no bit loss at all. The losses over the radio waves are far greater than any fidelity loss from MP3 at those bitrates.

Nonetheless. I can take a file coming directly out of BIAB and put it into MP3 @ 320. And I can take that same material through a DAW and mastering tools, also ending up in MP3 @ 320. It will be night and day. I am not joking here. If you have not experienced that, I really recommend that you do that. I think you will find that a very educational and rewarding experience.


No, I really don't know what you are saying. I think you are confusing the speaker fidelity of the device with the content of the music file. As I said above, I can give you an MP3 that sounds great -- and I can make a big improvement on any file that comes directly out of BIAB. Yes, obviously, if I try to play that file on an Android phone, it won't sound like much. But with good headphones and/or a nice stereo Bluetooth speaker, the quality will be evident.


Yes. I can generate MIDI from BIAB and run it into a DAW, then render it with VSTis. I would far prefer to use Addictive Drums, for example, than any of the drum audio that comes out of BIAB, because I can control that sound to an gnat's eyelash. If you have not worked with these tools, you should try it.

Or I can render each instrument in BIAB and move each instrument's WAV file to the DAW. I do both techniques routinely. I would rather use MIDI because then it is easy to align the bars and beats in the DAW, which is useful for many things, such as synchronizing a delay each to the beat of the music.

In addition, I often take MIDI from BIAB into a notation program -- not to notate the MIDI, but to include a rhythm section bed in an arrangement, for example. This is why I say the MIDI output is far more useful to me than the RealTracks.

I think the fundamental issue is that BIAB started as a practice tool. It gradually evolved to something higher quality, but the authors and majority of the user base were comfortable with the walled garden. During that same time, we have seen an explosion of tools that really do work together, and BIAB does its best to not play nice. There is a certain percent of the BIAB user base that is very much committed to this broader music technology world and finds PGMusic's insular approach to be out of line with what is happening in the broader space. It is a shame that PGMusic looks at it this way because there really is no reason why they cannot excel in both market segments.

Pumps2 - I use MIDI for the same reasons as you.

I think there is a great misunderstanding when it comes to MIDI. Some think all MIDI sounds like the inexpensive GM sound source that comes with BiaB. Some find it to hard to work with while I find it much easier to work with than audio. But on the down side good sounding MIDI sources has an extra cost factor and MIDI has another learning curve.

99% of my work involves MIDI. The other 1% is RTs that I use for other peoples songs.

YMMV

+1 Same here

TBH, I reckon a lot of people should listen to a lot of the real tracks in isolation to hear just how clumsy a lot of the recordings are. Metronomes in the background, chair noises, audio artifacts,human noises etc can all be heard. Of course when in among other tracks (especially drums) these are not really audible, but when trying to use guitar tracks in isolation for simple piano/guitar tunes it can be annoying.

I only write this to suggest that there are far more important things (including incorrect chord generation - maj for min, min for maj etc-, real 6/8 RT instrument tracks, proper compound time chord sheets and so on and so forth, that need to be done before we worry about getting 64 bit. For the record I too think the code should have gone 64 bit ages ago and bridged 32 bit plugs (not bridge 64bit plugs to 32bit OS) to run. Which is the way pretty much most modern audio software does things.

+1 for me also

Thanks MJames for starting this thread, over 45,000 views, correct me if I'm wrong but I have not seen another topic in the forum ever with this much interest.

Pretty sure Our forum member Don Gaynor has the record which I believe exceeded 1,000,000 before it was taken down.

What was the topic about ? "before it was taken down." Free Po#n ???

Jokes, jokes and more jokes. One or two of them was actually funny.

Jokes from the Internet, otherwise known as jokes taken from copyrighted sources with no attribution.

this thread isn't isn't even close - and less useful

There's a lot of Reaper users 32 and 64 but they don't fight, I wonder why ?
There is even a Linux version coming. That guy that made WinAmp must be crazy.

REAPER is just fantastic programming. Using 64-bit version of REAPER you can load 32-bit vsts without any issue. I think it works the other way round too loading 64-bit vsts into the 32-bit version although I can't see many people doing that. I have loads of 32-bit vsts operating just fine in REAPER 64-bit. I don't see the big concern about BIAB needing to be 64-bit as I don't view it as a DAW. I tend to use it to output the song backings and drum parts which I then load into REAPER and work on further.

I don't think we fight I think we have:

One group that doesn't care or need 64-bit BIAB and this makes the 64-bit group distraught for some reason.

My assumption is; if I purchase the audiofile edition of BIAB it uses .WAV files for RealTracks instead of the claimed lossless .WMA files in the budget version that I can afford. My assumption is also a much higher quality end result, uh, dependent on the user, of course. Perhaps sound quality-wise I would have no desire for 64 bit version. But, only for compatibility issues.

There have been many views expressed on this subject and it is fair to say that most have some merit
I have been with Biab since the floppy stage and thought at the time that is was the "LAST WORD"
Since then it has improved rapidly year by year astonishing me with the advances made meaning we can ENJOY our music with near studio like results
PG Music and its staff love music and also throughout the years have made good business decisions and re-invested their profits in to making bb the force it is today
Everyone has the right to buy or not to buy but should acknowledge that PG Music is one of if not the best companies to deal with and I have always found them to be highly responsive - courteous and approachable right up to Peter himself
Whether as a former beta tester or a regular user my suggestions/problems have always been dealt with promptly - efficiently with a resolution
PG Music, is at the end of the day, a business and I trust them to progress this wonderful program forward to the benefit of the company and us the user knowing that suggestions we make will be listened to and acted upon where appropriate
I am a better musician because of BiaB and the PLEASURE it gives me in music terms keeps the technology part in its rightful place

I don't think so. I think that one group doesn't care or need 64-bit BIAB while the other group does care and needs 64 bit. I am in the later however I will upgrade if there is something in the upgrade that I might want or need.

I believe you are correct that going to 64-bit in itself has no effect on audio quality. I just wanted to mention that I do not think PG Music ever referred to their .WMA files in the 'regular' version of BIAB as being lossless. They are not.

There should be no affect on audio quality between a 32-bit BIAB and a 64-bit BIAB. I suspect some folks are confusing 64-bit application memory space with audio bit-rate settings (which would affect audio quality).

I've followed this thread and the other similar ones from the sidelines but your post here is the best expression of the value of BIAB 64 bit enhancement for me and my use that I've seen.

Dr. Gannon has stated elsewhere that 64 bit is not an enhancement to BIAB or accessed by the core programming. You are quite correct in your statement that an entire universe of audio enhancement products exist that musicians, engineers and producers of every level of expertise have or can access.

There already exists a simple and clear path from BIAB that technicians at each and every level of expertise can use to give BIAB midi/RealTracks/Realdrums and midi supertracks access to this universe.

I think the end result this upgrade presents is we get another product that enlarges the existing audio enhancement universe but has no effect other than a minor convenience to reach a portion of it from within BIAB. No additional BIAB memory access. No additional channels. No 24 bit resolution or no audio enhancement of the existing audio tracks that benefit the entire BIAB community and not just the community of 64 bit users.

However, my guess is that the entire community of BIAB will suffer a significant price increase given the manhours, research and development, reprogramming and software development required to convert and upgrade the program to 64 bit.

How many 64 bit proponents will abandon the external existing audio enhancement universe, their preferred DAW and go to exclusive use of BIAB when it becomes the convenient 64 bit? None.

Likely, this 'upgrade' will lead to "now that we have 64 bit, we should be able to _______. So we need PGMusic to develop this next functionality."

Is zero enhancement of existing internal BIAB audio and zero abandonment of the existing audio enhancement universe = Entire BIAB community suffers price increase truly a value? BIAB has many strengths that would better benefit development in my opinion and would be more palpable to accept a price increase. No offense to anyone intended, nor is this an attempt to change any minds. Just a statement of my understanding to the value of a 64 bit version of BIAB.

Audio quality is my greatest concern. As stated in my previous post, I don't think there is any shortage of existing tools that will do a better job than a 64 bit BIAB program.

Pumps2 - "When I take BIAB tracks into a DAW where I can use the full palate of tools, I can create a much higher impact product. In most cases, if I could simply use some of those effects directly under BIAB, I could get close to the same results with much less work.

In short, the sound coming out of BIAB today might sound pretty good compared to the days of tinny sounding GM softsynths. But it is an UNPOLISHED sound, clearly inferior in a world that raises the bar every year."

I think his remarks are right on the mark. So, to me, is a significant upgrade that will get me "close to the same results..." be a worthwhile venture leading to an increase in the cost of the program for everyone?

Well, that sounds to me like an argument for Microsoft never progressing beyond Word 4 (anyone remember that one?). After all, with Word 4, it was technically possible to come up with a way to complete just about any document, if you were willing to work really hard at it and make some compromises.

In an industry segment that has progressed so rapidly, I find it really hard to justify Band-in-a-box's 1990s level of compatibility and presentation. Yes, BIAB enthusiasts can find ways to work around the arcane BIAB interface to get the end result they want. But it makes very little sense to me that this could actually be a good thing for the marketing of the product.

So just to be clear, I view modernization of the core product (64-bit) as being part of an overall modernization that should include easy, immediate access to all popular VSTis and VSTs without having to hack the product. (That should include automatically scanning for VSTs, as most other products do.) It should include unrestricted chains of effects, not an arbitrary limit of 4. It should involve a MUCH better user interface that includes the ability to undock panels and move them to second and third monitors, and so on. We are trapped in 1995 with this product.

I am a full time guitar teacher. I often use BIAB in my lessons. Two thing make it frustrating for me to use BIAB in my lessons.

1. Starting BIAB takes way to long to load.
2. BIAB takes way to long to build real track styles. Uncompromising the .wma files in Real Track and Real Drums then compiling the song takes a lot CPU power. I admit my computers are not the fastest out there. But they are 64 bit and have solid state hard drives. I know 64 bit would speed everything up.

The problem for me is I only have 30 minute lessons. I can't spend 3 to 6 minutes of the lesson waiting for BIAB. I often just go to YouTube and find a nice play a long someone has made which is a bit frustrating to me since YouTube is free and I have paid hundreds of dollars for BIAB.
If PGMusic could reduce load up time and track generation by a minute or so it would be usable for me in my lessons. Some styles load a lot faster then others. I'm learning which one I have to avoid in lessons and only if I have BIAB already running in the background.

As far as I am concerned, BIAB is not a real time tool. I know there are features in there targeted at real time usage, but it is just too cumbersome to use that way IMHO. I have rendered hundreds of songs for play-along. Many of them I have also mixed and mastered in a DAW. For me, BIAB is, at best, a tool to help in one piece of the process. I would like to see it do a better job of that piece (faster operation, avoidance of the maj/min errors and others mentioned above, much better user interface) and also cover a broader swath (support all popular VSTis and VSTs, allow more than 4 effects. etc).

I am simply not interested in 100 more real tracks if the underlying shortcomings are not improved.

MJames,

When you say...


...What are you start-up times?

I just started BIAB and it took 4.5 seconds. Also, I generated a 76 bar song that contained four realtracks and it started playing the first bar (after the count-in) in under 10 seconds. I have BIAB 2016.

EDIT: I don't have solid state drives but the \bb folder is excluded from being checked by my antivirus software.

Regards,
Noel

• my latest song : Tomorrow I'll Be Fine

I have noticed this on my laptop, but not my PC so much, and I can't figure it out.

On my PC, from click to run with a Real Style loaded it is about 28 seconds, which I won't mind, since Sonar takes about that long to load. Seems kinda normal.

On my laptop, though, with the same 64 bit operating system and plenty of RAM, it does take several minutes, and I have no idea why.

So I can see why if you are a teacher and using a laptop it would be frustrating. I am interested in the answer to this.

David -



Have you excluded BIAB from your anti-virus scan? Of course, that's a tradeoff in that you must trust the BIAB executable file; however, it definitely does reduce startup times significantly. Also, what kind of hard drive do you have in your laptop. If SSD, I would think it should load pretty fast (unless it's loading from another drive). I've got 7200 RPM drives in my laptop, but many laptops (even new ones with a lot of RAM and processor horsepower) have 4200 or 5400 RPM drives, which will definitely affect performance (the slower drives improve battery life).

Who needs 64bit in this day n age ? a bunch of crazies !

That definitely DOS show what BIAB can do!

David,

That's strange behaviour. I've never had any version of BIAB from 2006 until now take longer than about 30 - 40 seconds (on both laptop and desktop). The longer start-up times where when Realtracks technology was in its earlier days.

Thanks man! I will check that out!

Both my laptops are really slow to start up and generate the tracks. I also have Dell mini form factor that is a little faster but still to slow. My home pc is a high end gaming pc that is fast. But it's monster pc with 16gig of RAM 6 core cpu, nVidia GPU ect...
The fact that we are having a debate over 32 bit vs 64 in this day and age is just stupid. Even if there were no improvements at all, BIAB should still have a 64 bit option so that it can take advantage of memory, cpu and OS compatibility and improvements and any number of other improvements and features that may arise in the future.

IK Multimedia just went to 64-bit this past year with SampleTank 3, so that's pretty recent. Finale just went to 64-bit in the past couple of months. It seems to me that a lot of companies have been wrestling with this "in this day and age", so plenty of stupid to go around, eh?

Buy it or don't, but whether it's 32-bit or 64-bit (and trust me, I'm on the bandwagon to get 64-bit), there's not another program that does what it does.

I had fear and worry when the windows version came out and I fought hard to stop this happening.....



but then I realized the fear was unfounded because my DOS v4 still worked !

Your sarcasm his really funny! And makes a good point.

Hi all,

This thread is locked, but is continued here....
http://www.pgmusic.com/forums/ubbthreads.php?ubb=showflat&Number=378781#Post378781

This thread was started in 2014, before we had support for jbridge ($10). So it contains dated information, before BiaB worked seemelessly with 64 bit plugins. Customers were confused reading this thread, because they were reading information from 2014.

Feel free to continue the discussion in the continued thread above, posting current information.