Why does my suggestion (Gig Performer Cross-Platform Issue & Suggestion - #17 by dhj) not address the problem?
As edm11 said, I was responding to jeffn1’s comment about using symlinks that you then quoted and that’s what I was responding to in your follow-up comment.
My comment was not about inserting multiple paths in the SAFP. But since I believe that is what you may be referring to, I’ve attached a zip file containing my original Win gig file used to seed the Mac gig file, how Mac changed it and snapshots of the before and after SAFP for drums, Locations and Wiring diagrams on both machines. I really don’t know how to document the problem I’m having any better than that.
Further, GP is still leaving zombie background processes on my Win11 machine every time I quit GP. And, if I load the Mac gig file version on my Win11 machine (just to see how Mac changed it from the original Win gig seed file) and then quit it. I can no longer bring GP up without deleting all the background processes it leaves in memory.
Hope that helps!
GP Win & Mac Gig Files and File Path Screenshots.zip (16.1 MB)
Bias FX2 used to leave processes in Windows long after it closed. I wonder if your Bias X plugin is the root of the issue. You can obviously test this by disabling the Bias X plugin in the GP Plugin Manager, reloading your gig, then closing it again to see if the extra processes are still there. I believe the Bias FX2 processes would start after opening the UI of the plugin, so you can also check your process list to see what happens when you open Bias X.
I understand what it did — (I wrote that part of the system!) — I’m trying to understand whether my proposal would solve your problem
What happens now is
-
that the SAFP keeps the entire path to the file so that it can quickly find it again when the gigfile is reloaded.
-
If the file is not there, then GP will search for that file in all the locations you specify in the Locations option (recursively as well).
-
If the file is found at one of those locations, then the entire path to that file is stored in the SAFP and then (1) above applies.
Now, if I understand you correctly, the problem you have is the following:
A. You copy your gig file from a macOS machine to a Windows machine (say)
B. On the new machine, the full path to the song (i.e, as defined in (1) above doesn’t work ) so GP will search locations on the Windows machine
C. The song is found at one of those locations
D. The SAFP is updated with the full path to that file using Windows format (e.g. drive letter colon path, etc)
E. Now, when you copy that saved file back to macOS, the hard coded path is no longer valid (obviously a Windows path with a drive letter won’t work) so we have to search locations again.
Consequently every time you copy a gig file from macOS to Windows or vice versa, GP has to search all over again for the correct path - for every song.
If that is what is happening - then I think my proposal to store two paths for each song would address this issue. So instead of a single field storing the entire path to the file, we would have three fields
- the file name with no path
- a macOS path to the folder where that song file lives on a Mac
- a windows path to the folder where that song flle lives on a PC
Now, when GP has to search for a song using locations on your Mac, it will only save the path for the Mac. If there is already a path to the folder for Windows associated with the SAFP, it won’t be touched. Now, when you copy your gig file to Windows, GP will only use the Windows path which won’t have changed so no search will be necessary.
Does this solve your problem?
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.
When I discovered that BIAS X was preventing me from bringing GP up again after exiting it, I checked for an update and there was. So, I downloaded the latest greatest BIAS X update (v1.2.3.60424) and it fixed the problem with not being able to bring GP back up after exiting.
So, I took your advice and disconnected BIAS X plugin in my gig file, to no avail. The zombie process was still present after exiting. However, removing the BIAS X plugin altogether and testing the updated gig file did eliminate the zombie GP background process scenario. This sucks because I want to use BIAS X custom plugins its AI generated from guitar stems of songs I want to cover. I guess, I need to open a ticket with Positive Grid for BIAS X plugin leaving GP zombie background processes.
Thanks Ed for the advice.
FYI: I opened a ticket with Positive Grid regarding the zombie background processes BIAS X leaves behind after exiting Gig Performer 5. I also discovered that this is not unique to Gig Performer as it also leaves background processes behind when exiting Pro Tools Studio.
Thanks for reporting this - it is unfortunate but true that many (if indeed not most) issues ascribed to Gig Performer are in fact issues in plugins. But since Gig Performer is the name of the running process, it’s easy to assume GP is always the culprit.
D