Not a Bug Presets with the same name can't be assigned to different colors

jordikt

jordikt

Experienced
  • I have 2 presets with the same name. The name is "--"
  • In FM3-Edit, preset picker window, I set the first preset "--" to the red color.
  • Then the second preset "--" is also assigned to red color.
  • If I set the second preset "--" to yellow color, then the first preset "--" is changed to yellow also.

So, the bug is that all the presets that are sharing the same name can not be assigned to different colors.

In the previous versions of FM3 Edit, this was possible.
 
jordikt said:
  • I have 2 presets with the same name. The name is "--"
  • In FM3-Edit, preset picker window, I set the first preset "--" to the red color.
  • Then the second preset "--" is also assigned to red color.
  • If I set the second preset "--" to yellow color, then the first preset "--" is changed to yellow also.

So, the bug is that all the presets that are sharing the same name can not be assigned to different colors.

In the previous versions of FM3 Edit, this was possible.
Click to expand...
Preset Coloring is based on the preset name not its location.
 
Personally, I'd really like to see this behavior changed. If we copy a factory preset, or inadvertently duplicate a name, it's annoying that all instances of that name are forced to use the same color.

I have some tweaked versions of a factory preset, and, in case I need to look at the factory version I kept the name to make it easy to search for the original, but I have my presets coded with a specific color so I can quickly isolate them and factory presets end up being filtered into the results.

I think presets should either be forced to have unique names, or an additional constraint be considered when coloring presets, such as the slot number.
 
Michael Pickens said:
Preset Coloring is based on the preset name not its location.
Click to expand...

I think it's correct that color has to be based on the preset name. If you move the preset from number 1 to number 127, the color doesn't change. That's good.

I am not saying that the bug is related to the location.

The bug is related to the name when 2 or more presets are sharing the same name.

Don't you think that's a bug?
 
The color is a property of the preset. Renaming it or moving it shouldn't change the color of the preset. This probably explains why my color assignments sometimes inexplicably disappear.
 
GlennO said:
The color is a property of the preset. Renaming it or moving it shouldn't change the color of the preset. This probably explains why my color assignments sometimes inexplicably disappear.
Click to expand...
The color is tied to the preset, but it's actually in a file called "color-assignments*.dat" stored in the editor's folder on disk.

Using a sidecar file is used in other applications and it's the same liability with them also; If you back up your preset, then lose that file containing the assignments, say because the drive crashed and it wasn't backed up, then restore the preset, it's back to "None", as will all the other presets be that you colored. While that's not as critical as losing the preset entirely, it's annoying that we get unexpected behavior undoing our explicit actions. I think it could be smarter.
 
jordikt said:
I think it's correct that color has to be based on the preset name. If you move the preset from number 1 to number 127, the color doesn't change. That's good.
Click to expand...
The editor knows when we're moving the preset, so it can change its key/pointer of location + name to reflect the new slot. By doing that it'd have a unique key always.

Probably this problem occurs because the modeler doesn't know anything about colors, just names, so we can move presets around and the editor can find the presets with that name and continue coloring them correctly. The editor is somewhat constrained by the interface and features on the modeler. If we could color code presets on the modeler we'd probably see a more robust and intelligent system for the same in the editor, except that the color information would have to be embedded into the preset and files when they're backed-up....

It's probably one of those "If you give a mouse a cookie..." situations and won't get changed.
 
Greg Ferguson said:
Using a sidecar file is used in other applications and it's the same liability with them also; If you back up your preset, then lose that file containing the assignments, say because the drive crashed and it wasn't backed up, then restore the preset, it's back to "None", as will all the other presets be that you colored. While that's not as critical as losing the preset entirely, it's annoying that we get unexpected behavior undoing our explicit actions. I think it could be smarter.
Click to expand...
The color is a property of the preset, just like the preset name, and should be stored in the preset. If you look in an Omnisphere preset, you'll find properties that are there only for display use in the browser, for example the star rating or the notes or the search tags. By putting them in the preset, you avoid unfortunate surprises like the one this thread is about.
 
GlennO said:
The color is a property of the preset, just like the preset name, and should be stored in the preset. If you look in an Omnisphere preset, you'll find properties that are there only for display use in the browser, for example the star rating or the notes or the search tags. By putting them in the preset, you avoid unfortunate surprises like the one this thread is about.
Click to expand...
Agreed, but the preset looks like it's a MIDI dump of the actual settings so they'd need to change that format and make a change to the firmware so it didn't complain or break. And then when a preset was distributed containing that designator, it'd break other people's modelers that don't have the updated firmware. At least that's what I suspect keeps them from doing something like embedding the information in a preset.
 
There's nothing new about that. That's true of almost all FAS firmware updates. There has never been version compatibility in FAS firmware. You can't take a preset from one version and load it into an earlier firmware version. Saving the color in the preset wouldn't change anything about that policy.
 
GlennO said:
There has never been version compatibility in FAS firmware. You can't take a preset from one version and load it into an earlier firmware version. Saving the color in the preset wouldn't change anything about that policy.
Click to expand...
I agree with that.

FAS can change the color features whenever they want (if they decide that is a good improvement).

Also it would be very practical to edit the name of the colors, and increase the qty of them. I would like to read "Clean" and not "Yellow" at the side of the yellow color, for example.

I posted a big wish asking for these things and also for more complex things, all related with coloring. Probably all the wish is difficult to implement, but editing colors and the addition of 2 or 3 colors to the current list would be very practical for all users.
 
Personally, I find the use of colors for sorting/filtering to be limiting and would prefer to see an ability to filter by attributes in the preset, like the block types, the device types inside the settings, etc. It'd take even more work, but would make it possible to quickly sift through factory and our own presets to find things that match parameters we select.
 
GlennO said:
https://forum.fractalaudio.com/thre...-presets-irs-and-blocks-and-set-lists.162038/
Click to expand...
+1 and agreed.

Interface is where modelers will differentiate themselves, and I can imagine a point where the modelers will be headless black boxes with Bluetooth connections to the editors that live on phones, tablets or computers. Being able to control them from a front panel is only going to be for emergencies, then will be gone entirely as the interface and software matures.
 
GlennO said:
The color is a property of the preset, just like the preset name, and should be stored in the preset. If you look in an Omnisphere preset, you'll find properties that are there only for display use in the browser, for example the star rating or the notes or the search tags. By putting them in the preset, you avoid unfortunate surprises like the one this thread is about.
Click to expand...

But if I download a preset from another user, I have no use for the color which was assigned by the other user. I have no issue with colors remaining as it is: simple.
 
yek said:
But if I download a preset from another user, I have no use for the color which was assigned by the other user. I have no issue with colors remaining as it is: simple.
Click to expand...

After downloading a preset from another user, it's usual to change the name, modify some parameters according to your enviroment, pedalboard, etc. Of course it would be also normal to change the color attributes of the downloaded preset.

I agree that coloring options in FM3 now is simple, but maybe too much.... :)
 
yek said:
But if I download a preset from another user, I have no use for the color which was assigned by the other user.
Click to expand...

That's right. That's why when you import a preset, certain fields that don't make sense in your local context should be cleared.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom