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

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.