PG Music Home Forums PG Music Product Forums RealBand Glitch and erroneous chord change occurring between bar 240 and bar 241 [Resolved]

After posting an idea to fix the dreaded "255 bar limit" in the BiaB forum, jazzmammal (Bob) informed me that this limit does not exist in Real Band. And when I also discovered that RB also can open .XML files and generate arrangements like BiaB does, I decided to try it with a 9-minute song I wrote in January 2013 that consists of 325 bars. In the process, I discovered a weird glitch that keeps occurring between bar 240 and 241. But before I elaborate on this glitch, I'll explain the process I went through before I discovered it.

The first problem I encountered after I opened my .XML file is that RB truncated the song at around bar 220. So, I tried to resolve this by copying and pasting about 100 bars of chords from a previous section in my song into the section that got truncated and then manually entered the rest of the chords at the end of the song. While this did indeed result in the complete restoration of all the chords and bars in my song, I wanted to understand why RB had truncated my song in the first place and went back to MuseScore (the music notation software I use to create my lead sheets and .XML files) to study what was occurring around bar 220. The only thing I could find that I suspected as the culprit was the word "INTERLUDE" that I had entered at that location. However, I had also entered the word "INTERLUDE" at bar 105 because the interlude in this song occurs between the first and second verse and between the second and third verse. To be safe, I deleted both occurrences of this word and created a new .XML file that I then opened in RB. Sure enough, RB did not truncate the song at bar 220 like it had done before.

