It might, but my SAFP use case, apparently, is not like most other user’s SAFP use cases that I’ve seen. For example, I’ve seen a SAFP with a list of songs each, ostensibly, containing all backing tracks for the song rather than creating a separate SAFP instance for each instrument and vocal track per song, as I want to do. And, I’ve seen other different SAFP use cases, so I’m not sure how you’d instantiate your three proposed fields without breaking current SAFP design–which, obviously, we don’t want to do.
I understand that the operating system does the root folder remapping when an external (exFAT formatted) SSD is connected to a PC (e.g., G:\ on my Win11 PC is remapped to /Volumes/[SSD_NAME]/ on my MacBook) and that’s how GP determines how the Options->Locations file paths are automatically changed. But what I still don’t understand is why the SAFP cannot do the same automatic remapping (provided the audio tracks reside in the same underlying subfolder structures).
When I copied my original gig file (Win) and renamed it to gig file (Mac) and GP opened it from the external SSD now attached to my MacBook, it correctly remapped the Options->Locations files, but I had to manually drag and drop the song track files to each SAFP to get the gig file to play on my MacBook. (Which brings up another issue, the SAFP File List View only shows the terminal filename and hides the entire absolute path (except when it can’t locate the file). Also, hovering over a valid filename doesn’t reveal the full path as I read somewhere that it should).
I suspect it is because SAFP hard codes the absolute paths to audio tracks and will not automatically remap those tracks to where they reside under the new OS. So, since the remapping is unavoidable when switching platforms, I still don’t see why once the remapped gig file (including all SAFP tracks) is complete (which should be very fast), GP couldn’t just ask the user if they want to save the remapped gig file or just leave it cached on the current platform; perhaps auto renamed to gig file 2 (and/or enable the user to rename it) so if the user exits GP and wants to bring it up again without enduring the remapping process again, they could simply reopen gig file 2.
What I’m trying to avoid is having to maintain two (or more) gig files and/or having to manually change every SAFP audio track when the gig file is moved to an alternate (e.g., live or backup) platform. I’m quite sure that this ability would be gratefully appreciated by other users, such as requested by bartiest in his Virtual File location post.
I’m also getting concerned that this SAFP/backing track issue may become more problematic when I’m through with my newbie/experimental learning phase using a gig file for just one song attempting to create a reasonably efficient and workable template that’ll later become a master gig file that contains all my songs. But I’ll cross that bridge when I come to it.