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

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.