Wish Firmware version numbering synchronization across all Gen 3 units

Moke

Axe-Master
Vendor
This wish would technically affect all three Gen 3 units, but didn't want to clutter up three threads.


Determining whether or not the different Gen 3 platform firmware versions are in sync is just way too difficult IMHO.

Preset sharing across platforms, free or commercial, is just so complicated.

I would have loved it if when the FM units were introduced, their Axe-Fx III based firmware versions would have used the same version number that they were based on. And kept the matching version numbers from then on. If the firmware versions are in sync, the version numbers should be too.

At the next alignment of the firmware versions of the FM units to the Axe-Fx III, It would be so nice if their firmware version names/numbers would also align.

In the past, when a completely new modeling algorithm was introduced (Quantum, Ares, etc..), the firmware numbering system sometimes was restarted. Maybe the next Cygnus X3, Pegasus, or whatever would be a good time to start over on all three units and get them sync'd up. 'Pegasus 1.00'

After that point...
  1. Minor changes (bug fixes) that leave the units otherwise compatible would show a change in the hundredths decimal.
  2. Something more significant like added models, or functions (but existing preset are unchanged and still compatible?) would show a change in the tenths decimal. If this renders them incompatible, so be it. We would just have to understand that only differences in the hundredths decimal are compatible.
  3. Any major changes to the modeling algorithms or any changes that could alter any existing preset and otherwise make it not compatible, would show a change in the actual firmware version number.
Let the bickering begin.. LOL

Thanks, Moke
 
Last edited:
This wish would technically affect all three Gen 3 units, but didn't want to clutter up three threads.


Determining whether or not the different Gen 3 platform firmware versions are in sync is just way too difficult IMHO.

Preset sharing across platforms, free or commercial, is just so complicated.

I would have loved it if when the FM units were introduced, their Axe-Fx III based firmware versions would have used the same version number that they were based on. And kept the matching version numbers from then on. If the firmware versions are in sync, the version numbers should be too.

At the next alignment of the firmware versions of the FM units to the Axe-Fx III, It would be so nice if their firmware version names/numbers would also align.

In the past, when a completely new modeling algorithm was introduced (Quantum, Ares, etc..), the firmware numbering system sometimes was restarted. Maybe the next Cygnus X3, Pegasus, or whatever would be a good time to start over on all three units and get them sync'd up. 'Pegasus 1.00'

After that point...
  1. Minor changes (bug fixes) that leave the units otherwise compatible would show a change in the hundredths decimal.
  2. Something more significant like added models, or functions (but existing preset are unchanged and still compatible?) would show a change in the tenths decimal. If this renders them incompatible, so be it. We would just have to understand that only differences in the hundredths decimal are compatible.
  3. Any major changes to the modeling algorithms or any changes that could alter any existing preset and otherwise make it not compatible, would show a change in the actual firmware version number.
Let the bickering begin.. LOL

Thanks, Moke
I made the same request some years ago.
Definitely +1 !!!
 
Pegasus, or whatever
That sounds good!
pegasus-01.jpg
 
I wholeheartedly agree with the same numbering but I think for those with multiple different devices it would also help to have clear understanding of what may not be included on a certain model due to hardware limitations. For example, if it's not feasible to put a the cpu intensive effect in the fm3, people should know which effects may be stripped down.
I mentioned a versioning format in the other thread denoting version1a for ax3, 1b, for fm9 and 1c for fm3 with a notes page describing what's not included between the versions. It, of course, doesn't have to be a letter format. I just need to know what the differences are between common versions on different devices. Problems can arise, when using an fm9 preset on an fm3 if the effect is not available.
 
This is, and will always be the case. And is somewhat(?) common knowledge. You can't put 10 lbs. of potatoes in a 5 lb. sack.

But the extra complexity of mismatching firmware versions without a clear way to identify them for compatibility further exacerbates it.
 
I wholeheartedly agree with the same numbering but I think for those with multiple different devices it would also help to have clear understanding of what may not be included on a certain model due to hardware limitations. For example, if it's not feasible to put a the cpu intensive effect in the fm3, people should know which effects may be stripped down.
I mentioned a versioning format in the other thread denoting version1a for ax3, 1b, for fm9 and 1c for fm3 with a notes page describing what's not included between the versions. It, of course, doesn't have to be a letter format. I just need to know what the differences are between common versions on different devices. Problems can arise, when using an fm9 preset on an fm3 if the effect is not available.

I agree with @Moke, the version number should only indicate firmware compatibility.

While I understand the appeal, version numbers are not really relevant to the differences in hardware between the units. Tables exist showing what blocks are available on each unit, and the hardware differences are documented. People moving presets between the hardware have to check those sources. The release notes document what has changed in a particular release for a particular model, so if people read the notes they will be clued in, and they are listed in the Wiki for later referencing.
 
The release notes document what has changed in a particular release for a particular model, so if people read the notes they will be clued in, and they are listed in the Wiki for later referencing.
And if you open the current release notes, you’ll find all the release notes right there in the same file, all the way back to product release.
 
  1. Minor changes (bug fixes) that leave the units otherwise compatible would show a change in the hundredths decimal.
  2. Something more significant like added models, or functions (but existing preset are unchanged and still compatible?) would show a change in the tenths decimal. If this renders them incompatible, so be it. We would just have to understand that only differences in the hundredths decimal are compatible.
  3. Any major changes to the modeling algorithms or any changes that could alter any existing preset and otherwise make it not compatible, would show a change in the actual firmware version number.

This guy SemVers 😎

This is how most of the open source software development world uses version numbers.

Strong +1, however it would be best to use two decimals to denote the change. Pegasus 1.00 would instead 1.0.0. A bugfix becomes 1.0.1, these move independently across hardware. A new feature is 1.1.0, resetting the micro version. A major change that breaks compatibility with old settings increments the first digit.

A typical semantic versioning timeline looks like this:
1.0.0 - initial release
1.0.1 - bugfix, micro version increments
1.0.2 bugfix, micro version increments
1.1.0 - new feature introduced, minor increments and micro resets
1.1.1 - bugfix again
1.2.0 - new feature again
2.0.0 - breaking change! Major version increments, minor and micro reset.

Read the spec at semver DOT org (the forums not letting me add a link in my comment for some reason, maybe a spam protection thing?)

SemVer is usually used by people who share code to indicate the safety/effort level of installing the new version. When someone released multiple related projects, they’ll often synchronize major version to show how they are related, eg “Make sure that if you use LibraryExtension 3.0.0 that you also use LibraryCore 3.0.0.” FAS firmware could potentially have the same relationship across models. A problem would arise if the three completely deviate but I guess that’s where the “Cygnus” piece comes in, as Cygnus 3.0.0 and Pegasus 3.0.0 would have no expectation of compatibility.
 
Last edited:
A problem would arise if the three completely deviate but I guess that’s where the “Cygnus” piece comes in, as Cygnus 3.0.0 and Pegasus 3.0.0 would have no expectation of compatibility.
Fractal keeps the firmware across the units as closely aligned as possible. It's a good strategy; There are some delays synchronizing new features because the smaller units are different CPUs from a different manufacturer and sometimes the code needs to be hand-tuned, but it's pretty amazing what they can get the FM3 to do in order to keep up with the bigger siblings.
 
Back
Top Bottom