FM9 Firmware Version 4.01 public beta 2

[Greg Ferguson]

Fractal doesn't report things unless they're doing it.

They also don't report when they're doing things until they spring them on us unawares.

That's called being "sneaky".

 

[Greg Ferguson]

oh, I'm sure they'll add it. Not sure that it will work for people that run at presets running at 80% though.

The nice thing is that the presets continue to work normally. At your leisure you can experiment and decide whether you want to switch to a Dyna-Cab or not.

 

[Greg Ferguson]

Not sure if the fm9 and fm3 will have the horses to run it.

The FM9 does, and the Turbo definitely does, it might mean making minor adjustments to existing presets if they're converted to use Dyna-Cabs.

 

[clgnyc]

A month+ since the last beta. What’s the likelihood FM9’s jumping past 4.01 and they’re gonna drop a new release with big mystery feature instead?

 

[Roby Rocks]

oh, I'm sure they'll add it. Not sure that it will work for people that run at presets running at 80% though.

at the moment, on fractal systems, CPU usage up to 80% is safe... over the 80% the "Warning/CPU Limit" message appears. This is the limit...
Maybe Fractal can optimize the CPU usage up to 90%.... 10% of the CPU recovered, instead of changing hardware.

 

[Greg Ferguson]

at the moment, on fractal systems, CPU usage up to 80% is safe... over the 80% the "Warning/CPU Limit" message appears. This is the limit...
Maybe Fractal can optimize the CPU usage up to 90%.... 10% of the CPU recovered, instead of changing hardware.

Sure, if we're willing to give up USB and the front-panel's responsiveness.

 

[Rex Rox]

The FM9 does, and the Turbo definitely does, it might mean making minor adjustments to existing presets if they're converted to use Dyna-Cabs.

I bet there will even be versions of dyna-cabs for the FM3. But the embedded IRs, if that is the way fractal is doing it, might be lower res on the FM3. I'm just guessing based on my experience with software modelers.

You have been able to do this in most software modelers/plugins for a while (like Bias FX, etc.). If I understand correctly the way it is usually implemented is they basically embed different IRs captured at different mic locations into one cab model. In some of the software modelers the mics are just modeled with EQ adjustments, but in better ones the mics are specific to the embedded Cab IRs. So at least in these software modelers moving a mic around an image of a speaker is just a UI trick - when behind the scenes different IRs are being loaded from the cab model depending on mic selected and it's position.

If Fractal implements it this way too then it really shouldn't be too much of an extra drain on CPU. Of course its also possible to sprinkle some digital/algorithmic magic into the mix to emulate distance, pan, etc. Those tidbits will certainly eat some extra CPU. I am sure Cliff and his mates will make use of the optimal approach to deliver the best experience possible. Maybe a combination of embedded IRs and algorithmic magic?

I've only had my FM9 a month, but the more I dive into it the more it rewards me. Even the last beta was awesome. Granted it was beta 2 and not 1 - but I have not found a single issue with it. IMO it could have easily been a final release instead of beta. So maybe they didn't release so they can add more? If they are going to add dyna-cabs then I am guessing there will be a beta 3 for those before full release.

Of course I could just as easily be wrong about all of the above!

 

[Roby Rocks]

Sure, if we're willing to give up USB and the front-panel's responsiveness.

As I said: "Maybe Fractal can optimize the CPU"

 

[Axehole]

Sure, how hard can that be?

 

[Rex Rox]

As I said: "Maybe Fractal can optimize the CPU"

Hard to see under the hood to know. But its a quad core CPU right? So it is certainly possible some parallelism could help if it hasn't already been implemented everywhere possible. I used to write code for a living. I'm sure the fractal folks can see under the hood so they probably know where and why they get CPU bound.

 

[Randalljax]

oh, I'm sure they'll add it. Not sure that it will work for people that run at presets running at 80% though.

Technically not much will work for people running over 80% though

 

[unix-guy]

Hard to see under the hood to know. But its a quad core CPU right? So it is certainly possible some parallelism could help if it hasn't already been implemented everywhere possible. I used to write code for a living. I'm sure the fractal folks can see under the hood so they probably know where and why they get CPU bound.

The FM9 already has a core dedicated to Amp modeling, another core dedicated to Delays, and another dedicated to Reverbs.

 

[Rex Rox]

The FM9 already has a core dedicated to Amp modeling, another core dedicated to Delays, and another dedicated to Reverbs.

Dedicated cores aren't necessarily superior to spreading the workload across cores according to load. I'd guess the delay and reverb cores get CPU bound pretty quick while the amp modeling core could be humming along at 50% utilization - especially for single amp block patches.

So one optimization technique is schedule threads for execution to the core with the least utilization. There are plenty of OSes and real time systems that do exactly this. But I did not know Fractal took a dedicated core approach. So that would probably take a major rewrite.

Just curious: Every time I have hit the wall on CPU for some patches I have been able to think about a slightly different way to get nearly the same result. One trick I found after watching Leon Todd vids was to eliminate drive blocks whenever possible by choosing a corresponding boost type in the preamp section of my amp blocks then assigning that to a footswitch instead of a drive block. Between that and the output EQ I have been able to get very close to a dedicated drive block without as much of a CPU hit. Other tricks like using the delay built into the pitch block and turning off external delay block when possible, or using chorusing in delay blocks and turning off chorus blocks, etc.

