"I'm hoping that the upcoming release of RB 2019 Version 4 will include a fix for this issue."
I think that's the ultimate resolution you'll be satisfied with.
Now, that's an interesting statement, Charlie, for two reasons. One reason it's interesting is your use of the words "ultimate" and "satisfied." While I would be "satisfied" if this occurs, I have to say that the "ultimate" resolution I'd be "satisfied" with is if the 255 bar limit in BiaB was eliminated completely so that I wouldn't have to deal with one or more of the numerous workarounds to this limit for any of my songs that exceed it. I also wouldn't have to consider the option (along with the pros and cons) of using RB instead of BiaB for such songs of mine that are still being developed or that I may write in the future. But as you and I both know, the chances of this limit being eliminated in BiaB any time soon (or even at some point in the not too distant future) are next to none.
The other reason your statement is interesting is that it could imply that the resolution of this issue in RB would mostly benefit me. In other words, your statement has the appearance of shifting the focus away from a legitimate issue in RB that does need to be resolved and placing that focus on me personally. Now, I'm not saying that this is the actual intention of your statement because I don't know and can't know for sure that it is. But this is a definite possibility, so I think it would be good for me to dispel such a notion in case you or anyone else has embraced it. I'll begin by explaining why I believe that such a notion is a possibility.
From my perspective, this entire discussion of the existence of two problems at the 240/241 bar boundary in RB has been like a wild roller coaster ride to the moon and back because of how many other topics (some closely related and some not so closely related) have also been discussed in this thread. After all, as you pointed out in a previous post, this thread (which curently has over 190 posts) is by far the longest and most involved thread of any thread in the last seven years
past year on this entire forum. The gist of these two problems are as follows:
1) a glich that intermittently occurs at the 240/241 boundary as a result of an attempt to fix the other consistently occurring problem (by inserting a chord into bar 241), which is
2) an erroneous chord change to C when no chord exists in bar 241 and when the most recent chord in the song was not a C chord.
Considering the fact that (please correct me if I'm wrong about this) I am the first person to discover these two problems and the fact that I discovered these two problems as a result of using RB to open an .XML file of one of my songs that contains more than 255 bars, I need to make it clear that these problems are not related in any way to my .XML files (contrary to Silvertone's assertion in his post on 06/19/19 07:19 AM PT). In other words, contrary to the perception that some readers of and participants in this discussion may have had about these two problems (including myself as well initially), they are not due to RB's alleged improper handling of .XML files or to MuseScore's improper creation of .XML files. Instead, these two problems also occur when chords are manually entered into the Chord window after which any one of the "Generate Tracks" commands is executed in RB.
Considering the fact that a substantial amount of time was spent on various workflow processes in this discussion, I also need to make it clear that these two problems have nothing to do with my workflow. In other words, because these problems are not related in any way to my .XML files, and because my standard use of both BiaB and RB is to begin (as my first step) by opening a .XML file that I exported from MuseScore (rather than by manually entering chords into the Chords window of either program, as most users of these programs normally do), these two problems also have nothing to do with my workflow (contrary to your assertion in your post on 06/20/19 at 08:07 AM PT and contrary to MusicStudent's subsequent post).
Considering the fact that, even though this discussion has been ongoing since 6/7/10 and has 190+ posts so far, as recently as 06/20/19 06:07 AM PT (per a PM he sent me two days ago and which he reiterated in his public post on 06/20/19 12:35 PM PT), Silvertones thought that the newest RB 2019 Version 4 release candidate had fixed these issues and that the .SEQ file he had created from that version (to which he provided a link in his post on 06/20/19 12:35 PM PT) was proof of that. He also thought that these issues were directly related to RB's improper handling of .XML files. But when I opened that .SEQ file in RB (after I updated my RB V2 to V3), I was able to demonstrate that the issue had not been fixed in the latest release candidate version either. It was only after this that I was able to convince Silvertones that the issue had nothing to do with RB's handling of .XML files when I followed his instructions to test a new file in RB that I created by generating a single RealTrack after I had manually entered a chord into bar 238 and a chord into bar 245.
Finally, considering the fact that everyone who has used RB to automatically generate tracks for songs with more than 240 bars has ended up with an erroneous chord change at bar 241 of their songs (if there wasn't any chord already entered into bar 241 and if the most recent chord in their song was not a C chord), there shouldn't be any reason for anyone to assume that I would be the primary (if not the sole) beneficiary of a fix to these issues. Furthermore, I find it very surprising that no one else who has used RB for this purpose discovered these issues before I discovered them about two weeks ago. Surely, if soneone had discovered them, either these issues would have been fixed long ago or I would have been informed early on in this discussion that these are known issues that Tech Support hasn't fixed yet.