Bank Event GUIDs changed in FMOD Upgrade

We were using 1.08.30 and we’re in the process of upgrading to 2.01.08.

The sound banks and GUIDS.txt that we’re using were generated with the FMOD Studio app for Mac version 1.08.18.

Our app walks the GUIDS.txt and uses it to find the associated events in the bank (by GUID). With 2.01.08 some (maybe 3 out of 143 events) no longer have the same event GUID.

We’ve discovered this by doing this on two machines (one on 1.08.30 and the other on 2.01.08):

  1. loadBankMemory
  2. getEventCount on the bank
  3. getEventList on the bank
  4. printing the values of the GUID returned by getID() on the event.

Here’s a screenshot of the GUID diffs where the left side is 2.01.08 and the right side is 1.08.30.

That’s certainly not desirable, could you send us the 1.08 project that when upgraded causes this issue?
Or perhaps a stripped down 1.08 project that demonstrates the issue?

I’ve just tested upgrading our examples from 1.08.18 → 2.01.08 and they all retained their GUIDs.

Sure, is there a place I can privately send you a dropbox link? I doubt I could create a cut-down project. It only happens on some of our banks and they’re the ones with a lot of stuff in them.

You can direct message me through the forum here, or email the link to support@fmod.com. Alternatively you can upload files to us via your FMOD account profile: https://www.fmod.com/profile#uploads.

Thanks for sending the file, I’ve used our GUID exporter (File → Export GUIDs) in 1.08 and 2.01 for comparison. The three Events you see present in 1.08 (missing in 2.01) are referenced events that are not assigned to a bank. These Events considered “private events” are no longer exported with the GUIDs. You should be able to get these back (if you need them) by assigning them to a bank.

The three events present in 2.01 (but not in your 1.08 export) in my tests are present. Perhaps there is something different about how you export GUIDs vs File → Export GUIDs?

Hi Mathew,

Thanks for looking into this but that event is attached to the master bank when I look at it in 1.08.

If I right click on the event and go to “Assign To Bank”, “Master Bank” is already checked. If I click on the “Banks” tab, the event appears in the list…and I’ve even looked directly at the xml file ({967e97fd-f796-43d6-9bbc-9fe002e68601}.xml) and can see this:

> <relationship name="banks">
> <destination>{25aa234b-eb6c-41fe-9552-6b2f89d1c4f5}</destination>
> </relationship>

So I’m confused when you say that it’s a referenced event that’s not assigned a bank.

Thanks,
Chris

Sorry I should have been more specific about the events I was referring to, the Events present in the 1.08 GUID list that are missing in the 2.01 GUID list are:

{8e203672-b911-411f-bfbf-f7bc7c9da099}
{3c8e9636-1b73-4445-a2ee-73c494145cbe}
{7c9c7a6a-cdc7-4c62-916b-1f4c050aee13}

Those events are all referenced events that aren’t assigned to a bank, so they no longer appear in the list, you can get them back in the list by adding them to a bank (if you need to).

The other event you mention {967e97fd-f796-43d6-9bbc-9fe002e68601} I can see in both my 1.08 and 2.01 GUID exports. Since it doesn’t appear in yours I’m interested in how you are producing the your GUID list. Have you compared the results to our export via File → Export GUIDs?

The issue is not that the GUID is not in the export. It is! (And we just use File > Export GUIDS). The problem is that when we iterate the events in the BANK in our app, in the way that I described earlier, the GUID does not exist.

The screenshot that I posted is not the GUIDS from GUIDS.txt, it’s a printf of the GUIDS I can see by enumerating all of the events in the loaded bank…in 2.01 vs 1.08.

I hope that helps to clarify the issue. It’s a lot of finicky little details. :slight_smile:

Okay, I think we are converging on an understanding :slight_smile:

I’ve migrated your project to 2.01, built your master bank and loaded it into our API examples to print out all the GUIDs in the bank, then compared that output back to the GUIDs.txt as exported by Studio 2.01. For me there is a 100% match, specifically I see {967e97fd-f796-43d6-9bbc-9fe002e68601} in both GUIDs.txt and runtime output.