Then I switched to the Tracks window and clicked on the Generate button so that RB would generate a full arrangement of my song using the style I had selected. Because I had previously clicked on the "start from beginning" button in the Chords window, the first 50 bars were visible in the Tracks window as the arrangement was being generated. But before RB started to generate the drums track (the last track to generate), the Tracks window shifted to show a later set of 50 bars that has bar 240 at the midpoint of the window. So, I clicked the Play button and listened to the arrangement from that point onward. Sure enough, a weird glitch and chord change that I had heard previously (before I had removed the INTERLUDE words from within MuseScore and after I had tried the copy/past operation to correct RB's truncation of my song) was present again at the 240-241 bar transition. But when I switched to the Chords window to check the chords at this location, I saw that a chord change doesn't occur until bar 244 (an Am chord) with the most recent chord change occurring at bar 238 (a Dm chord). To make sure that a chord change was indeed occurring at the 240-241 transition, I muted every instrument except for one of the acoustic guitars and played the section again. Then I switched to the other acoustic guitar and did the same thing. Both times I could hear a chord change occurring where there wasn't supposed to be one at bars 240-241.

My next idea was to insert a Dm chord into bar 241 so that a chord change wouldn't occur in the arrangement when RB generated it. But instead of just regenerating a few bars on both sides of this transition for each instrument, I had RB re-generate the entire song from scratch. While this did prevent the chord change from occurring, RB still tried to briefly make this change and ended up creating a weird glitch at the transition between these two bars. I don't know what is going on at this location in the song, but this shouldn't be happening. Does anyone know what it could be? The next thing I'm going to do is insert a Dm chord into bar 240 to see if the glitch goes away completely, even though I shouldn't have to do this for either bar 240 or 241. In the meantime, perhaps someone can give me an explanation of what's going on at this location along with some other suggestions to resolve this issue.

I have some more info on this issue and a possible explanation of what's happening. After I entered a Dm chord into bar 240, reset the view to the beginning of the song, and then had RB re-generate the entire song from scratch, RB moved the "Play" start position to the beginning of bar 241 immediately before it began to generate the drum track (as it had done before). But I also noticed that RB was generating every other instrument track in two stages. The first stage was from bar 1 to bar 240, and the second stage was from bar 241 to the end of the song (bar 327). However, RB didn't do this for the drum track (as far as I could tell). So, does this mean that RB can only generate 240 bars at a time of each instrument in an arrangement? If so, why?

Well,
You got me confused.

"the first 50 tracks were visible in the Tracks window as the arrangement was being generated. "
then ..
"the Tracks window shifted to show a later set of 50 tracks that has track 240 at the midpoint of the window."
Your Tracks window shows 50 tracks? RB only has 48.

What was the source file? Did you open a BiaB file?
Wondering if the 255 bar issue somehow is carrying over inside the file format of a BiaB file and causing these issues.
Maybe try making all BB tracks Regular tracks (as mentioned in the other thread) so RB stops trying to behave like BiaB.
Then Save As a SEQ file.
This may make the song start honoring the RB standards (instead of RB trying to honor the BiaB format)
Once saved as SEQ file;
Then highlight the desired tracks from measure 241 forward and regenerate those .. or maybe highlight the desired tracks and regenerate the whole song.

If you opened a BiaB file and never saved it to SEQ format, maybe RB is still dealing with the 255 limit while trying to work with a file in the BiaB format.
Just a thought

If I open a BiaB file in RB I always immediately 'make all BB tracks regular tracks' and save as a SEQ file so RB behaves as expected .

Sorry for using the wrong term. I meant to say "the first 50 bars were visible in the Tracks window . . ."



The source file was a .XML file that I had created in MuseScore.



No because I didn't use a BiaB file. BiaB can't handle more than 255 bars. That's why I'm using RB and opening a .XML file with 325 bars directly into RB.



Um, I'm not sure how to do this because I've never used RB before, but I'll try to figure it out. I also don't know what a "SEQ file" is. Is that just one of the formats that RB can save the file in?



Like I said above, I opened a .XML file, not a BiaB file. All I did after I opened the file is click on Generate and then select "Generate all BB tracks" because there is no option to generate RB tracks. There is only one track visible, and that is the midi track of the melody that was in the .XML file.

rharv, the screen shot in your previous comment does not apply because there is no "make all BB tracks regular tracks" item on that menu under Audio Effects. IOW, there are no BB tracks in the song, only the midi track of the melody. I could save the file as a SEQ file and reopen it, but it still won't have any tracks but the midi track, so doing this may not be of help.

Well, I figured out how to convert BB tracks to RB tracks. This command is actually on the "Edit->Track" submenu rather than on the "Audio Effects" submenu. Anyway, before I did that, I cut out one entire section of the song (Interlude, verse, and chorus) to reduce the number of bars to 223 and then generated the five BB tracks. After doing that, I saved the file as a SEQ file and then reopened it in RB. Then I converted all the BB tracks to RB tracks and replaced all those bars (102 of them) for that entire section that I had deleted before so that I would have my complete song back again in RB format with the entire arrangement (RB copied the audio for each track as well). Then I saved the song again under a different filename. Next, I tried to re-generate all the tracks again as RB tracks, but RB said that "there are no previously generated tracks found to re-generate." So, it looks like the arrangement generation of tracks is strictly a BiaB function that is limited to 255 (or 240) bars, which means that RB does not resolve the 255 bar limit in BiaB without also abandoning its automatic arrangement generation capabilities. That is, unless I'm missing something or didn't do something right.

Maybe check the Bar settings in the Generate section(?)
I haven't tried it using your described workflow .. just trying to help.

Thanks for the suggestion. I'll try that and see if that makes any difference.

That setting just defines the length of the song. I always change that number immediately after I open my .XML file because the Chord window still shows the default 32 bars in yellow, and the number in that box is still at 32 as well. I've tried changing that number before opening my file, but it automatically reverts back to 32 after opening it.

<<< Well, I figured out how to convert BB tracks to RB tracks. >>> and <<< Next, I tried to re-generate all the tracks again as RB tracks, but RB said that "there are no previously generated tracks found to re-generate." >>> plus

You are correct that generation of tracks is a BIAB function within RealBand. The message you saw is telling you there are no BIAB designated tracks to generate which is true since you previously changed the first 8 BIAB designated tracks to regular Tracks.

RealBand does not have that 255 bar limitation other than it will only generate the 8 tracks designated to BIAB. "I opened a .XML file, not a BiaB file." is why I think you did not generate any tracks. You need to select a BIAB Style or BIAB tracks to generate.

As a test, I generated 16 bars of BIAB tracks to a chord progression and loaded _STEPUP.STY. I changed these 16 bars of BIAB generated style to Regular Tracks.

I reset the 8 tracks to BIAB Tracks.

Then I set my song start to end markers 1 - 276 which set my song stop limit at end of bar 276 - according to the from -through selection that is 276.4.119. I added a chord about every 16 bars and regenerated and RealBand rendered the full 276 bars of the track of the BIAB tracks and did nothing to the 5 tracks I'd converted to Regular Tracks. All tracks used were all RealTracks.


I removed the RealTracks and Style and loaded an All Midi Style - 60spop16.sty and repeated the test and it also generated tracks beyond the 255 limit.

In this simple test,RealBand did generate tracks beyond the 255 bar limitation.

Hope this helps you out.

Thanks Charlie, I can't seem to replicate the issue either.
I haven't tinkered much with XML files though, so I don't know if that could be part of the issue.
I suppose if the XML file had some directive happening at measure 240 it could get inherited/interpreted by RB as a stop point, causing the issue.
FWIW I don't see how an issue at measure 240/241 equates to the BiaB 255 measure limit.
Those numbers are quite different, and as shown in my previous image, generating 296 measures was successful here .. thus eliminating the 255 limit.
I suppose I could have done 800 measures, but thought 296 was enough for proof of concept.

Thanks for your reply and test-run efforts. As I mentioned in previous posts, I did select a BiaB Style and was able to generate five BiaB tracks. But (as I also explained further in my previous posts), RB generated each of those BiaB tracks in two consecutive stages. First it generated bars 1-240, and then it generated bars 241 to 327 before it moved on to the next track and repeated this process. It did not do this two-stage process for the drum track, however. Because of the two-stage generation process, a glitch and erroneous chord change occurs in bar 241.

I looked closely at measure 240 in MuseScore but didn't see anything there that could be causing this to happen. I tried to attach a screen shot of this section in MuseScore but couldn't figure out how.


I agree with you, but there does appear to be some correlation between the two even though 240 doesn't equal 255.

If you know what a rest, shot or hold is as known to BIAB/RB any of those will cause a gap in generation as will having the 'two bar ending' checked. Both of those conditions caused gaps in generating the tracks in some of my testing. In the RealTracks Style test, this occurred at bar 16 and again at bar 273 because I had input a hold ( G... ) at bar 16 and RB automatically generated the 2 bar ending after what I designated as the last bar of my song.

You can test your system by replicating my test. Create a new file, be sure there's a BIAB style picked, (this should be done default) and just any a chord every 1-15 bars and set the length of your song somewhere above the 255 bar. If you enter a rest, shot or hold, you must enter another chord after that after a number of bars to cancel the rest, shot or hold command. The test should separate your issue between a system or program setting and your imported file.

I don't know what any of those are because I don't do any production type stuff with BiaB or RB. I only use it to find suitable styles for my songs than to use those styles to generate arrangements, which I then save as .WAV files to use in other programs. Before I try your test, Charlie, I'm going to open a .XML file of another song I wrote that has more than 255 bars to see if the same thing happens with that song. If it does, then I'll try your test. Depending on what happens next, I could always give you a copy of my .XML file for you to open and see if the same thing happens on your computer. But one step at a time.

Charlie, the same thing happened with the .XML file of my second song with more than 255 bars in it. Also, what I said previously about RB generating each track in two consecutive stages is not correct. RB generates the first 240 bars of each track (except for the drums) first and then starts the process all over again with the remaining bars for the first track and does the same with the remaining tracks before it finishes by generating the entire drum track.

Before I try your test, I'd like you to regenerate all of your tracks if you still have your test file in RB or on disk. But this time, I'd like you to watch the text info in the white bar at the top of the RB window. That text info will start by saying "Generating RealTracks Instructions." Then it will start to generate the first 240 bars of each track for each instrument that is included in the BiaB style except for the drums. This means that if you have four instruments (bass, piano. electric guitar, and acoustic guitar), RB will generate the first 240 bars four times (once for each instrument) before it starts over by saying "Generating RealTracks Instructions" again prior to generating the remaining bars for each instrument. When it is done generating the entire track for each instrument, then the Tracks window will shift all the tracks to the left so that bars 240 and 241 are visible with a dark line (the play tarting point) on the boundary between these two bars. This happens at the same time that the dialog box for generating the drum track appears.

At this point I wouldn't worry about doing my test. The results you've gotten, Rharv's testing and mine indicate to me there's no problem with a 255 bar limit. Importing XML files is a fairly new feature with BIAB and RB and I have no experience or knowledge working with them, within or outside of BIAB/RB.

I think there's a command from the XML file that is either being misinterpreted by RB or something along those lines. There are several here on the forum that are familiar with XML files that can help you sort that out and you can clear up this issue with little trouble and begin to enjoy your music.

Charlie, I have to disagree with you about the XML file being the problem, and here's why. I created my own test by entering some basic chords into bars 1-41 (see my image below) and then copied those chords repeatedly until I reached the end of the song, which I had previously defined to contain 320 bars. Then I switched to the Tracks view and tried to load the _SETUP.STY file that you had mentioned in a previous post but couldn't find that file in my Styles folder. So, I just used the one that I had used previously, which was a modified version of _MELWALZ.STY that I had created by substituting a couple of the instruments. When i generated the BiaB tracks this time, RB did the same two-stage generation process as before except that all four of the BiaB instrument tracks (excluding the drums) faded out to silence at bar 182 and then started again at bar 241 to the end of the song. Because there was no sound at bar 240, I couldn't start playing the song a few bars before bar 241 to listen for a chord change and the glitch that occurred other times. (see my image below)

Why did the sound fade at bar 182? The reason I think this happened is that the style I had chosen had a default time signature of 3/4, but the song I had created had a time signature of 4/4. What this means is that RB ran out of beats with its arrangement by the time it got to bar 182, as in these equations: 182 x 4 = 728 and 728 / 3 = 242.6666 IOW, 242.6666 (less the .6666) is the exact same number of bars that RB generated tracks for in my other two songs because I had two lead in bars in addition to the 240 bars where the track generation ended and started again.

My next thought is that perhaps I need to try this again using a different style that I didn't modify and that had the same default time signature as my test song. So, that's what I did. This time, RB did the same two-stage generation process for each track as before. However, because my test song had a chord entered at bar 241, I didn't notice a glitch when I listened to that section of the song. Of course, I did notice the chord change, which I should have.

Then I decided to open one of my .XML files again so that I could test RB's track generation process using a style that I hadn't modified but that had the same time signature as my song (3/4) so that I could eliminate the style itself as the source of this problem. Unfortunately, because my song didn't have a chord at bar 241, an erroneous chord change occurred there as had occurred at other times. But to make sure that this erroneous chord change was not caused by something in the .XML file, I decided to do one more test.

My final test involved my second test file that I had created from scratch by entering chords manually and replicating those chords to the end of the song. This test file had a chord entered at bar 241. After I opened it from my hard disk, I moved the chord at bar 241 to bar 238 and left bar 241 blank. However, when I re-generated all the tracks, RB changed the chord at bar 241 anyway, as it had done every other time I did this procedure. This means that the problem is with RB's track generation process using the BiaB engine.

I opened RealBand 2019 build 3. It had a RealTracks style left over from my last project. I created a 300 bar chord chart with a mixture of whole chords, rests, shots and holds. I placed "A" and "B" markers at random throughout the chord chart.

When I generated audio tracks it took quite some time but the resulting waveforms looked like I expected.

I then modified the chord chart by changing all rests, shots and holds to whole chords and generated audio tracks. Again it took quite some time but the results did not look like I expected. There is a one bar gap at bar 248 and the bass track has a one bar gap at bar 272.

I was monitoring taskmanager while the RealTracks were generated and formulated a theory of why there are gaps.

My theory is a background task is interfering with RealTrack generation and RealBand is not correctly handling the break in focus.

+++ HERE +++ is a link to the RealBand SEQ file if anyone wants to play with it. Note that the file size is about 450 MB.

Did you listen to either arrangement for several bars before and after the 240 bar mark to determine if there's an erroneous chord change at bar 241? Also, do either one of your test files have a chord at bar 241? If so, this would override any erroneous chord change for bar 241.

You may be correct there's no issue with the XML file. As I said, I have no experience with applying them in BIAB/RB or knowledge of using them in any manner. Also, XML files ability to be imported into PGMusic software is a fairly new feature so I was giving my best guess. Your issue with the two instances of INTERLUDE also led me in this direction. At the same time, I'm fairly confident from the various results obtained, there's no defect with RealBand regarding generations of 240 or 255 bars.


It sounds odd when I say it but I believe the issue is no more than something from somewhere has put a command around bar 240-241 since you consistently have the issue there.


You can easily select a few bars prior to bar 240 carrying the selection beyond 241 perhaps to bar 245 and manually make changes to the chords, replace instruments and only regenerate those few bars to see if completing a smaller size task makes a difference. You can do this to one instrument or to all of them at that section only.


To select a section of all the instruments -

Select the radio Snap To Grid Button in the upper left tool bar area.

Select a track, multiple tracks or all the tracks (to select multiple tracks use the control on any desired additional track or shift key between the first and last track you want to choose.)

Place your curser at bar 238 and Press F7

Place your curser at bar 245 and Press F8

The selected section (all tracks)should be highlighted in blue.

Right Click on the blue selected area or Select the large Generate Button

From the drop down menu - Generate\Regenerate All (selected region) (selected tracks) - The selection reads different in the large radio generate button than from the Right click method but the result should be the same.

Only the selected area should regenerate and apply the changes you made to the chord chart.

Thanks, Charlie, for elaborating on your perspective on XML files. And thanks for your suggestion for me to experiment with the 240/241 bar boundary by making various changes to a small section of bars before and after this boundary and then regenerating those tracks. Unfortunately, I had tried this during one of my previous tests and repeatedly ran into the exact same problem. To substantiate my claim that there is indeed an issue with the 240/241 boundary during RB track generation process, I created a video that documents this entire scenario using a test song that I had created by manually entering the chords into RB's Chord Window. IOW, this test song was not created from opening a .XML file. You can watch this video on my Youtube channel at this link:

https://youtu.be/khIKS_RAGHg

muzikluver,
Maybe try sending this to support via email, or Chat with them tomorrow.
Since you can post the video file, PGMusic may be able to replicate or explain.
https://www.pgmusic.com/support.htm

Thanks for the suggestion. I'll try emailing it to them first along with a link to this discussion.

Thanks for posting the video. You're correct, there's nothing in the chords to cause the chord change and it's clearly there. Rharv's correct that it will likely be best to let support examine the file. I asked someone knowledgeable about XML files and they told me a chord change would be obviously visible and they did not think the XML file had any thing to do with your issue. This test you did seems to confirm that.

I sent them an email several hours ago with links to both discussions about this issue (here and in the BiaB forum) as well as a link to my video. I'll let all of you know when they get back to me and what they say about all of this. Thanks for all the help!

<<< I'll let all of you know when they get back to me and what they say about all of this. >>>

Please do. It's an intriguing problem.

Charlie

Well, this afternoon I received a reply from Joe at PG Music to the email I sent to technical support yesterday. Before I share what Joe wrote to me, I'll share with I wrote in my email:

"Dear Technical Support,

I started using RealBand for the first time a few days ago to find out if it resolves the 255 bar limit in Band in a Box per the suggestion of another user in the Band in a Box forum. In the process, I discovered a problem that occurs repeatedly when RB reaches bar 241 during its track generation process using the BiaB engine. Rather than explain the problem in this email, I'll provide you with a link to the discussion I started in the RB forum on your website as well as a link to a video I created that documents this problem. I'll also provide you with a link to the original discussion I started in the BiaB form that resulted in my decision to try RB in order to create arrangements for two of my songs that exceed the 255 bar limit. Perhaps you could explain why this is happening and if there's anything I can do to work around it. Better yet, perhaps you could fix this problem without much effort. Thanks for your help!

(links included)

Tom"

And here is the reply I received:

"Thank you for contacting us. Although the limit for the song length in Band-in-a-Box is 255, generally speaking the closer you get to that point the more work the Band-in-a-Box engine taxes your computer and thus can create some pretty unwanted results.

As a general rule, the shorter the song the better it is. Even if you need to export smaller portions as a .wav then import them into another DAW to increase the length of it that would be a good work around.

Let us know if you require further assistance.

Cheers,
Joe
PG Music Inc.
Important Reminder: Please include all previous correspondence when replying to this message."

In my opinion, this is a strange reply. I contacted support about a bug in RB's execution of BiaB's engine to overcome the 255 bar limit, and support responded with a discussion on BiaB and a recommendation to use songs that don't get close to the 255 bar limit. Huh?

Thanks for posting the update.

Interesting reply from Joe. It seem that although the RealBand program doesn't have a limit of 255 bars, the BIAB algorithm within the RealBand program becomes unstable when generations near the BIAB physical limit of 255 bars.

An analogy would be a rope designed to be safe under a specific load at 20' will not break when used at that load at the 20' length. The same rope braided to a length of 100' will still be designed to work at that load for 20' and may break when used at the 100' length.


It's a limitation of BIAB although it presents within RealBand.

That's one way to look at it, Charlie, but I think there's more to it than that. On the one hand, RB doesn't even allow the BiaB engine to reach the 255 bar limit. This is why it only generates tracks up to 240 bars and then starts over with an additional 240 bars (or, in the case of my 320-bar song, an additional 80 bars). Although Jim Fogle's post on 6/8/19 above identified two gaps that occurred in his test song (one in all tracks at bar 240 and one in the base track at bar 272), my complaint isn't about the FIRST 240 bars. My complaint is about the SECOND 240 bars. More specifically, my complaint is about the BEGINNING of the second 240 bars, that is, the VERY FIRST bar if it doesn't have a chord assigned to it along with any subsequent bars that don't have a chord assigned to them as well.

In my test song and in a test song that Pipeline did (see his post on 6/9/19 in my BiaB forum topic "An idea to fix the dreaded '255 bar limit'"), RB inserted a C chord in the first unassigned bar, which from these two test cases appears to be a default operation within RB. Thus, on the other hand, RB's implementation of the BiaB engine for any unassigned bars in the BEGINNING of the second 240 bars is faulty because it doesn't account for the last assigned chord at the end of the first 240 bars. Or, as Pipeline put it in his post, "I would say that's a bug they need to look into as it's not stitching it correctly." This is why a glitch will sometimes occur at the 240/241 bar boundary as well as an erroneous chord change.

Regarding Jim Fogle's test, those gaps appeared only after he had changed all the rests, shots, holds in his song to whole chords. The gaps at bar 240 may have been due to a beat calculation error, which may correspond indirectly to the gap that appeared from bar 184 to bar 240 in one of my test songs with a 4/4 time signature when I used a 3/4 style. However, the gap in the base track at bar 272 could have been random and may have disappeared if he had regenerated that entire track or just a small section of that track surrounding bar 272. I say this because I had encountered a similar gap in BiaB on a finger picking acoustic guitar track in one of my songs that did not exceed or even come close to the 255 bar limit. When I regenerated the song, that gap went away.

CORRECTION: Jim Fogle's first gap appeared at bar 248, not bar 240. See my post below.

I just realized after checking Jim Fogle's post again that the gap in all the tracks of his test song was actually at bar 248, not bar 240. So, my theory about a beat calculation error for the first 240 bars is incorrect. So, perhaps this gap reinforces what I said above about RB's implementation of the BiaB engine at the BEGINNING of the second 240 bars.

I also did not point out that Jim Fogle's base track had a gap at bar 244 as well, but he didn't mention this in his post.

Yes

muzikluver, I suspect you now can more appreciate what the term "baggage" means.

I sure can! Obviously, as Bob (jazzmammal) pointed out, "RB isn't perfect," and I never expected it to be perfect. I just didn't know what types of issues I would be running into. This forum contains plenty of posts about such issues. Of course, BiaB has its own issues as well. But it's still a great program, and RB has the appearance of being a great program for its primary intended use as a DAW. I just haven't used it enough yet as a DAW to know that for sure from my own experience and may never know that because of my limited DAW needs.

HI

Just a thought to stop the first chord in a new song coming up as C just set the key sig of the song to the chord you want.
However if you want to start on a note in a key that is not the tonic that is a problem.
But you can always change the first chord yourself anyway.

Starting a new version of song for part 2 to stitch on as a wav, I guess you would need to end part one on a key signature bar before it reaches its critical bar number for you.
At a point that makes musical sense of the arrangement currently generated.
Then create part 2 set to that key sig. the problem then being you may have to regenerate multiple times to come up with same arrangement that the software came up with in part one.
You may well struggle here a bit as what was say bar 220 of a song in part one
In your part two song will be back at bar one and may well get treated as an opening phrase, and therefore not sit well, with where the arrangement would have gone in a continuous generation of more bars.
You will also have to negate the count in at some point .

Seems a rather messy workaround to me and a bit hit and miss

Just my take
Mike

Thanks for your suggestions and for joining the discussion, Mike. I think you misunderstood what I said. RB doesn't change the first chord in a song to C. It inserts a C chord into bar 241 if bar 241 doesn't already have a chord assigned to it. This chord won't be visible in the Chord window, but you'll definitely hear it in the arrangement. The quickest workaround for this is to simply insert a chord (the most recent chord that occurred prior to bar 241) into bar 241 before asking RB to generate all the BiaB tracks. However, even after doing this, a glitch will sometimes occur at the 240/241 bar boundary because of RB's attempt to switch to another chord first---probably the C chord.

I just sent Joe at PG Music support the following reply to his email:

"Hi Joe,

Thanks for your reply to my email and for the comments you made about the behavioral characteristics of the 255 bar limit in Band in a Box. While I do appreciate this information, I have to tell you that the email I sent you was not about problems I was having with this limit in Band in a Box. Instead, my email was about the problems I was having in RealBand because of how it had implemented the Band in a Box algorithm/engine to generate BB tracks for several songs that contained more than 255 bars. This is why I was using RealBand in the first place---as a workaround to the 255 bar limit. But rather than take the time to go into those problems in this email, I strongly encourage you to read through the discussions I started on the "255 bar limit" in your Band in a Box and RealBand Windows product forums. I also shared a video in the discussion on the RealBand forum that shows the main issue I had contacted you about. The links to this video and to both discussions are at the end of my original email below, but I'll provide them again here:

(links included)

Thanks for revisiting this issue.

Tom"

You are persistent, I will give you that, but what about buggy do you not understand? <said with a big smile >

I sure am! And I hope that's a good thing---especially in this case.

Are you asking me about "buggy" or "baggage"? I suspect that you're using both terms interchangeably. As I mentioned above, my primary intended use of RB is to generate arrangements for my songs that exceed the 255 bar limit and to save those arrangements as instrumental demos that I can share with other people. But after Pipeline suggested in a reply to my discussion of this issue on the BiaB forum that I check out the VST plugin for using two instances of BiaB within Tracktion, I'm thinking of pursuing that option instead of RB when I have the time to set it up and try it out, which I haven't done yet. Nevertheless, I'm not done pursuing a resolution of this issue in RB yet and won't until I'm sure that I've "beaten this horse" completely to death.

If you had fun exploring RB, you are going to have a blast with the BIAB VST. I can't wait for all the drama to come.





Not the first time I have heard this expression here in the forum.

Thanks for the "heads up," MusicStudent. I've done plenty of software testing in my life, and I even did some software development in my late 20s and mid 30s, so I'm looking forward to it because I'm no "stranger to danger."


Are you saying that I'm not the only "horse beater" in this forum? That means I'm in good company. Thanks for letting me know!

I'm looking forward to your continued participation. There are a few "horse beaters" in the forum. All appear to have the same goal, to help PG Music identify and fix issues to create a more reliable and stable product.

Thanks, Jim! I appreciate your participation as well and have the same objective with my "horse beating" tactics.

I support your objective and horse beating and squeaky wheels are normally how things eventually get fixed. So good luck. But playing devils advocate, "I have to tell you that the email I sent you was not about problems I was having with this limit in Band in a Box. Instead, my email was about the problems I was having in RealBand because of how it had implemented the Band in a Box algorithm/engine to generate BB tracks for several songs that contained more than 255 bars. This is why I was using RealBand in the first place---as a workaround to the 255 bar limit." and "But after Pipeline suggested in a reply to my discussion of this issue on the BIAB forum that I check out the VST plugin for using two instances of BIAB within Traction, I'm thinking of pursuing that option instead of RB when I have the time to set it up and try it out", I wonder what outcome you're expecting because the 255 bar limit emanates only and always from the BIAB algorithm regardless of the vehicle it's wrapped in. Be it RealBand, BIAB VST, Reaper, Traction or any other DAW.

This is an interesting issue. I've been on a trip which is why i haven't jumped in with some testing and what you're describing is not how I would try to do this. Maybe my thinking won't work either, I'll be home in a few days and try a few things and post what happened.

Bob

Good question, Charlie! I haven't tried the VST plugin option with Tracktion yet but hope to soon when I have enough time to go through all the steps of setting it up and trying it out. For me, this option is definitely "Plan B" if PG Music's support team does nothing to try to improve the way that RB implements the BiaB algorithm, which I certainly hope doesn't happen. But if this does happen, my understanding from when I read Pipeline's post about the use of two instances of BiaB's VST plugin with Tracktion is that it would provide more control over how the BiaB algorithm is implemented because of the ability to split a long song into two sections at a location other than the 240/241 bar boundary by opening two separate .XML files (exported from MuseScore) and also to disable the "Ending" function for the first section and the "Lead in" function for the section. Theoretically, this would result in both sections of the song to be stitched together more seamlessly than they are when RB is used for the entire song. After all, the noticeable existence of an audio "seam" (erroneous chord change and possible glitch) at the 240/241 boundary is why I started this discussion.

To add to what I just said in my previous reply to your question, Charlie, it just occurred to me that RB should be able to use the information in a single XML file of a song with more than 255 bars to automatically do what I intend to try doing with Tracktion using two instances of BiaB's VST plugin and two partial XML files of the same song. In other words, RB should be able to identify the different elements in a song (verse, chorus, bridge, etc.) from the XML file and intelligently split the song into two sections (or more if necessary) at a boundary between these elements so that it can then generate all the tracks for each section and then seamlessly stitch those sections together into one continuous arrangement without any glitches or erroneous chord changes. This is what I would like to see RB do as an effective and convenient workaround to the 255 bar limit in BiaB.

RealBand silently uses a helper file in the background to render RealTracks. The helper file appears to be a modified version of the Band-in-a-Box executable. If that is the case, then the helper file will have the same limitations as the main file.

The plugin also uses a helper file which appears to be another variation of the main file.

That makes sense because BiaB's track generation only takes a few seconds while RB's takes minutes. But the reverse is true when saving BiaB's tracks as a .WAV file versus saving RB's tracks as a .WAV file. In other words, the helper file for RB must be doing more than just generating BiaB tracks or it wouldn't take so long.

Continuing with my thoughts about your expected outcome and that the 255 Bar issue is always related to BIAB algorithm, not only is your issue with the 255 bar limit of BIAB intriguing, but so is your work flow where that limitation interrupted your projects.

I edited and condensed your comments about the bar limit and your project work flow from your comments in the other thread here on the Forum that focused primarily on the bar limit.

I agree totally with Bob (Jazzmammal)regarding RealBand can become an integral part of your workflow regardless of you also using other DAW's as well.

Although a long standing issue, I think too much focus is being placed on the 255 bar limit. Not as a criticism but as a statement after reviewing your work flow, your current workflow does not differentiate well between the accompaniment audio rendering process by BIAB and the resultant audio considered just rendered audio file. This results in unnecessary and undue time spent when and how you're working with the audio after it's been generated by BIAB and that rendered audio is imported into a DAW be it RealBand, Studio One, Pro Tools, Reaper, Traction, Ableton or Audacity. The DAW is irrelevant other than 1) Realband will be the most productive first stage after BIAB generation even if it's moved to another DAW after that. 2)The importance of any DAW is only dependent to how well you understand it and how competent you can manipulate it.

