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.
I didn't understand why the video link to a 1997 video on Generating Solos?
You mentioned
Quote:
There are programs that will convert 80% of delphi to c++.
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...)
BIAB & RB2025 Win.(Audiophile), Sonar Platinum, Cakewalk by Bandlab, Izotope Prod.Bundle, Roland RD-1000, Synthogy Ivory, Kontakt, Focusrite 18i20, KetronSD2, NS40M Monitors, Pioneer Active Monitors, AKG K271 Studio H'phones
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.
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...)
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.
Interesting topic. But, why would we end users be concerned with how or why the program is developed, programmed and compiled?
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.)
Interesting topic. But, why would we end users be concerned with how or why the program is developed, programmed and compiled?
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
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.
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.
"My primary musical instrument is the personal computer."
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
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.
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
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.
Band-in-a-Box® 2025 pour Windows est disponible en Français.
Le téléchargement se fait à partir du site PG Music
Pour ceux qui auraient déjà acheté la version 2025 de Band-in-a-Box (et qui donc ont une version anglaise), il est possible de "franciser" cette version avec les patchs suivants:
Band-in-a-Box 2025 für Windows Deutsch ist verfügbar!
Die deutsche Version Band-in-a-Box® 2025 für Windows ist ab sofort verfügbar!
Alle die bereits die englische Version von Band-in-a-Box und RealBand 2024 installiert haben, finden hier die Installationsdateien für das Sprachenupdate:
Update Your Band-in-a-Box® 2025 to Build 1128 for Windows Today!
Already using Band-in-a-Box 2025 for Windows®? Download Build 1128 now from our Support Page to enjoy the latest enhancements and improvements from our team.
Already using RealBand® 2025 for Windows®? Download Build 5 now from our Support Page to ensure you have the latest enhancements and improvements from our team.
PowerTracks Pro Audio 2025 is here! This new version introduces many features, including VST3 support, the ability to load or import a .FLAC file, a reset option for track height in the Tracks window, a taller Timeline on the Notation window toolbar, new freeze buttons in the Tracks window, three toolbar modes (two rows, single row, and none), the improved Select Patch dialog with text-based search and numeric patch display, a new button in the DirectX/VST window to copy an effects group, and more!
First-time packages start at only $49. Already a PowerTracks Pro Audio user? Upgrade for as little as $29!
Video: Summary of the New Band-in-a-Box® App for iOS®
Join Tobin as he takes you on a tour of the new Band-in-a-Box® app for iOS®! Designed for musicians, singer-songwriters, and educators, this powerful tool lets you create, play, and transfer songs effortlessly on your iPhone® or iPad®—anytime, anywhere.
One of our representatives will be happy to help you over the phone. Our hours of operation are from
6:00AM to 6:00PM PST (GMT -8) Monday thru Friday, and 8:00AM to 4:00PM PST Saturday. We are closed Sunday. You can also send us your questions via email.
One of our representatives will be happy to help you on our Live Chat or by email. Our hours of operation are from
6:00AM to 6:00PM PST (GMT -8) Monday thru Friday; 8:00AM to 4:00PM PST (GMT -8) Saturday; Closed Sunday.
Dansk
Deutsch - Windows
Español
Français - Windows
Italiano - Windows
Nederlands
Polski
Português
Svenskt
русский
Japanese
Simplified Chinese
Traditional Chinese
Korean