Best practice regarding FMOD source control branching

Hi folks,

I’m working with a coder via Git/Sourcetree who is adamant that the .fspro project file should be fully exposed in the same repository alongside the game/engine files (and therefore the .fspro file exists separately on every branch) to ensure there’s a project backup with each Commit/Push. Probably a habit of Unity coders who have Unity set to read directly from the project file, not banks. Is this normal?

In theory it’s a good idea but in practice a nightmare as the project ‘hot-swaps’ with every branch change/Checkout so I need to be very careful. As a means of staying organised, I work off a master project not exposed to source control, pasting events into specific feature branches only to avoid merge conflicts.

AFAIK it’s common practice to have just one audio branch and merge from/merge into the main Dev branch, not have a separate project iteration existing in every new game feature branch.

Would love to get any thoughts from game audio pros on this.

Thanks, Matt


I can completely understand what you write and what your situation is. The problem is often that coders don’t understand how FMOD works. I was also once involved in a Unity project: Until it became multi-platform and you needed separate banks for each platform anyway. In the current UE5 project it is not possible to implement directly from the FMOD project anyway.

Can’t you just explain to the coders that it just doesn’t make sense to have the project directly in-engine?

In terms of source control: I’m working with Plastic SCM, but I have a coder on my side who also understands quite well how audio and FMOD works. Well, UE5 works quite differently from the data structure, but still, I would recommend working only with banks. The FMOD project I would not even have them in the same repository. I mean, there are also audio assets in it, which have no place in the dev branch. The 3D artists don’t have their Maya/Blender projects in the branch, do they?

These are my thoughts about it.

1 Like


I can’t really offer a single best practice, as your use of source control with FMOD is going to depend the size of your projects and your team’s needs - there’s no right or wrong answer. For larger projects, a separate repo specifically for the FMOD project might be useful, as:

  • FMOD projects can get quite large - you may not want your FMOD project in the same repo as an already large game project

  • You don’t want the whole dev team pulling every audio asset, just the small subset of people working on audio

For a smaller project, it might be better to include your FMOD project in the same repository:

  • Project size isn’t that much of a factor

  • Overlap in roles with smaller teams means more people need to care about audio changes

  • Multiple repos may unneccesarily cost you extra, depending on what source control option you’re using

With that said, whichever means of source control you use, you’ll definitely want to be tracking your built banks in your game’s repo.

There is documentation on Using Source Control with FMOD Studio, and with FMOD’s Unity and Unreal integrations. It’s more about functional stuff as opposed to how to structurally approach using source control with FMOD, but it might be helpful regardless.

1 Like

Hi there

I’m one of those programmers, just giving a different point of view. My company is small to medium sized, with a couple of designers and usually one or two programmers working on the integration. We also use the same fmod project for both music and SFX, so both the sound designer and musician have to share the same fmod pro file.
For the time being, we keep the fmod assets in the same repo as the project, and it’s worked well for us in fully orchestrated games. Most changes in fmod are changes to the project, and the ocassional audio drop. That’s not a huge issue for versioning tools.

There are 2 separate things in your post:

First, the normal way we work is, yes, have a music_main branch, which receives merges from main, and is merged into main. We have a sfx_main as well. Both the musician and sound designer merge main into their own branches. Then, someone from the integration team merges their branches into main.

There’s no real reason to have the musician hop between feature branches, since music is its own feature, and it can be merged from main into any other branch. The important idea is that main always maintains the most recent and working version of everything. Feature branches are, per definition, unstable and not a workable backup of anything.

Second, you imply that there’s a different fspro file in each branch, which is not really the case. Each branch has the version it had when last merged from main. If merges from main are common, as they should, everything should be pretty much the same between all current feature branches.

I hope that helps finding a workable middle ground for your team!

P.S.: A small correction to the comparison to artists not keeping Maya files in the repo. The equivalent to that would be the protools/whatever project.
The fmod project and assets are closer to the fbx/png files created for a model. Having it accessible to the team is important, because sometimes tweaks or small fixes require changes in the audio or music.
The banks are closer to the final compiled binary version of in-game assets.



These are 3 valuable perspectives, thankyou folks.

kike sorry let me be more clear: What I mean by ‘feature’ is not as kike says, not just Audio branches, but closer to the word ‘releases’ (ie a different branch every time new stuff is added to game - for example new weapon set, seasonal content, new map ect). Your description I’d just call an Audio branch. So in my case there’s literally a different FMOD project in these differing branches (ie the same project but timestamped to different dates) - it’s horrible for me to work in this way as I can’t keep track of Events or Snapshot behaviour easily across different versions of the same project. I can’t imagine any Sound Designer tolerating it.

My conclusions from all your contributions:

Having different FMOD project iterations in different feature/release branches (in my use of that phrase) is more of a ‘hangover’ from old Unity days - it’s just not the way FMOD is designed to work and although it might be easier for my Code colleague to look at using an older version of Unity (as they see it all as lines of code anyway) it’s not good practice as it causes general chaos for Sound and indeed nobody else works in this way AFAIK. I hate the thought that there could be Snapshots or Mixes set up on one feature branch that can’t easily merge into another, let alone more basic issues caused by not having a clear ‘working’ project. It’s not just a case of merging Events - although that can also go very wrong if you can’t see everything in one project.

For smaller projects only, it makes sense to use Audio branches, maybe one for SFX and one for Music that can push and pull to/from Main, which can push/pull with other (feature/release) branches. From what I can see online, this approach seems common when Coders want a hand in the FMOD project, perhaps because they are building the banks themselves with assets created by others, but Code do the integration and testing/tweaking. As Louis says, when there’s more overlap of roles perhaps in smaller teams. This is not my case - nobody else needs to get into the FMOD project - I have it constantly open as I work. I integrate and test all the sounds, I just ask Code to send me parameters and to create the code hooks when required.

I offered to go along with the idea of Audio branches (but not feature/version branches) as a compromise, but the bigger the project gets the less I like this idea - more time gets wasted pushing/pulling on Version Control software and things slow down as the project develops. I’m worried they haven’t thought that through, but they would complain with all the extra Version Control traffic with my constant swapping of sound assets.

This seems a clear cut case for a separate Audio repository - if anyone disagrees please share your thoughts, I’d love to hear from you, this is all new to me still!

Thanks again folks, great community here.