This is the edited and comments as I've completed them:

... how I use BiaB

This is how my writing process plays into the formation of my idea to increase the 255 bar limit.

I create my songs with MuseScore, an open source music notation program and import an .XML file into BIAB rather than input chords manually. This .XML file contains the complete melody, lyrics, and chords to my song.

The very first song I tried to use with BiaB is a 9-minute long ballad I wrote in January 2013. It consists of an intro, three 12-line verses, a 5-line chorus that is repeated three times, a short musical interlude after each chorus, and a 2-line tag at the end. All of these sections combined total 327 bars.

I started listening to a newly-created arrangement in BiaB. All of the bars past the 255 mark were blacked out. I researched to find out why. Then I tried to figure how to create repeats for the verses, chorus, and interlude to get around this limitation but eventually gave up because of the complications I ran into.

In February, I again used BiaB for a 7+ minute acoustic/rock/symphonic ballad that will be the title track for an album I'm working on with a local producer. Being aware of this limitation and the challenges involved in setting up the repeat function (which I'm still not sure would prevent the 255 bar limit from being exceeded), I created a .XML file with only one verse and one chorus before the bridge. I created a .WAV file of the arrangement and imported it into Traction (a program I am familiar with.) and constructed a full-length version of the song then exported it to a .WAV file.

