This was a very interesting discussion four years ago and I'm glad it got revived. A lot of things could have changed under the hood since then so I'm curious if my thoughts and guesses then are still valid now.
First, since the RT's are a main part of PGM's "Secret Sauce", I don't think they're going to release all the goodies that go into producing a Real Track, these user templates are dumbed down versions.
Second, that list of chords that Biab recognizes is for midi, not necessarily the RT's. We all know RT's are recorded by a real person playing that instrument in a studio. If s/he didn't play a proper 6/9 chord then that chord gets ignored if you're using that RT. Or maybe it gets subbed with a standard major 6th or 9th.
Third, the file sizes. This is part of the secret sauce I think. To me it's logical to assume there is a max file size for an RT because if there wasn't and somebody produces a massive piano RT that has all of those chords in the list played in all four keys so they can be properly transposed, the generation times would be huge, like measured in minutes not seconds.
And even if that massive RT was produced, what I described is only one chord inversion in one position on the piano and it's the same for guitar. You should have at least two different inversions but three or four are really needed to cover jazz properly so multiply that list of chords by one of those factors.
For any noobies, understand this is no problem with midi. We have printed out and discussed midi piano tracks generated by Biab and they are really good. Lots of different chord positions, left hand voicings etc and all based on the style. Not so with the Real Tracks and I'm pretty sure it's because of file size limitations.
Fourth, I don't think it would do any good to take an RT soloist and run it through the ACW because soloists are plying single notes and the ACW doesn't work well with single note lines, it needs the bass and a chording instrument.
Just some thoughts.
Bob
My thoughts:
FIRST: I think they've given all the goodies just not in one complete explanation with full step by step instructions. They left out how their algorithm accesses all the audio data and many users don't consider the UserTrack Development list when they create their personal UserTrack and create SGUs that are specific audio for those song circumstances. Not addressing as many different possible transition points as possible, these UserTracks are sub par creations.
My point here is the templates are complete but for a quality User RealTrack, multiple SGU templates must be used with each addressing a specific and more complex piece of audio the algorithm is programmed to locate and use. For instance; Start by creating a base chords SGU template or use one of the BIAB provided Templates. Continue your UserTrack with an intros SGU template, Create an endings SGU template, Create a common chords transition SGU template and also create an uncommon chords transitions SGU template. I think the User Development Page located in the Bar Settings Page infers the need for additional SGUs for UserTracks that allows the BIAB algorithms to recognize pointers to select and program specific audio for the Chord Chart. The Simple Pop Template will provide one intro and one ending and a set of Chords but we know that we can add additional SGU templates to add more intros and endings and more chords for our User Track to choose from. From reading the Forum intro, user manual and help files, I've come across additional clues to what I'll call 'algorithm pointers' that add to the complexity of recorded audio, be it PG Music RealTrack or a UserTrack.
One example I think is in multiple places there's reference by PG Music staff to RealTracks having 'smooth transitions'. Solo intros, endings and chord changes are all specific areas in a song Chord Chart that sometimes force users to regenerate a track in order to randomly get a correct intro, solo ending or different chord inversion. I think this is because the BIAB search algorithm found and selected a less than ideal or even incorrect piece of audio. I know that the BIAB algorithm 'reads ahead' our song Chord Chart and selects audio clips to create a performance the same as if a 'live' session player was performing our song. It selects audio in our key and at our chosen tempo and apparently there are pointers in the algorithm to recorded 'smooth transitions' for RealTracks. I wondered why doesn't the BIAB algorithm 'read ahead' and 'see' OUR programmed Chord Chart transitions by Soloists and chord transitions?
In various literature, PG Music claims soloists and players provide 'smooth transitions' and their demos always have 'smooth transitions'. BIAB does this regardless how many times we change key, tempo or chord progressions. With a bit of study and experimentation, I learned how to access this BIAB 'reads ahead' feature and always get a programmed 'smooth transition' just like a PG Music demo. I don't know if my speculation is correct or not but I can say with absolute certainty, I get a smooth solo intro, solo ending and can correct bad chord changes flawlessly every time. I have not personally had a single issue since learning the method.
This theory applies equally to BIAB algorithm reading ahead any artist's personally created UserTrack.
SECOND AND THIRD: I combine these two points as I believe they're related. I don't think it's necessarily the size of the file although that is relevant to keeping the overall program to a manageable size. I believe the limitation is content related to having sufficient audio choices for these 'algorithm pointers' to select from and to include as many of the chords recognizable by BIAB as possible. A clue to me is that RealBand Multi Riffs are limited to seven each generation even though these seven can be compiled and generated repeatedly. When Multi Riffs were introduced to BIAB, the number of each generation of Multi Riffs was also seven. Since a RealTrack is always (regardless of file size) a finite amount of recorded audio, seven seems to be the maximum safe number of regenerations of audio selections possible without producing duplicate audio clips.
FOURTH: I agree.