PG Music Home Forums PG Music Product Forums Band-in-a-Box for Windows programming language upgrade delphi to c++ [CONFIRMED]

I was looking @ the programming language of band in a box & real band they use delphi if they changed to c++ would get less errors and run smoother. They seems very outdated - looking on google most audio applications use c++ with better gui's and less bugs. There are programs that will convert 80% of delphi to c++. They could keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years and make a new modern version that can be used like band in a box but in an audio workstation like real band in a new c++ 64 application. They seemed to be able to port it to the Macintosh ok so I do think they would be able to accomplish this sometime soon hopefully.

Hi Pipeline

I didn't understand why the video link to a 1997 video on Generating Solos?

You mentioned
Have you used these programs successfully (like 80% successfully)? No, I guess not.

Whatever development environment BiaB is produced in has no relationship to its output functionality. Most modern development systems - whether it is Pascal, Java, C++ or C# etc - are all capable of producing the same results, (well, maybe not Cobol...)

The output from the Delphi Compiler is just as compact and efficient as any C or C++ or C# compiler. Smooth running is a function of the programmer's effort.

BUT... to change from one language to another for a mature program is asking for trouble.

I know I am a programmer that uses Delphi primarily. It has grown up and kept on a technical level on a par with any other language.


Kevin

Interesting topic. But, why would we end users be concerned with how or why the program is developed, programmed and compiled?

He he. I have been doing many things in COBOL but I wouldn't say that COBOL is modern. It is a nice language, quite speedy, quite comfortable to write and read but verbose. StylePicker and its fellow Pickers would probably be faster in COBOL and because of the file system the maximum number in the Style Picker would have never occured. But for the mathematical equations in the nusic files FORTRAN would be much much better.

Because of the resulting size of the program and the speed it runs. The smaller the program the faster it loads. The more compact the code, the speedier the program is.