If I just wanted to create a single demo of this song for myself or to share with others, I would be done at this point. This wasn't the case because I intended to share this song with my producer as my next song for him to arrange and produce for me. Plus, this would be my first use of BiaB to create a fully-arranged demo of one of my songs before I shared it with him. I always provide him a video of the lead sheet for him to play the song on his guitar as the melody is being played in the video.

Every song I've given him to produce, he finds things in the song to be tweaked, changed, or rewritten. The "pre-production preparation process" for this particular song lasted 5-6 weeks during which I went back and forth to his studio about ten times with new demo versions of the song that contained necessary and/or desired modifications, some of which I came up with. Each of these versions required the same process I described plus the additional step of importing the .WAV file of the full-length version of BiaB's arrangement of a new .XML file into another program (ActivePresenter) I used to create the video of the new lead sheet of the melody.

This isn't the full story of what it took to create the final full-length demo version of this song for my producer. One week in particular I spent at least 30 hours repeating the above process because I wanted to provide my producer with several different options for him to consider (one with two different tempos, another with and without a key change for the final chorus, and another with and without a capo on the second fret). I also had to start over twice with the entire process for all of these options because I discovered when I was listening to the final demos that I needed another measure in one or two places in order to make sure the down beat of the drum track didn't switch during a subsequent line. If I didn't have to construct a full-length version of BiaB's arrangement for each of these options in Traction because of the "255 bar limit", I doubt I would have spent more than ten to fifteen hours creating these demos that week. Primarily because of what I went through with this particular song motivated and compelled me to post my idea to fix this limitation.

