Open FMOD event that’s fairly complex, like say, 8 tracks of Scatterers with 20+ clips and automation lanes in each one is what I used to repro it. (I am also experiencing rather chunky/degraded performance adjusting knobs and such, the UI refresh is noticeably slow on a Mac Studio. Wonder if it’s related.)
Play the event.
Toggle SOLO or MUTE on a track multiple times.
OBSERVE:
The button eventually gets visually stuck, and the orange/red light stays on, even though there’s still a functional, audible change.
EXPECTED:
Button should turn on/off accurately to reflect the state of the track.
Thanks for letting us know about this issue. Unfortunately, I haven’t been able to reproduce it here, which makes me think I must be doing something differently to you.
What are the specifications of the Macintosh that you’re using?
Approximately how many times do you need to interact with the solo or mute button in a session before the issue manifests?
Does deselecting and then reselecting the event in the events browser fix the issue?
Does stopping and then restarting the event using the transport controls fix the issue?
What brand and model of mouse are you using?
It’s possible that the issue only manifests with specific types of content. Can you send us a copy of the event that exhibits this issue - or, failing that, can you describe its content in more detail?
Argh, another elusive one! Well @joseph I’m confident we’ll get to the bottom of this with your keen eyes for details. But first let me answer your questions!
What are the specifications of the Macintosh that you’re using?
Mac Studio M1 Ultra, so it’s running FMOD Studio in Rosetta 2 (can’t wait for a native version!).
Approximately how many times do you need to interact with the solo or mute button in a session before the issue manifests?
A few clicks, no more. I usually don’t need to do it a lot, but it’s so unpredictable. Just a few fast clicks!
Solo is visually easiest because it dims the other tracks, so I know something’s wrong when Solo is lit but the other tracks not dimmed.
Does deselecting and then reselecting the event in the events browser fix the issue?
It appears to “reset” the state and work around it, yes. Until it happens again.
Does stopping and then restarting the event using the transport controls fix the issue?
No. Solo stays lit, other tracks stay undimmed.
What brand and model of mouse are you using?
Microsoft Intellimouse Pro and it’s wired, so it’s not a wireless Bluetooth thing. Only noticing this in FMOD Studio and not in other DAWs where I do the same functional behavior.
Sure let me message you a link to a project with the event and a demo video, so you can see exactly what’s happening! One moment…
@joseph More followup as I’ve observed what’s going on, back to what I said about “rather chunky/degraded performance”: it appears this MUTE/SOLO issue is more likely to happen if the rest of the UI is also slow. Is that what you’re seeing too?
Stopping playback “clears” things momentarily. But once I start playback, it seems very difficult to even type in parameter values and other UI operations.
We’ve tested the project you sent us on a 2020 Mac mini M1, and weren’t able to reproduce the issue. We also didn’t see any degraded/chunky performance. Given that we were using the earliest model of M1 machine available and didn’t have the issues you’ve encountered on a more recently-produced machine that outclasses it in every way, I begin to suspect this issue isn’t related to Rosetta 2 or the technical limitations of the hardware you’re using.
The behavior you described does have all the hallmarks of an application running low on resources, though. Are there any other applications running on your machine at the same time as Studio that might be consuming your machine’s resources, or managing the resource consumption of other applications?
@joseph Argh! Elusive indeed. If anyone else is seeing this, please chime in? It continues to negatively affect my daily workflow.
Can you confirm if you tried adding scatterers with more and more clips to an event, and if you notice progressively degraded performance? The example I sent you was enough to trigger issues, but when I stuffed each scatterer with even more clips, it DID noticeably get increasingly sluggish.
What I’m observing is as soon as I stop playback on such an event, UI response returns to normal. But playing it is what results in problems.
FMOD Studio itself only appears to be taking up 75% of one CPU core, in an event with eight scatterer instruments and dozens of clips like the one I sent you (which still repros it for me).
application running low on resources
I’ve ruled that one out as I have PLENTY of RAM and CPU cycles free, when I look at Activity Monitor and iStat Menus. I also sorted by “% CPU” column and quit the other contenders (including Ableton Live and REAPER) just in case to do an isolation test, and no change.
It does appear to be specific to FMOD Studio, and here’s why: even when things are “chunky molasses” with FMOD, Ableton (and UI) still runs smooth and other multitasking like video encoding at the same time continues unaffected… as you referenced.
Please let me know if you find anything else or I should try anything else for that matter, it would be such a joy to not be slowed down.
With the latest thing you sent us, I was able to reproduce the degraded/chunky performance you described. I haven’t yet managed to get the solo/mute issue you described happening, but the fact that I’ve got the performance issues happening suggests it may be possible.
More importantly, the performance issues themselves are worth looking in to, and solving them is likely to solve the solo/mute issue indirectly. I’ve asked our developers to investigate.
To give you an update, our investigation has identified some areas of our UI code that can degrade in performance when dealing with extremely large events. We’ll work on optimizing these sections of our UI.
Incidentally, I should mention that while it is entirely valid to create extremely large events of the type found in the project you provided, they do consume correspondingly large amounts of resources. For example, the event we used to reproduce the degraded/chunky performance issue consumes ~2 gB of memory when loaded, most of which is due to loading all its assets. Our bank compression will of course help reduce the amount of memory consumed by these assets at run-time, but if you might want to consider breaking up this event into multiple smaller events if doing so would be a better fit for your resource budget.
@joseph I appreciate the update, and your guidance about resource usage. This is an extreme case and likely going to be slimmed down. I wanted a clear way to show you what’s going on so I’m happy we’ve achieved that.
Is there an alternate, more efficient way in FMOD Studio to have a “jukebox” scenario where it starts playing a single event “music generator” (each made from many scatterers) at random, without having them all contained in a Multi Instrument? So it just picks one to loop and the others are ignored on trigger.
Of course now it’s very hierarchically-nested and complex. That’s one of my example use cases I’m trying to explore, along with transitioning from one of these to another so it’s a continually evolving and everflowing river of ambient music.
Hmm… For this specific event, I suggest replacing the event instruments in your scatterer instruments’ playlists with “start event” command instruments. The number of event instances created will remain the same, but the assets of events started by command instruments’ don’t need to be loaded into memory until those command instruments are actually triggered, instead of all the assets associated with every event having to be loaded up-front.
This method does mean that there may be a slight delay when the command instruments triggered, to allow the associated assets to be loaded, and also means that the events spawned by command instruments won’t be routed through the parent event, but through the referenced events’ normal routing paths. Whether those are disadvantages or benefits depends, of course, on the needs of your project.