It is a [*****] to program, but written by very good programmers in Assembler the program would be much smaller and faster. The problem with third, fourth, fifth generation program languages (#GL) is that they are often very comfortable to use for the programmer but also create a lot of bulky overhead within the program. In Assembler you would have to program the GUI, in a 4GL you select the features and the appropriate module is loaded.

But in general: I don't care -- as long as my computer is fast enough and the necessary memory can be accessed.

(In the times when Bill Gates had said: "640 KB of memeory should be more than enough for everybody.2: The smallest program I've written in Assembler has had a size of 9 bytes. It gave back an errorlevel number indicating which key was pressed to control DOS batch programs. This program would have never been so small using another language except machine code.)

C# has to be the most appropriate for a music program ?

Sorry, couldn't resist. Merry Xmas everyone.

Mike.

Exactly! With today's fast computers and oodles of memory I have zero concern about what programming language PG might choose to use! No one would ever program a Windows application in assembler. Delphi, C++, who cares? Just get that GUI fixed! Better yet, get the whole thing converted to a VSTi that I can use in my DAW!

Well, I would say you have it backwards. Go onto your DAW's forum and ask them why can't they be a slave to Biab's host?

My point is DAW's along with Biab have always been master host programs. They're not designed to be slaves.

Bob

Yes, agree 1000%. Big trouble. Huge trouble...

Baloney!:) there is no need to ask a DAW to support my Kontakt instrument library because it is already designed to a standard! if PG designed the RealTracks to be a VSTi it would become something universal that would work with any DAW!

The programming language has nothing to do with it, the Delphi compiler is quite efficient, what slows BIAB down is it uses a lot of resources which need to be loaded into memory. You could program it in Assembly language or even machine code for that matter it the increase in speed would be minimal. What it needs is a streamlining of the GUI to be less taxing on the system

""They could keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years and make a new modern version that can be used like band in a box but in an audio workstation like real band in a new c++ 64 application. They seemed to be able to port it to the Macintosh ok so I do think they would be able to accomplish this sometime soon hopefully.""

Sorry was trying to emphasize for a new version but keep the old delphi32 biab for those existing users. The delphi just seems very dated to be still using so I did a list of what others are using for good reasons I would expect. C++ is simply portable to just about any platform and it seems everyone was complaining about the gui problems and syncing to other daw's and vst syncing. Sorry it was just something I had noticed.

more

I'm totally out of my depth here, but I'm curious. I read through the list and saw that all the "Brand X" programs used C/C++ except for Sonar, which uses MFC. What's that?

R.

MFC is an object oriented library it stands for Microsoft Foundation Classes, Delphi uses it's own object oriented library "VLC" which stands for Visual Component Library, it's far more sophisticated than MFC and now delphi is focusing on a vector based library called Firemonkey that is used for cross platform development on Android and IOS.

The problem is not in the language or in the libraries; it's in the code efficiency and baggage. You can easily port Delphi to C++, since they are basically the same language aside from the syntax, but all you'll end up with is the same exact program running with code compiled from C++ instead of Object Pascal. Band In the Box was written back in the DOS days and ported to Windows, but for all intensive purposes it still operates like a DOS program. It reminds me of the earlier versions of AutoCad for Windows before they rewrote it to function like a windows program. One thing that would speed it up is to lose all of the unnecessary bitmaps and 3D bevels on the buttons and controls that not only eat up resources but make it look like a program out of the 1990s

"for all intents and purposes"

The code would need a total rewrite...pretty tall order unless the team is well versed in modern oop programming.

It wouldn't be a total rewrite, unless the GUI code is mixed in with the analytical and music processing code.

Typically all of the GUI code should be in the units which contain the forms that use them and all of the non GUI code such as the music generation should be in separate units.

If everything is in one big main unit and the GUI elements are being accessed from within the procedures which do all of the musical functions then yes it would be quite an undertaking and a nightmare to maintain.

Thank you roslon for that - that's what I'm trying to convey - that's why that old video was posted.
""make a new modern version that can be used like band in a box but in an audio workstation like real band in a new c++ 64 application - and keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years""
Maybe not tomorrow or the next day but sometime soon would be a good thing.

The choice of development environment has little or no bearing on the resultant functionality.

Object Pascal is anything but a dated language. It has always been and is still under very active development. The latest RAD Studio is Seattle, released just a few months ago. It includes cross-platform capabilities, giving Multi-Device application support.

I understand your intentions are good, but porting to a different language won't deliver the results I think you are expecting. And certainly won't deliver anything quickly - far from it.

Could the User Interface do with some work? Well, yes. Like all active products, users expect to see regular enhancements.

Given the program's legacy this would be my guess.

johnjohnjohn " get the whole thing converted to a VSTi that I can use in my DAW!"
that could not be hard to do as realband\data\bbw2.exe generates up the tracks then lays them in real band that is a daw - initializing accompaniment functions is starting bbw2.exe up that appears to be much the same as bb\bbw.exe band in a box.

videotrack "Object Pascal is anything but a dated language"
is delphi the best to be using for this ? I just wonder why the other daw applications are using c++ and not delphi - is it the personal choice of the person programming since the 90's or is there a reason why c++ could not work for them ? is delphi easier than c++ ? there is a big forum somewhere on band in a box 64 where people are wanting a new interface rather than the dated one would delphi do this ok ? if so why is it not there yet as requested by many but the interface on the ones listed above using c++ are very modern.

Pieline,
I think I see where you are coming from, but I really believe you don't quite grasp the programming side of things. I'm guessing that because you saw DAW's whose interfaces you liked better and noticed that they were written in C++, that the best/only way to write a good DAW is to use C++.

C++ doesn't produce better graphics or better programs than Object Pascal (Delphi). They're both high-level languages. Down in the nuts and bolts, they all utilize Graphics Objects, I/O routines, Metafiles and more that are exposed by the Windows Operating System.

Here's an analogy:
An author wants to write a best seller. He can use a PC or a MAC to write it.
Will the book be a better seller because he used a MAC? Of course not. It will only be as good as the author's writing style and creativity, not the editor he produced it with.

Hope this explains it more clearly.

I'm still unclear as to the reasons why they use c++ and not delphi ? - if you could give some examples of daw's that are using delphi with good interfaces and operation so I could compare and get an idea of what it is capable of it might help me to understand more than what I do. I don't think it is just about interfaces as said before there are many other problems. I'm just at a lost as to why they use C++ and not delphi.

What is your professional background?

Do you develop software, if yes on which level
- Design
- Code
- Test?

Do you know any programming language at a working level?
Better: Do you know more than two programming languages at a professional working level?

I believe that FL Studio is written in Delphi. It certainly used to be.

Regards.
Mike.

This is a brilliant idea! RTs could become as universal as MIDI and I would expect that PGMusic's sales would skyrocket!

Actually if they could produce a VSTi RT player where one would input the chords and it would generate RTs they could sell it as a separate product.

GHinCH "What is your professional background?"

Sanitation Engineer
1.Industrial Level
2.Home Level
3.Street Level

Attack the new guy or welcome the new guy as there might be some truth that hurts a bit to hear ? that's why I said

""They could keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years and make a new modern version that can be used like band in a box but in an audio workstation like real band in a new c++ 64 application""

Mike R "I believe that FL Studio is written in Delphi. It certainly used to be."
It is strange what it is written in.

In my opinion PG has one HUGE challenge and one HUGE opportunity!

The challenge is converting decades old code to something with a modern GUI abnd 64 bit. It will almost certainly require a major rewrite in logic, code, GUI, etc. Even if they accomplish this they only end up with version X of BIAB.

The opportunity is to build a VSTi version of BIAB! This would also require a large effort but they could leave out a ton a legacy features and functionality that would not be needed in a VSTi. If I could add BIAB RealTracks to individual tracks in my DAW...man oh man that would be heaven! In the pop up VSTi window there would be the ability to select a RealTrack instrument and enter chords in bars and generate/regenerate on command. Maybe the BIAB track(s) could even display chords in my DAW to serve as the "guide" track for the whole song!

This would be so cool and would instantly open up an enormous new market for PG! And they could continue selling the regular BIAB for those who love the classic interface!

[img]https://en.wikipedia.org/wiki/FL_Studio[/img]

Still shows delphi. What is the detector you are using to determine the code base, it might just be detecting a wrapper rather than the native code perhaps ?

FL may have changed to C++ but it certainly used to be coded in delphi for many years and has a neat and fast interface although non standard windows look and feel.

"The opportunity is to build a VSTi version of BIAB! This would also require a large effort but they could leave out a ton a legacy features and functionality that would not be needed in a VSTi. If I could add BIAB RealTracks to individual tracks in my DAW...man oh man that would be heaven! In the pop up VSTi window there would be the ability to select a RealTrack instrument and enter chords in bars and generate/regenerate on command. Maybe the BIAB track(s) could even display chords in my DAW to serve as the "guide" track for the whole song! "

What you are describing as a VST is how RB works with Biab. PGMusic can save a ton of R&D and money just by you learning RealBand and switching over to using it. Alternately, one can already click DAW Plug-in MODE in BIAB and drag ever how many files or regenerations of tracks that you want to into any DAW? What is the payoff to PGMusic to undertake such a huge effort that is at best, promoting a competitor's DAW over RealBand?

It is not attacking, but to get to know the background of somebody who says you need to drive this car to be better.

Well, first, they don't gain a single new customer by me "learning RealBand and switching over to using it"! Not one new customer there! I already use and love BIAB!

And second, let me blunt, RealBand is not a great DAW! I doubt it could even survive as a stand-alone DAW product without RealTracks. So again, very few new customers available to PG that are interested in giving up their modern 64-bit DAW for RealBand!

Third, the DAW plug-in mode you describe sounds interesting but there are so many inconsistencies and warts in BIAB that I would never bother when I can just as easily render my tracks to then use in my DAW. And again, no new customers for this feature!

So that leaves us with a new VSTi version of RealTracks. This would directly compete with huge sellers like Native and everyone else selling VSTi products. It would work in every DAW. Convincing someone to buy a new VSTi is certainly not a big task while convincing them to drop their DAW for an old one that supports RealTracks...well that is never gonna happen!

So there you have it. An almost unlimited supply of new customers who would buy a RealTracks VSTi for their DAW vs. just continuing to sell the DOS/Win3/Win95 patched up product to us old-timers (until we stop buying it of course!)

Mike R you could be right that's maybe why they can't port to Mac only a crossover wrapped version as c++ should be portable to any platform.

Thank you johnjohnjohn +111111 I will now hand you the wheel.

And also let me blunt, I considered going ahead in my initial comment to address the "RealBand is not a great DAW!" arguement. To be blunt again, I saw that one coming a mile away! Name a single mainstream DAW that has not undergone upgrades, rewrites and enhancements. Protools is up to version 12. Reaper did not use to be a very stable and good DAW. Sonar is ramped up Music Creator. There are folks out there making music as good as most anybody with Audacity. All of those programs are better today than they were in earlier years. Realband is getting better too.
I've had Music Creator, Cool Edit, Studio One Professional, Protools 6, 7., Cubase and there have been stability or compatibility issues with each and every one of them at some point.

I didn't advance answer the RB not a great DAW for three reasons. 1. I saw it coming and decided to wait until now. 2. The post is about a VSTi version of BIAB. BIAB is not a DAW. Realband is only relevant because as poorly as you think it performs, it integrates superbly with Biab in the manner you want it to work with other DAW's as a VSTi. and is there for you to use. 3. Terms such as universal, plug & play and works with every DAW seem to be more marketing tools than absolutes. Think of the time setting everything up, drivers, asio, MME, latency, crashes, porting, firewire vs USB, USB2 vs USB3, dongles, activations, passwords and user accounts. Heaven is always just a sin away. The imagination much brighter than the reality. And the reality is that for many, the VSTi version may not be any more stable than RealBand is now.

cause you know it is true?


not fast enough for me and the thousand of others who use more modern DAWs!


Is that any reason not to dream and aim high?


Well that would be a real concern if I were PG. I have used dozens of plugins in several DAWs and for the most part they work quite well. The market would certainly not accept a RealTracks VSTi that is not stable.

My main point in suggesting a VSTi is to build on what PG has done best! Namely, RealTracks and the way they create them, time-stretch them, transpose them, integrate them into my chord progressions, etc. That is nothing short of BRILLIANT! It is far more brilliant than any DAW on the market that I have seen. It is far more brilliant than any VSTi I have used so far!

In their RealTracks, PG has something truly amazing that would set the music world on fire when compared to sample libraries where I still have to play the parts entirely! But they need a way to get this brilliance into the hands of people making music and I honestly believe yearly patches to the current GUI will never do that! On the other hand, a new VSTi version of RealTracks would be the product of the year or maybe the decade!

I couldn't agree more.

RealTracks ARE awesome! But comparing them to a VSTi program is not a fair comparison. By definition VSTi is a sound generator and can only sound as good as the midi commands let it sound. RealTracks are a collection of audio phrases. The genius is not just the sound but the arrangement the musician follows, the recording and mixing engineers dedication to creating the right sounds AND the (BiaB) program's audio engine capability to compile the phrases into something that is both pleasing and coherent. To me that is truely magical.

Would a laser focused VSTi with the capability described above be great? You betcha'. Would it be the equal of megabucks VSTis like Kontakt? Perhaps but it would be a huge gamble for a small music company like PG Music. But, I don't think the VSTi program would be compared to another VSTi. I think it would be compared against audio loops and against loops RealTracks and a VSTi does not fare as well because loops and RealTracks both rely on audio phrases.

Compare RealTracks and BiaB against VSTi and PG Music "wins" because it is an apple versus oranges comparison. Compare RealTracks and BiaB against loops and you have a much more level match up. PG Music doesn't "win" but it doesn't lose either. They just get to compete against every other company that makes Acidized and Rex loops.

So we are all settled on a vsti version and a 64 bit c++ audio workstation version I will mark that as confirmed. The existing delphi32 version as stated will still be available for the older users and the 64 bit c++ audio workstation will also be ported to Macintosh.

Nothing wrong with ambition.

Some good points but not sure what your overall position is!

In my growing collection of virtual gear I have some plugs that feature totally synthesized sounds and I have some that are digitized samples. Some of the synthesized sounds have no real-world equivalent while others are intended to model and synthesize a real instrument.

What they all have in common is they can be "played" using a MIDI controller or by inputting the notes on some version of piano roll software.

Some of these plugs are very simple with only a note-for-note match between the MIDI controller and the samples being played. But others have quite extensive functionality such as loops or strum patterns, or drumming patterns, etc.

I understand that BIAB/RealTracks are not created, stored and manipulated note-by-note, rather, they are complete musical phrases a bar or more in length. So clearly there would be some difference between playing notes on a MIDI controller and having the plug select the proper samples from the library.

But given all of that I see no reason why it would not be possible to implement RealTracks generation via a VSTi interface that would work inside any DAW!

And yes, there would be technical issues to work out and also possible issues with assumptions of users who are familiar with how samples work and unfamiliar with the RealTrack phrase approach.

So, I acknowledge it will be a fairly steep learning curve if the PG team has not programmed VSTi before but I cannot imagine the curve to be any steeper than a complete rewrite in a modern framework! And of course there will still be GUI elements required but all of the stuff the DAW already does can be left out.

At the end of the day, if PG could create a RealTracks plug that follows the standards and works in any DAW it would be a KILLER product!

I agree a VSTi that can use RealTracks to create an audio file within a DAW environment is a wonderful idea. I support the thought.

But I don't think PG Music has any desire to create a VSTi.

That's one of the great things about PG Music, one never knows in advance what they will do. I never would have guessed a Band-in-a-Box foot pedal or partnering with Roland and Microsoft on Songsmith. PG Music follows their own path.

Roland helped with Songsmith? I didn't know that, where'd ya hear it?

It truly is surprising how much PGMusic gets done every year.

It was on the Songsmith website. Roland provided different instrument samples from those used in Microsoft software. Songsmith also had a modeled based versus sample based instrument set for a short time years ago.

The project seems to be pretty stagnet but every now and then you can visit the website and scroll through the pages and find something new. I don't think there have been any changes to the program itself since 2012 but the forum area still has some activity.

VSTi youpee; we're waiting for that train quite a while now ... !!

the mac guys are complaining about not having the same features as the win version and having to wait 6 months more

cross platform development in c++ might be a way to get both apps released at the same time with the same features
https://www.google.com/?gws_rd=ssl#q=cross+platform+development+in+c%2B%2B

I say let the Mac users "eat cake"

LOL!

Isn't one of the main reasons behind the differences between Mac and Windows BIAB versions due to the fact that Apple changed their OS significantly a few years back without consideration for those programs that were designed for the previous system? I'm not sure about this but I seem to recall a discussion a year or two ago.

Regards,
Noel

I understand that BiaB current version and RealBand can run on Mac computer hardware, just need Parallels or Boot Camp etc and run it on a Mac under Windows O/S

Trouble is, many Mac users refuse to do that. That's really their decision. There is a choice.

I would say that all the other cross platform audio applications are released at the same time but I could be wrong you would have to have a look and let me know. When you fix a problem with one version you would also be fixing the problem for the other version. Just trying to lift the awareness up.

this is some information on the Macintosh version

I have not coded for a long time, did it at UNI, then some years in program design. Old school as a programmer, modular 2, Pascal.

As you guys know, I support a total rewrite and a VST. I believe that a new product will come with time (perhaps a loooong time) .

In regards to programming language I don't really know OOP, but I would have thought that major considerations would be what code was available off the library shelf, if there were good interfaces to work in, whether their was sympathetic development tools, enabling stuff like dockeable drag and drop widows, good sound, low latency.
Programming from scratch is always possible but it can be expensive and their are better ways to use time.

Big plus for VSTS

Z

I recently retired as a software developer after 30 years in the trenches. I've written everything from Assembly to C#.
I worked freelance for the last 15years. I don't know how many tons (all code is measured by the metric ton) of code I have written.

A good friend (and decent enough programmer) once told me that
Programming is easy, good Ideas are difficult.

Inexperience sometimes makes people believe a particular tool or technology will instantly solve a problem. Experience shows us mostly this is not true. It is people who take the tools and make the product what it is.

In the hands of Stradivari a chisel is a formidable tool. In my hands it is but a pry bar.

The boys and girls at PG Music have put together a first class piece of code for over a decade now. This is MUCH longer than most programs survive.

Hats off to them.

They never could have done it in JAVA!!!

All excellent points mrgeeze. Actually, BiaB just celebrated its 25th anniversary. An eternity in software applications.

Joel Spolsky is a New York software developer with some excellent ideas. I've long been an admirer of his work.

I remember he wrote this article - a long time ago now, but I kept a link to it because it's great advice and this advice is still current. The article discusses rewriting code from scratch. The line that caught my attention was: "It’s harder to read code than to write it." How true.

If PGM ever decided to port to a different development platform, don't expect the next release for a long time. A very long time. And what would be delivered after that extraordinary wait? Exactly what we have now, except with a whole new set of bugs thrown in that need to be painfully sorted out.

Joel also makes other excellent points:

"When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years."

I expect Peter and his team are aware of this too.

While I'm sure the intentions are all good, the O/P should definitely read Mr Spolky's article. I have no intention of being confrontational, but the line: "if they changed to c++ would get less errors and run smoother" is just utter nonsense.

Trevor

Excellent article, Trevor.

That's a cool series of essays and it brings back memories -- yes reading code is hard and developers knowing what they have written don't devote time to comment what the code means. Later they take weeks to analyze what they presumably have thought writing this mess within an hour.

It's a good read for everybody who has master solutions to better software.

I have followed Joel for years as well and I totally agree a complete rewrite of software as complex as BIAB would be an enormous undertaking. But there comes a time with every piece of software where you must bite the bullet and do it! Lots of folks here are always wishing for true 64-bit and except for a few die-hard EGA/DOS/WIN95-fans, everyone agrees the GUI is overdue for real modernization. Those kinds of changes done right will likely necessitate a pretty serious rewrite.

But I will come back to my VSTi mantra! If I were PG I'd plan to keep patching up BIAB indefinitely but on a parallel track I would hire a crack team of modern software architects & engineers to connect the brilliant RealTracks engine into a modern VSTi interface. Now that is a Killer Product!

"They could keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years and make a new modern version that can be used like band in a box but in an audio workstation like real band in a new c++ 64 application."

Hey guys don't miss the point i'm trying to make - the writing is on the wall - have a bit of insight. You don't want to hold things back.
Can you really see band in a box being still having only 32 bit in 2020 2030.. ?
I always see things long before they happen but they still always happen.
Lift up your consciousness, come up with some transcending ides - new concepts.

This is a good place to bring these to fruition.
Don't just sit back and wait n hope pg comes up with some good thing at the end of the year like chickens waiting to be fed, make it happen !

Don't hold back and knock things - get into it. You guys have got to aim a bit higher. With all the vast programming knowledge you guys have it should be possible - not impossible.

If another company decide now to do the same thing, how quick do you think it would take pg to change things ?

LISTEN to johnjohnjohn - get that "VSTi interface" happening NOW !

I found this http://sourceforge.net/projects/delphiasiovst/ so you delphi programmers might be able to incorporate the bbw.exe into a vst as is done something like in realband that calls on c:\realband\data\bbw2.exe (initializing accompaniment)

you could set up a main instance of the plugin on track 1. and set it to track 1. in the vst, with track 2. set to track 2. in the vst and so on or allow the next track as a midi track for the midi notation of that real track.

so the plugin will follow the host synchronization n bpm TPOPSTRINGDIALOG


the vst would need to show the chord window TSSWINDOW and other necessary windows that could be in tab form, might be easiest to follow if you have the chord window like real band continuous unfolded - but basically you just need it for generating up the tracks then move to the daw functions for any further editing.

you should be able to select any bars then click the generate track No.X button on the main plugin window to render a new piece if you don't like the section, without having to generate the entire track.

so the generate buttons would need a drop down menu with real track - drums - user track - super midi and so on with recent generation to choose from could be something like the drop down generate in real band.

you would still need the open save as to import and save an sgu

you can set a bar offset in your daw to allow for 2 bar count off and pickup intro notes.


That is just a startup idea any other users with suggestion, improvements and ides for the vst please post! *


There is a cross platform c++ VSTGUI to create for Macintosh also but by the responses you guys weren't too worried about them. http://sourceforge.net/projects/vstgui/?source=recommended


* again please note "They could keep the existing band in a box how it is 32 for the older users that have been accustomed to it's interface for the last 20 years"

Stimulating conversation that I've been following from the beginning. Been reading, but held my fingers in check, but feel the need to write something regarding this subject.

I'm sure that PG is way ahead of you. As development takes time and knowing how 'secret' PG is about upcoming releases, I am not at all surprised to not see any PG staff responding to this interesting thread.

Do any of you seriously believe that Dr. Peter Gannon is still living in the DOS ages? I think not. Bide your time, fellow BIAB'ers.... As has been adequately mentioned, a complete rewrite of what we have today is a HUGE undertaking and will take a lot of time and resources (therefore, money!).

Things will come to fruition in time. And time is what it will take.

Keep on keeping on!

I fail to see the need of having BIAB as a VST.

Can somebody explain me WHY exactly is a great, desirable feature to have?

Pretty please?

You could use BiaB track generating in other DAWs.
Imagine if Reaper could generate BiaB Realtracks .. or Sonar, or ProTools or whatever.

!!!!!:D !!!!!

Do we "need" to have Band-in-a-Box? Is there a "need" to have RealTracks? Is there a "need" to have a tv? Is there a "need" to have ____________ (fill in the blank with whatever you like/want that someone else might not like/want!) It ain't about "need"!

When I am president of the BIAB VSTi fan club, long-time BIAB users who love the interface and functionality will be able to keep it! But for others who want to use the latest, greatest software, GUI, 64-bit, DAW of choice, etc. the new VSTi version will be great for them! (I just realized I may have doomed my idea with that association in this forum!!!)

There is an enormous market for virtual instruments to add in to my DAW and help me create amazing music. I own lots of these libraries such as Kontakt and others. But in most cases the instrument samples are note by note and while that provides great flexibility and control, I also have to play everything on a MIDI controller to get them into my DAW. Some of them include patterns that get close to what RealTracks offers and I like those a lot.

For me, and I suspect lots of others, I have zero interest in many of the things BIAB does. I will never ever use it live and will not even use it to produce complete backing tracks. Mainly that is because I have a DAW that I much prefer to use (and there are LOTS of people out there who have a preferred DAW and will not be changing that!) I am not going to use the built-in metronome or any of the other gadgets.

But those RealTracks! Oh My God...those RealTracks! A pirate's dream. A king's ransom. A maiden's knight in shining armor. Well, the RealTracks are nothing short of amazing! And they blow everything else in the virtual instrument arena out of the water! Hands down. End of story. Slam the door. It it fits it ships!

Having the ability to drop the RealTracks engine into my DAW would be the best thing since sliced bread! And this would indeed be a Killer Product! Can you imagine the excitement among the millions of music producers who could now add RealTracks to their productions directly in their DAW of choice

The only downside is a whole lot of people could start producing music that is as cool as what we BIAB users are producing! Wait...I have changed my mind! Let's cancel the whole VSTi idea before I lose my edge!

I have done a bit more searching and found this http://www.energy-xt.com/index.php?id=0115 works like how I suggested but using rewire.

ReWire VST works as a standard VST instruments and can load all versions of Reason (32-bit and 64-bit) on PC and Mac OS X. Want to use Reason inside energyXT, MPC, Maschine or any other VST DAW/sequencer, then ReWire VST is for you.

The vst can work in a similar way - just needs to use the c:\realband\data\bbw2.exe like real band does to bring the tracks into the daw instead.

any ideas or suggestions will help.

It could very well be due for a total rewrite as I have files in the bb root going all the way back to 07/24/1991 5:47PM 8.3 DOS names

C'mon, let's be pragmatic. There's always room for improvement, but I don't think a single file date of July 24 1991 means the entire system was last written/developed/improved in the 1990's.

Maybe it means that it's fantastic in it's backwards compatibility (!)

It goes without saying that your intentions are all good, no doubt. All things need constant attention & upgrading. But sorry; that's just not a realistic example. I too want to see continual improvement. But let's start with where we are now, not where we were then, yes?

Trev

sorry "files" in the bb root going all the way back to 07/24/1991 5:47PM "8.3" "1995,1996,1997,1998,1999 - - -
where we are now is still using 8.3 - I remember be limited to working in 8.3 file names back in the dos days trying to squeeze all the different company names and areas into 8 characters
I think it would be a good thing not a bad thing
it might be just that old notion fear of change

Sometimes I look at this thread and think is this really the biab windows forum, the subject would seem more at home on a computer programming forum. Of course your view may differ.

I think there has been a vast improvement in the biab GUI over the past few years, it has come along in leaps and bounds, and now is a lot easier to use.

Just look at the 2013 GUI and does anyone want to go back to this?

Who cares what programming language is used.

a long time back somewhere in the forums here I remember watching a video someone made of a whole new band in a box with a totally quantum leap interface that was totally user ajustable - I think that combined with new 64 bit programming would be fantastic.
It's just good to see new ideas and new ways of doing things being suggested - sure most would just rather just sit back and not get involved or come up with any new ways and just hope for some good things at the end of another year.

It's always new ideas that we first imagine that bring about change - let's face it that guy that first imagined that the world was round would have coped a pretty hard time - I think some were even scorned, jailed or executed.

I might be just 5-10 years too soon - I could always come back in 5 n try again when there is a collective shift in consciousness.

Hope this helps.

** again I did suggest to keep the old 32 bit delphi for those long term users from back in 07/24/1991 5:47PM

Hi, sounds cool. I had a look. Was it this one?

My sentiments exactly! Thanks for that post!

just trying out RapidComposer http://www.musicdevelopments.com/rapidcomposer.html it is a standalone and a vsti - the vst RapidComposer_x64.dll (400k) is just used to connect the daw to the RapidComposer_x64.exe (9meg) that starts up when the vst is loaded. BBW.exe is only 8meg so a vst version would be a must to lay tracks down straight in your daw.. though the syncing problem would have to be fixed, like that rewire vst didn't work http://www.energy-xt.com/index.php?id=0115

So even if we had biab as a vst,

1 would we have to load a biab vst for every track?

2 And if so load and edit each instance of the vst (realtracks etc) separately for each track?

If so seems a rather long winded and way about way of doing things, might just be a lot handier just to do everything in biab or rb, and then render to .WAV and import into the DAW.

What I am saying though it might be a nice feature to have could be more trouble than its worth.

Musiclover

Sigh.
No matter how good, it'll never happen

horse - dead - beat - still? (not yet? OK)

Larry

rather than saying no that's way too hard it'll never happen - get your thinking caps on and come up with some ideas how it can be done - if Peter came on here asking you for ideas on how to do it you would be straight in there - we would not say oh no Peter forget it that's way too hard Doc.
The original post was about programming language but you guys said that would never happen as it's way too hard to do, don't rock the boat.
Why not make a list of what is possible and what is not and pin it to the top of the forum, that way anyone coming here with "crazy ideas" will be cut off quick smart and sent on their merry way never to return again - how dare they ! Men on the moon, off to the insane asylum for you mister !.

Come on you Guys, I know you have it in you, I'm sure each one can come come up with an idea, don't be embarrassed it won't sound silly, come on do it for ol' pipeline

I have owned RapidComposer for over a year and it is a very impressive tool! In a lot of ways it does what BIAB does but strictly with MIDI and VSTis. And in some ways it does a lot more! PG would do well to study some of the features RC provides and bring those into BIAB. Things like huge libraries of riffs...automatic suggestions for chords that might typically follow the last one...huge library of chord progressions as well as a chord progression generator...stand-alone and VST versions...32-bit and 64-bit...and so on! The RC interface seems a bit quirky to me but is still a much more modern one.

Of course, nothing compares to the end result I can get quickly with RealTracks! So I see these two tools, BIAB and RC, as two important tools in my songwriting toolbox! I would now never be without either one!

It may be that some of us think of BIAB rather one-dimensionally. If you think of it as a performance tool, a chord detector, a training aid and all of the other myriad of features new and old that occupy (litter?) the complex menu and toolbar, then I'd have to agree with you that this should never be converted to a VSTi!

BUT, if you view BIAB, as I do, as simply a shell I have to struggle with to get to those SWEET RealTracks, then having a RealTracks VSTi would be a godsend! I would venture to guess the vast majority of modern music producers work inside their DAW and prefer NOT to have to leave it to use external software on their tracks! Imagine what a pain it would be if your favorite VSTs/VSTis required you to output your tracks, process them inside their own proprietary software, then export and bring them back into your DAW!! There is a very BIG reason for the whole plugin concept...we want to work in a unified environment to the greatest degree possible!

So, imagine a new product from PG called RealTracks VSTi where you mainly get two things...a huge RealTracks library and an engine to manage them (select, stretch, tempo adjust, etc.)! This new product would leave out maybe 75% of the BIAB "features" like a metronome or jukebox and leave out most/all of the MIDI-specific features!

My feeling is such a product would be a killer, best-of-NAMM type deal! Every music producer and every wannabe music producer would be the target market for such a product! I am even a little nervous that PG might actually do this some day and let the rest of the music world know what a great thing we have here!