FM3 GAP/SEAMLESS SWITCHING

magic

(But doesn't every block basically have 4 (or whatever number) channels? Even if you don't use the channel, it's still there)
 
XaviM said:
How come?
Click to expand...
Because that’s how the system is designed.

Memory use is likely not the issue, it’s possibly CPU, and reducing channels would save just a little memory. Cliff said he thought it would make it to the FM units, but he didn’t say when. We’re already testing it on the FM9 in private beta, so we know it’s in process.

Besides, removing channels has serious downsides: it would touch how scenes and presets work and are defined, and that would break every existing preset in your system, including the factory presets, plus any backed-up presets, plus the 3rd party presets and presets for the current generation products in Axe-Change. And that is when Fractal would see torches and pitchforks outside their office.
 
hole said:
magic

(But doesn't every block basically have 4 (or whatever number) channels? Even if you don't use the channel, it's still there)
Click to expand...
Yep.

Pre-allocating memory helps when processing speed is needed because the system then knows there are four chunks to read and grabs that many bytes and splits it into what it needs. The code has it all predefined after compilation.

Not pre-allocating and pre-defining means the code starts reading at the beginning of the block and searches for an indicator of the end of the channel’s information, or has to at least read a length byte saying grab n channel-chunks of memory. And it would have to happen for every preset, they’d have to be read sequentially through the system’s memory if channels were allowed to be up-to four. Or there’d have to be additional code that keeps track of where every preset begins in memory, which would eat into the saved memory space….

Speed is extremely important for this type of system, and knowing ahead of time how many bytes it needs to read is a good way to get there.
 
Greg Ferguson said:
Yep.

Pre-allocating memory helps when processing speed is needed because the system then knows there are four chunks to read and grabs that many bytes and splits it into what it needs. The code has it all predefined after compilation.

Not pre-allocating and pre-defining means the code starts reading at the beginning of the block and searches for an indicator of the end of the channel’s information, or has to at least read a length byte saying grab n channel-chunks of memory. And it would have to happen for every preset, they’d have to be read sequentially through the system’s memory if channels were allowed to be up-to four. Or there’d have to be additional code that keeps track of where every preset begins in memory, which would eat into the saved memory space….

Speed is extremely important for this type of system, and knowing ahead of time how many bytes it needs to read is a good way to get there.
Click to expand...

I think this is what they are doing. IIRC channel gaps persist due to muting the block in order to load the new set of parameters into the model. If they are able to set aside some extra memory to load all the parameters to the block when the preset loaded then the channel switching speed would likely be increased. I know this is greatly simplified (and potentially very incorrect), but any one who does any level of coding...think about the time required to read data from a source as needed vs scenario where you know the data you need and can preload it into memory to access as needed.
 
Will Chen said:
I think this is what they are doing. […]
Click to expand...
Knowing the language they're using gives us some hints; IIRC, it's C++ and C loves structs, and it's really easy to tell it to iterate/grab/skip over big blocks of that particular struct-sized memory quickly and then grab the individual components/members that are also known sizes from that block. It's crazy flexible that way. I've always considered programming languages as if I was digging a swimming pool, what tool would I want, a spoon, a garden trowel, a shovel or a backhoe. C/C++ is all those things.

Will Chen said:
I know this is greatly simplified (and potentially very incorrect)
Click to expand...
I think you got it figured out. :)
 
Admin M@ said:
Just a note that we're still working on this. Some of our staff has been out of work with persistent seasonal illnesses.
Click to expand...

I saw that the FM9 firmware with gapless switching and several new updates was beta released today. That’s awesome! Can we get excited already about an imminent FM3 firmware release with gapless as well? That would be more than awesome! :)
 
Last edited:
you can try to extrapolate the time between the fxIII and the fm9 firmware release posts and give us the results for the remaining waiting time for the fm3 release :)
 
As an FM3 user since July 2022, I'm absolutely smitten with the unit. YAY! if gapless comes to it, YAY! if it doesn't, but well, the former please, rather than the latter. but hey, please guys, take your time, nail it (as you always do) before beta releasing. I'll just sit here in my studio and marvel at what I already have.
 
stephanfm3 said:
you can try to extrapolate the time between the fxIII and the fm9 firmware release posts and give us the results for the remaining waiting time for the fm3 release :)
Click to expand...
How do you mean? The FM3 is worked on separately. It's not like the FM3 team is having a lovely vacation in the tropics while others work on the FM9. I'm sure they're constantly working on porting features over as Cliff comes up with them for the Axe-Fx III.
 
You must log in or register to reply here.
Back
Top Bottom