*****

There are numerous BIAB and RealBand recording techniques, some that have been mentioned but not explained or discussed and some not mentioned that may benefit how you can more efficiently and in much less time complete a demo and make edits, changes and corrections to the your demos than what happens presently with your projects. Let us know if you'd like to discuss these other options.

Sure, I'm definitely interested in discussing other workflow options with BiaB and RB that would be more efficient than the one I'm using, as long as they start with the .XML files that I export from MuseScore. I'm always open to learning new techniques and procedures that can improve the efficiency of my demo-creating projects. I should point out, however, that I don't use BiaB or RB to do any recording because I don't have the equipment for that and because my musician skills (guitar playing) are mediocre. So, any alternative workflow options you have in mind would have to be limited to the track generation capabilities of BiaB and RB.

One big difference between Band-in-a-Box and RealBand is how the two programs approach track generation.

Band-in-a-Box generates a few bars of each track then begins audio playback. Band-in-a-Box then continues to play audio while also continuing to generate tracks as a background task. Sometimes the program will stall because audio playback catches up to track generation so there is temporarily nothing to play. If that frequently happensns a user can go to preferences > RealTracks and remove the check mark for, "Speed up generation of RealTracks (disable on slow machines)". When that feature is disabled Band-in-a-Box will completely generate all tracks prior to starting audio playback.