For reference, here is the code I used:

FMOD::Studio::System* system = NULL;
ERRCHECK(FMOD::Studio::System::create(&system));
ERRCHECK(system->initialize(1024, FMOD_STUDIO_INIT_NORMAL, FMOD_INIT_NORMAL, NULL));

FMOD::Studio::Bank* masterBank = NULL;
ERRCHECK( system->loadBankFile(Common_MediaPath("mathew/wrong_guids.bank"), FMOD_STUDIO_LOAD_BANK_NORMAL, &masterBank) );

int evtCount = 0;
ERRCHECK(masterBank->getEventCount(&evtCount));

FMOD::Studio::EventDescription **evtDescs = (FMOD::Studio::EventDescription **)calloc(evtCount, sizeof(FMOD::Studio::EventDescription *));
ERRCHECK(masterBank->getEventList(evtDescs, evtCount, nullptr));

for (int i = 0; i < evtCount; i++)
{
    FMOD_GUID id = { };
    ERRCHECK(evtDescs[i]->getID(&id));
    
    Common_TTY("{%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
        id.Data1, id.Data2, id.Data3,
        id.Data4[0], id.Data4[1], id.Data4[2], id.Data4[3], id.Data4[4], id.Data4[5], id.Data4[6], id.Data4[7]);
}

Yeah that matches the code I’m using to debug this. That’s good news to know that rebuilding the bank on 2.01 works…but that’s not exactly an option for us.

We have 3rd party developers that generate content (banks) for our app (using 1.08) and we really really really can’t let them be broken by updating to 2.01. Of course NEW content they make will be on 2.X but existing banks made with 1.08 need to continue to work. And they often do. Of the 6 banks that I tried, I only found two that had issues and the one I sent you is one of them.

Would it be possible for you to try to generate the bank using 1.08 but then try and LOAD that bank in C++ using 2.01? If it’s easier, I can send you the bank (generated on 1.08) to try in 2.01 and see if you can reproduce our bug.

Ah, that’s the key part of the puzzle I was missing, loading the 1.08 banks in 2.01 runtime.

I’ve just done that and can recreate exactly the issue you are seeing.
We perform runtime migration on banks to support this exact scenario, so I will now debug why it isn’t working.

It looks like the number returned from getEventCount is incorrect due to not properly handling some internal transformations we do when loading older banks. We will need to make a code change to fix this in a coming version.

There is however a workaround, instead of using getEventCount to determine the size of your array, choose a sufficiently large number, let’s say 500 for your case. Use the “count” output parameter on getEventList to retrieve the actual number of events for use with processing.

Here is my updated code:

FMOD::Studio::System* system = NULL;
ERRCHECK(FMOD::Studio::System::create(&system));
ERRCHECK(system->initialize(1024, FMOD_STUDIO_INIT_NORMAL, FMOD_INIT_NORMAL, NULL));
    
FMOD::Studio::Bank* masterBank = NULL;
ERRCHECK( system->loadBankFile(Common_MediaPath("mathew/wrong_guids_1_8.bank"), FMOD_STUDIO_LOAD_BANK_NORMAL, &masterBank) );

int evtCount = 500;  
FMOD::Studio::EventDescription **evtDescs = (FMOD::Studio::EventDescription **)calloc(evtCount, sizeof(FMOD::Studio::EventDescription *));
ERRCHECK(masterBank->getEventList(evtDescs, evtCount, &evtCount));

for (int i = 0; i < evtCount; i++)
{
    FMOD_GUID id = { };
    ERRCHECK(evtDescs[i]->getID(&id));
     
    Common_TTY("{%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n",
        id.Data1, id.Data2, id.Data3,
        id.Data4[0], id.Data4[1], id.Data4[2], id.Data4[3], id.Data4[4], id.Data4[5], id.Data4[6], id.Data4[7]);
}

Yeah! I get 146 events now instead of 143 with the getEventCount! Now everything seems to load properly and all of my events can be referenced.

Thank you! Will this be in a 2.1 patch or a 2.01 patch?

I aiming to sneak this fix into 2.00.17 and 2.01.09, which we are readying at the moment.