At our studio we have an old game that we would like to take a new pass at mixing.
I was wondering if it’s possible to create a copy of our project and in that project do all the mixing in, and then merge the project back into our old one? The mixing will mostly involve reorganizing the buss structure.
The reason we can’t just replace the old project with the new one is because we push updates to the game almost weekly and we suspect the mixing will take more time then a week.
I suspect that it might not be possible, but wanted to see if anyone has any experience or answer to this.
FMOD’s source control integration does permit merging changes made in separate versions of the project - in fact, that’s the main benefit of using our source control integration. Each user collaborating on a project is actually working on the copy of that project that’s present in their local workspace; every time they select “Sync Latest, Merge & Commit…” they merge their changes into the copy of the project stored in their source control repository. If you want to avoid merging your local changes into the repository, all you need to do is avoid using the “Sync Latest, Merge & Commit…” command.
There is one limitation of this: FMOD Studio cannot intelligently merge changes made by multiple different users to the same file. This is rarely a problem, however, as an FMOD Studio project consists of not one file, but many; each bus, snapshot, event, asset, bank, shared effect, parameter, and folder in your project has its own metadata file in the project folder, and can be edited independently.
This means that as long as the person who’s updating your project routing only changes the routing destinations of events and buses that aren’t currently being edited by anyone else, they’ll have no trouble working on the project at the same time as other people. (To clarify, when I say “the routing destination,” I mean only the specific bus that an event or bus is routed into. Other buses further downstream are irrelevant. For example, if the “cow” event is routed into the “barn” group bus and the “barn” group bus is routed in turn into the “farm” group bus, rerouting the “barn” bus into a different group bus does not count as changing the routing destination of the “cow” event, as it is still routed into the “barn” group bus, even though the “barn” group bus’ routing destination has changed.) Thus, if they only reroute buses and do not touch events, you won’t have to do anything special to make this work.
If they do need to change the routing destination of an event that’s being worked on my someone else, the procedure is simple:
The person working on the event should “Sync Latest, Merge & Commit…” to ensure their changes are subnmitted to your source control repository.
The person rerouting your project should “Sync Latest, Merge & Commit…” to make sure they have the latest version of the project.
The person rerouting your project should reroute the event.
The person rerouting your project should “Sync Latest, Merge & Commit…” to ensure their change is subnmitted to your source control repository.
The person working on the event should “Sync Latest, Merge & Commit…” to make sure they have the latest version of the event, then resume working.
Thank you so much for your detailed reply Joseph! All this info helps a lot but I have a follow up question that I was wondering about.
Is it possible for me to create a branch of our main project were we do the mixing and merge in changes from the main project to the mixing branch? As far as I know it can’t be done from within the FMODs Perforce integration because the the selected project needs to have a specific path and name. Please let me know if I am wrong.
If it can’t be done through FMOD integration is it possible to do from Perforce? Would merging only specific .xml files from the mixing project into the main one cause issues?
Yeah, I find it really difficult to explain the problem, so no worries at all.
We have decided to go with another path, so it has all worked out. However I am still interested to understand if it somehow doable.
So I’ll give another go at trying to explain the problem:
We, two sound designers, collaborate on a live service game’s FMOD Project (Project A), we both update the project daily and by using FMODs perforce integration we keep it synced between us.
We need to create a copy, Project B, for long-term mixing (weeks/months), were we both want to be able to mix and experiment on our separate machines.
At the same time, Project A will continue to be updated with new events.
The question is: can Project A’s events be merged into Project B semi-regularly (without manual copying) to keep the mix project current?
Eventually, Project B will replace Project A.
The reason I was writing about paths is because in the perforce integration you have to specify the project to merge or sync with. Since Project A and Project B have different names and locations within Perforce, it seems impossible to directly merge them using the built-in Perforce integration. Is that correct?
Hopefully this makes more sense, but let me know if it doesn’t. Thanks for you patience!
Ah! I think I understand. Or at least, I think I do.
One important question, though: Do you want to be able to regularly synchronize the changes being made in project B? As in, if your colleague makes a change in project B, do you need to be able to get latest and see that change in your copy of project B, in addition to any changes that’ve been made in project A? I ask because the answer to that question determines whether what you want is easy and possible.
If you don’t need to synchronize the changes being made in project B, then this is actually fairly simple to achieve. You don’t actually need the projects to have different paths in your Perforce repository, since (as you’ve observed) that will prevent you from being able to synchronize project B with the changes being made in project A; instead, you’ll want to create two different Perforce workspaces on your local machine, one for project A and one for project B, but point both of those workspaces at the same Perforce repository, which only needs to contain a single copy of the project. By using “Sync Latest, Merge, and Commit…” when working with project A and “Sync Latest and Merge Project…” when using project B, you’ll be able to get all of the changes made in project A in project B without submitting any of the changes made in project B to your repository, thus keeping those changes out of project A.
On the other hand, if you do need to be able to regularly synchronize the different copies of project B, this workflow isn’t something that our Perforce integration supports. You could technically do it by using Explorer or Finder to perform manual copying steps to move files from project A to project B in your local workspace and use the “Source Control > Identify Local Changes…” command to make FMOD recognize those changes so that you can commit them to the repository, or make use of multiple overlapping workplaces and “Identify Local Changes” to fake the changes being made locally, but either option it would be time-consuming and introduce a high likelihood of human-originating merging errors.
Our Perforce integration is largely built around the premise that there is just one true cannon version of your project, and it’s the one in your Perforce repository. It therefore doesn’t handle multiple contradicting truths very well.