Another way Band-in-a Box works is when the generate button is selected, ALL tracks are generated unless a track is frozen. By-the-way, Band-in-a-Box use to have only a combined play and generate button so every time you clicked play a new arrangement was created.

Finally, when a track is generated all the track is generated.

Now for RealBand. RealBand does partial or complete track generation; it depends on what is highlighted. Nothing is generated until the generate button is pressed. Audio playback does not begin until all track generation is complete.

I've become aware of most of the differences you described but not all of them, Jim, so I appreciate the additional information. And while my computer isn't super fast, I haven't noticed any problems with track generation in BiaB even though "Speed up generation of RealTracks (disable on slow machines)" is enabled. Also, when RB truncated my 9-minute, 327 bar ballad at bar 220 (before I removed the Interlude designator in MuseScore), I was able to copy and paste over 100 bars with their chords and five tracks of audio into a later section of the song to restore the missing bars without any issues. From what I remember, it took about 20 seconds to complete the operation. I've also used the "Freeze" function in BiaB numerous times--both on all tracks and on individual tracks.

This is exactly what I was going to suggest. RB may have the same 255 bar (or 240) problem but should be able to import or copy as many bars as you want. When i get home one test is say you've done all that, have your 327 bars and want an additional 30. Can you highlight the next 30 bars and generate? I would use the next empty track for that and do it one track at a time, not all tracks at once.

Bob

Not to worry. Your work in MuseScore and .XML files is a brilliant idea and allows you to construct a song in such a manner it's much like a roadmap of your completed song. Because of the length of your song projects and also the fact there's so much post editing, an .XML file is crucial to staying on track to how the song is constructed, the arrangement of how instruments weave in and out of your arrangement and how you dynamically build your song. Don't make any changes to how you presently use .XML files to input your chords, melody, key signature and tempo.

What I suggest is that rather than think of BIAB to generate a song, think of it to generate each section of your song. Rather than record all of your song as one linear song, record each section of your song, export that section's audio and in a DAW, stitching each section together. That's a recording technique called overdubbing and it's used extensively in studio recordings. Each section of your song will be comprised of it's own BIAB .sgu file. This replicates the concept of a live musician recording a verse separate from a chorus, separate from a bridge, separate from the intro and outro. This alone eliminates the 255 bar limitation of BIAB. Generating and saving the audio of each section of your song allows you to drop that audio into it's place in an master audio file. That bypasses the long entire song renders you currently have to do. If you make edits to verse 3, you only work within the BIAB .sgu file of the saved Verse 3. The rendered audio with the updated edits then overwrites and replaces the current audio populating Verse 3 of your master audio file. I suggest saving each edit you make to any section as a new BIAB .sgu file so you can easily return to an earlier version of a section if necessary. BIAB .sgu files are very small your song project is dependent on a well organized file saving structure. I suggest a folder for each section saved under a Master folder. This way, if you make 7 edits to Verse 3, you will have 7 BIAB .sgu files n the Verse 3 Folder and 7 audio files with the same name as the accompanying BIAB .sgu file. In your work flow, you would do your edits in MuseScore, copy the entire section that you're editing in (intro, verse, chorus, bridge), render the audio and place that audio appropriately in it's place in a Master Audio File. The Folder structure of your song will read as an Outline of your song and you are free to work on any section, in any order very quickly and efficiently. This also differentiates between BIAB generating audio and the saved audio you will use to linearly construct your song in a DAW which will also separate how you will edit that audio.

