PG Music Home
One issue users face is the program fails to load RealTracks and RealDrums content because the content is stored in two locations. My proposal is for the Band-in-a-Box program to have the capability to use two content storage locations.

There are too many reasons why RealTrack & RealDrum folders and files may exist in multiple locations. So I won't try to detail them. However a glance at forum threads confirms the issue seems to be commonplace. I have two proposals regarding how the issue can be addressed.

Proposal # 1: Add a "find this patch" button to each track in the Patches tab of the mixer. If a track patch name displays as N/A then pressing the track "find this patch" button will open a search window. A visible patch search scan (similar to what is displayed during a virus scan) will be initiated across all internal and external storage drives. When the patch is found, the scan stops and the patch is loaded. When the patch is not found the search window displays a "search complete, patch not found" message along with an opportunity to contact PG Music about the issue. While the scan is in progress the "find this patch" button should toggle to a "stop this search" button that ceases the search.

Proposal # 2: Add a second location for RealTracks and RealDrums. The first location is primary and searched first. If a patch is not found then the program advances to the second location.
+1

Jim,
Thinking about what you wrote and a little about the future...
My assumption is, users have multiple locations for RT/RD mainly for 2 reasons:
1)lack of space on main drive
2)improper installation by user or by the program
+ Various minor reasons that are not 1 and 2

While I support your idea, leaning toward Proposal #2, I can offer Proposal #3 as a variant.

Proposal #3
SSD hard drive space is translated to something around 0,05 cents per GB. I believe Ultra Pack (which I think most users have) and all extras are all under 200GB, so we are talking about ~$10-$15 to fit everything on internal drive. In not distant future price per GB will shrink even more. While BIAB content is expanding, it is not exponential, so I believe it is safe to assume that next 2-5 years UltraPack will remain under 250GB.

So, Proposal #3 is this:
Have an option of finding/searching for "missing" items in various location and sync-merging (newest files) to a single "default" folder of choice.

It should not delete donor folder, if it is important to someone for any reason.... And maybe even have an option to delete "donor" folder to save space-> This can be an option in "cleanup routine".

P.S. Also, if I may add to this, as it is in a way related... To be able to find "missing" preview (demo) files for RT/RDs, styles and have means to obtaining them if they are missing on computer, not going to internet to audition them through picker. If you have RD-RTs-you should have their demos. Period.
In case it helps your analysis, the audiophile version requires just about 1.5 TB now.
Quite a worthwhile idea.

We have a navigation program that allows users to have maps stored in multiple locations.
A simple text list of the directory paths where their maps are stored is all that is required for our program to be able to find any maps within their computer system.

+1
I think the most likely reason for this problem is that some users have difficulty understanding where files are stored. Given that this isn’t likely to improve, if a programming solution exists, then sure, +1. However, I think I might lean toward adding more power to the existing Cleanup routine to seek out all BIAB files and consolidate them. But, whatever works.
Originally Posted By: Matt Finley
I think the most likely reason for this problem is that some users have difficulty understanding where files are stored. Given that this isn’t likely to improve, if a programming solution exists, then sure, +1. However, I think I might lean toward adding more power to the existing Cleanup routine to seek out all BIAB files and consolidate them. But, whatever works.

It could search for them and consolidate them, or it could search for them while running as a low-priority background thread and create a directory structure of where they all reside.

Yes, and many other options are possibly available. Just trying to suggest ways to deliver Jim's suggestion.
RustySpoon# (Misha),

I believe you and I are saying the same thing in different ways regarding my #1 proposal and your #3 proposal.

The major difference is your proposal adds what, or how, the folder path is displayed at the top of the RealTracks and RealDrums windows; if the path is natural or symbolic. I really do not care what path is displayed at the tops of the Picker windows because the Pickers are completely bypassed by the "find this patch" track button.

The "find this patch" button I envision would be a new and unique feature with nothing in common with the RealTracks Picker and RealDrums Picker other than they all exist to manage content.

"find this patch" feature limitations:
(1) A track's "find this patch" button is not active unless a BiaB track patch (RealTrack, RealDrum, MIDI SuperTrack, Loop, etc.) is labeled N/A.
(2) Each search is track patch specific. For example, if a loaded song file identifies five track patches as N/A then five tracks will have an active "find this patch" button.

The "find this patch" search feature searches all assigned and active storage drive letters for the track patch name. This is important because storage media can assume a different drive letter every time the media is connected. This search effectively bypasses the need for the user to know the storage location.

When a patch is found, the patch will be loaded. Optionally, there can be a pop up window that asks if the user wants the found patch path to be added to the song file memo or another suitable location.

When a patch is not found, a "search complete - patch not found" displays. Optionally, there can be a pop up window that provides PG Music Support information.

As VideoTrack and Matt noted there are many ways the N/A patch issue can be addressed. Hopefully this discussion will provide PG Music with a heightened awareness of the problem.
© PG Music Forums