Preset files change when no parameters have been changed

[Dave Merrill]

It's a proprietary file format. The only right or wrong is what Fractal Audio decides. Us randos on the internet don't dictate correctness here.

Of course.

I trust you get my point though

 

[ElectricPhase]

This is happening because there is an unused word that has random data in it (copied from an automatic struct). This causes the CRC to change although the actual patch doesn't change.

It never occurred to me that someone would be OCD enough that this would matter. Lesson learned.

I regularly use duplicate finding programs to sweep for accidental duplicate files. It's not a big deal, but I understand the desire to use a tool for cleanup....

 

[alexjplant]

This is happening because there is an unused word that has random data in it (copied from an automatic struct). This causes the CRC to change although the actual patch doesn't change.

It never occurred to me that someone would be OCD enough that this would matter. Lesson learned.

If you had written the firmware in Rust this wouldn't have happened!

ducks to avoid airborne stapler

**EDIT: Before anybody takes this the wrong way it's a multi-faceted joke at the expense of Rust zealotry, C's power and lack of memory safety, the state of static checking tools, the extent to which undefined behavior gets relied upon in the real world, etc etc. It is meant in jest.

 

[flying_walrus]

If you had written the firmware in Rust this wouldn't have happened!

ducks to avoid airborne stapler

**EDIT: Before anybody takes this the wrong way it's a multi-faceted joke at the expense of Rust zealotry, C's power and lack of memory safety, the state of static checking tools, the extent to which undefined behavior gets relied upon in the real world, etc etc. It is meant in jest.

hmm. lack of memory safety, or requirement that programmers know how to manage memory? ducks

 

[alexjplant]

hmm. lack of memory safety, or requirement that programmers know how to manage memory? ducks

Those two aren't mutually exclusive. C's lack of memory safety makes it a poorer choice than many of its contemporaries for many applications. This isn't the 70s and not everything is running in a real-time memory-constrained environment.

 

[flying_walrus]

Those two aren't mutually exclusive. C's lack of memory safety makes it a poorer choice than many of its contemporaries for many applications. This isn't the 70s and not everything is running in a real-time memory-constrained environment.

i agree with the first sentence, but the amount of cruft that tends to come with memory safe languages, and the number of modern programmers who don’t understand what the hardware is doing is concerning

 

[alexjplant]

but the amount of cruft that tends to come with memory safe languages

Some are better than others but yes, the most pervasive memory-managed languages in use today are pretty bad in this regard (Java and Python). Depending upon which runtime you're using .NET is pretty great and Go gets lots of love as well.

, and the number of modern programmers who don’t understand what the hardware is doing is concerning

Very true. Simply minimizing variable scope and lifetime to let the compiler (and to a lesser extent runtime/GC) do its job seems to be a concept lost upon many contemporary devs, not to mention the data structures underpinning the default libraries' collections framework, how ORMs actually do lazy loading/deferred execution, occasionally-necessary bitbanging, primitive vs boxed data types, virtual tables... the list goes on and on.

 

[Zedhed]

Reading you 'code guys' posts give me the giggles. I don't understand any of it and yet I find myself reading it and getting a buzz. I'm sure there's subliminal messages in there to get people high!

Carry on y'all