For instance, using your song structure of intro, three 12-line verses, a 5-line chorus that is repeated three times, a short musical interlude after each chorus, and a 2-line tag at the end. All of these sections combined total 327 bars. The total number bars is irrelevant because the BIAB .sgu file for any section is comprised only of the number of bars of the particular section. If your INTRO is 8 bars, the accompanying BIAB .sgu file and any rendered audio for the INTRO will always be 8 bars. The INTRO is bars 1-8 in the Master Audio File so any subsequent edits you make to the INTRO, the rendered audio of the edit will overwrite the existing audio located in the INTRO. Each section will work in the same manner. Verse One will consist of 12 lines as will Verses Two and Three and so on.

What you're doing working in sections mimics somewhat how BIAB generates a style over a chord chart. The BIAB search engine reads the chord chart and searches hours of audio to find appropriate recorded audio (RealTracks) of that channels assigned instrument that matches the chord chart, key and tempo of your song. Rather than have BIAB search RealTrack audio, you're using BIAB section exported audio.

Another recording technique I suggest we discuss is not a widely accepted or used concept of BIAB. It's been mentioned earlier in this thread or the other you posted that BIAB is limited to seven channels and a single audio channel for a limit of 8 total channels to record BIAB generated tracks. That limit is non existent. BIAB can function as a multi track recorder and applying multitrack techniques along with the feature that each channel can have up to 10 instruments (that can alternate or play simultaneously), it's easy to generate a BIAB chord chart and render audio comprised of 70 instruments on 30 tracks. This can be done in minutes not hours and provides very complex arrangements. Using .XML should be quite useful if you are using this technique.

Once we've discussed these, then we can expand to how RealBand can take these audio and .sgu files to even higher and more complex arrangements.

1. Open song.xml in Real Band
2. Do nothing
3. SAVE song.xml as song.seq
4. Open song.seq
5.Now build your arrangement
In RB make the first 8 tracks regular tracks. Generate tracks one at a time.

Following these instructions results in glitch and erroneous chord change occurring between bar 240 and bar 241. It's essentially what the OP was doing.
Generating 327 bars on per track basis one at a time is extraordinarily time consuming.
Generating multiple tracks after editing several measures adds to what's already a time consuming process.

My suggestion was to avoid generating 327 bars of BIAB recorded audio in BIAB, RB or the BIAB VST, the only three programs capable of generating RealTracks. All three programs apparently share the same BIAB algorithm and have the 255 bar limit issue. Arranging the composition into sections and having a BIAB .sgu file and rendered audio clip matching the section for each section completely eliminates the bar issue limitation, speeds editing and rendering and emulates a live musician overdubbing onto a recorded audio track. All the audio in a DAW project is not subject to where and how the source audio was recorded.

That workflow\workaround is exactly what tech support indicated a couple pages back in this thread.



No matter how much we may want BIAB to behave differently, it generally comes down to the fact that there is a workaround to get done what you need. It is just a shame sometimes that so much effort goes into learning this lesson for newbees. But as long as you are having fun...

Tech support didn't "exactly" indicate "that workflow\workaround." Their suggestion to "export smaller portions as a .wav then import them into another DAW . . . " is quite different from the process that Charlie is suggesting/recommending. My concern from the beginning of my use of BiaB was (and still is) that piecing together chunks of short BiaB generated song tracks into a single, long song arrangement would result in odd and/or glitchy audio seams occurring at the junctures of those chunks. The fact that this occurs in RB's method of breaking up a long song into 240 bar sections confirms my concern. This is why Pipeline's suggestion in the other thread to use BiaB's VST plugin with Tracktion appealed to me so much because I had (and still have) the impression that using two instances of the BiaB plugin the way he described would eliminate or minimize the chances of odd and/or glitchy seams occurring between the track sections that those two instances of BiaB would generate. But if the workflow method that Charlie is suggesting would accomplish the same thing, then his method is also appealing to me, and there's no reason for me to have this concern .

Furthermore, MusicStudent, I was already using my own workaround that accomplished the same thing that Tech Support was suggesting but in a different way. Instead of exporting multiple .WAV files from within BiaB (or RB, which Tech Support didn't mention, so I'm not sure which program they were referring to in their email) and then stitching those separate files together into one full length song in a DAW, I've been exporting one .WAV file from BiaB that contains all the elements of my song after which I replicated that .WAV file two or more times within Traction and then stitched those separate .WAV files together (after cropping them properly) into one full length song that I could export as a single .WAV file.

Below is a screen shot of Tracktion with one of my songs pieced together---the 7+ minute ballad that I spent 30 hours on in one particular week a couple of months ago. The first track is the drum track. It was produced from a single .WAV file from BiaB that I replicated six times. The reason I had to do this is that the primary down beat of the drums switched at various places in the song.

The second track contains two copies of a partial drum track that my producer had created for me so that I would know where the primary down beat of the drums was occurring in the verses. Appended onto the end of the second copy of his drum track are three copies of BiaB's drum track, which I needed to bump up the volume of the first track to match the volume of my producer's drum track.

The third and fourth tracks contain two copies of BiaB exported .WAV files stitched together. The third track is the finger-picking guitar and base guitar combined from BiaB, and the fourth track is the strumming guitar from BiaB.

The fifth track is a full-length .WAV file of an earlier version of the same song that I had previously exported from Traction after I had stitched together two copies of a BiaB exported .WAV file of all the instruments in my song except for the drums.

The seventh track contains four copies of a three note transitional drum section that I exported from MuseScore to emulate and replace the transitional drum sections in my producer's partial drum track. I created these to make it easier for me to adjust the location of these transitional sections if I needed to add or remove a measure before or after the occurrence of these transitional sections.

The eighth track contains a .WAV file of the melody of my entire song that I exported from MuseScore.