Those approaches aren't perfect but they have helped me step back from the CPU wall a bit when I hit it. One other anecdotal observation I made yesterday but need more time to test. Not sure why this worked it is kind of counter intuitive, but I created a patch with 2 drive blocks, 2 amp blocks, 2 cab blocks, lots of modulation, delays reverb and pitch - started to hit the 80% wall. On a whim I switched the modulation to parallel instead of serial and it dropped my CPU from 80% to 76%. So anyone know why parallel modulation uses less CPU than serial modulation?

But its a decent tip anyway - especially if like me you are mostly just toggling the individual modulation blocks on and off. I almost never use a chorus, flanger, and phaser at the same time, so I started setting up my default template with parallel modulation. The only time I hit the wall now is with 4 ultrares cabs loaded, alongside a couple of the ridiculously hungry delays, a pitch block and verb.

 

[unix-guy]

Dedicated cores aren't necessarily superior to spreading the workload across cores according to load. I'd guess the delay and reverb cores get CPU bound pretty quick while the amp modeling core could be humming along at 50% utilization - especially for single amp block patches.

So one optimization technique is schedule threads for execution to the core with the least utilization. There are plenty of OSes and real time systems that do exactly this. But I did not know Fractal took a dedicated core approach. So that would probably take a major rewrite.

This isn't a generic OS nor typical processing requirements, though

Cliff has posted before on the topic of parallel operations and from what I recall, I think many types of realtime DSP operations are not suited for that.

He's a really smart guy and I trust he's already explored these ideas before the FM9 was even released.

 

[Greg Ferguson]

I used to write code for a living. I'm sure the fractal folks can see under the hood so they probably know where and why they get CPU bound.

A large number of us did, or still do.

You might enjoy reading the Tech Notes, then Cliff’s comments in the Wiki.

 

[Rex Rox]

Thanks! I started going through the tech notes this morning. I haven't seen anything in there on this topic yet. I went thru most of the wiki when I got my FM9 (~month ago) and there's a lot of good info in there but I don't recall seeing anything about that. I obviously missed the dedicated core thing someplace so maybe there is something about the difficulty with parallel dsp code in the wiki.

I am very curious. I used to work for Intel. One of the things I worked on was writing code for their video capture boards. Those boards used dual processors for dsp. Parallel processing of the io stream was critical for us not to get both processor and io bound quickly. We used a round robin approach for execution scheduling on the 2 DSPs which worked great back then. The tricky part was the cache and memory access. It has to be done with SRAM and a field-programmable gate array not DRAM. That's how we solved it anyway. There's an overview on wikipedia I meant to post but being a newb I still can't post links yet. Anyone interested can find it by searching for "Parallel RAM" on wikipedia.

It is obvious Cliff and the Fractal folks know very well what they are doing. So for all I know they may have tried the same and found a better approach. If that is the case then optimizing CPU usage may not be much of an option beyond the stuff that can be done with new compiler optimizations that may come along. Intel made some optimizations available in their C compiler back in the day that gave us a huge boost in our code base. Here's hoping!

 

[Musiclover]

I used to work for Intel.

Would that be the Intel that got their ass handed to them by TSMC, and are now begging the government for some free money?

 

[Kelleys Heroes]

Would that be the Intel that got their ass handed to them by TSMC, and is now begging the government for some free money?

This thread could go in all sorts of directions, but just like with chips, there are limits.

 

[Rex Rox]

Would that be the Intel that got their ass handed to them by TSMC, and are now begging the government for some free money?

Yep same Intel - only would be more accurate to say they got their ass handed to them by AMD. When I worked for Intel they ruled both the CPU space and the video capture space. Best performance hands down on both fronts.

Fast forward to today and I have only been running AMD CPUs in both my workstations and my studio machines. I'm not even sure if Intel still makes video capture boards.

Except for what they just recently started manufacturing for Apple, TSMC doesn't really make high end desktop/workstation/server CPUs to my knowledge. The desktop/workstation/server CPU space is still ruled by AMD and Intel.

Also don't forget TSMC is getting some of that free government money to build a fab here too! No one really begged for it. With China drooling over repatriating Taiwan (which is mostly about swooping in to steal TSMC's technology), it would be really dumb of us not to invest in much more semiconductor production right here. Intel is only getting money to build a different kind of fab - one that would specialize in producing the more mundane variety of chips that are in everything (cars, appliances, etc.). Those are the kinds of chips that TSMC make the most. Intel does just fine meeting demand with their CPU fabs now. AMD just outclassed them on performance/price ratio in the last decade.

 

[clgnyc]

Bug encountered using new firmware: reamping in stereo over USB after about 45 mins of use. A paltry 54.9% CPU usage. Not touching the FM9 Edit or the hardware in any way. Spontaneous reboot of the hardware unit, LOUD pop noise (hurt my ears, even with volume down low).