Have you tried importing as a midi file as opposed to xml?

Have you tried importing as a midi file as opposed to xml?

Muzikluver,

Mixers blend two audio clips together to create a continuous sounding audio sound by performing a cross fade (also written as crossfade). Track 1 audio is reduced while track 2 audio is increased. Band-in-a-Box and RealBand automatically cross fade when linking two audio clips together to create RealTracks. Many daws have an automatic crossfade feature that can be turned on while editing tracks together. I don't know if Traction has a crossfade feature.

+++ HERE +++ is a video by the University of Kentucky that demonstrates a cross fade.

No because a midi file wouldn't have all the chords. Also, the melody is included in the .XML file as midi and ends up as Piano2 in Track 6 of BiaB. I always turn that off and import a .WAV file of the melody from MuseScore because it sounds much better than the midi track.

RB can interpret them.
The melody wave is probably better because the synth in the notation program. Change the synth in RB to something better than the awful wave table.
I assume your song is a complete score in the notation program.

<<< Instead of exporting multiple .WAV files from BIAB or RB and then stitching those separate files together into one full length song in a DAW, I've been exporting one .WAV file from BIAB that contains all the elements of my song after which I replicated that .WAV file two or more times in Traction and then stitched those separate .WAV files together (after cropping them properly) into one full length song that I could export as a single .WAV file. >>>

It's my suggestion you export multiple .WAV files from BIAB and stitch the audio files into your full length song in a DAW rather than attempting one .WAV file that contains all the elements of the song that you cut/paste/copy to increase the length of your song. Here's why. The elements of your song you are replicating are exact duplicates of the original audio you're replicating. What you are doing is looping the same audio. So if you copy a verse and paste that verse into another verse, it's the same audio. Whereas if you construct your song in BIAB with each verse having it's audio generated and rendered where each verse is constructed by its own .sgu file, no verses will be exactly alike. Your song will sound much better and also more human. The result will carry over into every section of your song, be it intro, chorus, verses, bridge and outro.

<<< My concern from the beginning of my use of BIAB was (and still is) that piecing together chunks of short BIAB generated song tracks into a single, long song arrangement would result in odd and/or glitchy audio seams occurring at the junctures of those chunks. >>>

This is one of the unique features of the intelligence of BIAB generated audio and should never be a problem or concern. Learning and applying proper multitrack recording techniques will virtually assure successful smooth transitions.



<<< No because a midi file wouldn't have all the chords.>>> BIAB automatically decodes and populates the Chord Chart. Since you've written the song, you will immediately detect any errors and can manually correct those you find.

I'm familiar with crossfading from the gradual transitions between songs on AM and FM radio and from creating my own custom compilation cassette tapes decades ago. Yes, Tracktion does have a cross fade feature along with several other fade features. Check out the section under the red arrow in the attached image below.

Thanks for the suggestion, silvertones. I may try that with my next song, but I doubt that RB's chord interpretation will match the chords that I've come up with from my own analysis of the melody and experimentation on my guitar. Even after I've figured out all the chords to my songs (I do that last after I've written the melody and lyrics and entered them into MuseScore), my producer will always recommend a few chord changes at various locations in my songs. Sometimes, he recommends that I change a melodic section to eliminate a chord or two or to change a strong chord progression to a weak one (or vice-versa), as he did with the last song I gave him.

That's a great idea! I don't know how to do that, but I can check the manual. This would eliminate a recurring step and save me some time.

Yep, it sure is. That's where I put most of my effort in the beginning of the songwriting process for precise documentation of the melody and lyrics to my songs because I'm not a singer. This reduces the amount of time I have to spend prepping my songs in BiaB.

Thanks for your suggestion, Charlie, but this would not be beneficial for demos of my songs that I take to my producer because he'll be creating his own arrangement for those songs. So, going through the extra effort with these additional steps would be a waste of time. However, your suggestion is great for demos of my songs that I want to share with other people besides him---especially if I'm pitching a song to an artist, label, singer, etc. with the goal of having them acquire or license it for their use. I have a couple of song demos that I need to redo in BiaB using your suggestion to make them sound even better than they already do sound.


The key phrase here is "Learning and applying proper multitrack recording techniques . . . ." This is going to take some time for me to do as I become more and more familiar with the features and capabilities of both BiaB and RB by experimentation, by watching the tutorial videos on this website and on Youtube, by reading the manual as needed, and by reading the discussions in both the BiaB forum and this one.


Silvertones made the same comment about RB, to which I responded as follows:

"Thanks for the suggestion. I may try that with my next song, but I doubt that RB's chord interpretation will match the chords that I've come up with from my own analysis of the melody and experimentation on my guitar. Even after I've figured out all the chords to my songs (I do that last after I've written the melody and lyrics and entered them into MuseScore), my producer will always recommend a few chord changes at various locations in my songs. Sometimes, he recommends that I change a melodic section to eliminate a chord or two or to change a strong chord progression to a weak one, as he did with the last song I gave him."

<<< this would not be beneficial for demos of my songs that I take to my producer because he'll be creating his own arrangement for those songs.>>>

I don't understand what you mean by your statement above. What do you provide to your producer as a demo for him to create his arrangement? A single stereo audio file? an .XML file? A Pro Tools or other DAW session containing all the individual tracks?

How does his arrangement based from your demo and suggested changes to your demo affect how you created or will edit your demo?

It will. It'll interpret the midi notes in the score.If you get weird chords they will be technically correct but may not be pleasing. Those you can change.
Btw also drop the use of biab. I did 10 years ago. Learn RB it does more than biab.The xml file should work the same.
Before you import turn all bb tracks in RB to regular tracks.This should give you the whole song in midi format.Right click on a track in RB and generate any Real track. Forget about styles for RT. Just add 1 track at a time with musicians you want not those dictated by the style.
Sidebar: I'm a pro player playing 4 days a week for 8 months. Then I go into new song mode. I have over300 songs done this way.

In these days if you don't submit a perfect demo to a producer he wont even listen. Even if the song than goes 180°. I also do some local producing. If the artist doesn't care about his demo why should I.

Send me a link to an xml file and I'll send you back a song done my way.

In these days if you don't submit a perfect demo to a producer he wont even listen. Even if the song than goes 180°. I also do some local producing. If the artist doesn't care about his demo why should I.

It takes less than 1 min. to generate a 320 bar Real Track track.
BTW even though your tracks in RB have been made to regular tracks as long as they are REAL TRACKS you can still regenerate the whole track or just sections.
You can also edit just like a word Processor. Make sure to use the "snap feature" You can cut, copy, paste etc.