[FEATURE] Metadata: Settings used in profile

[vvasilikos]

I think this is a general topic, probably spanning multiple future & existing issues.

Also, it's probably something for the medium-to-long term future :D

(Some) related pre-existing issues: https://github.com/sdatkinson/neural-amp-modeler/issues/176 https://github.com/sdatkinson/neural-amp-modeler/issues/140 https://github.com/sdatkinson/neural-amp-modeler/issues/188 https://github.com/scottcorgan/tonehunt/issues/161

My thought here, aside from improving the user available features and overall experience, is to somehow "future proof" the current state as much as possible, in a similar way Kemper (apparently) did and were able to adapt their tech to this "Liquid Profiling" variant. Some useful insights from Christoph Kemper himself:

https://www.youtube.com/watch?v=IL6l0fR5PYw

So the idea here is that somehow the particular settings of a certain profile are stored and embedded in the JSON of the NAM file.

Now, I know that there's a myriad of different pieces of equipment out there with such a diverse set of controls, so I am not sure how viable something like this would be even to just make sure it's documented correctly. I'm thinking something in terms of generic objects, like "knob", "slider", "switch", etc, that could have any multiplicity within the model, and any value between 0.0 and 1.0 or something similar. The raw type is float with values 0.0 and 1.0 anyway, the physical type would only (probably) be useful for display purposes (see below).

If such information was preserved, there is strong potential for future upgrades:

• UX : You could display the settings in the GUI as static elements, just as a reference
• UX: If, in the future, the skin is loaded dynamically, you could even have a dynamic picture of the real amp/pedal face with the controls set accordingly.
• Tone: If, at some point, it becomes somehow possible to sweep through certain controls, knowing where the particular model was captured at as a starting point would be essential.

Regarding that last point: One thought that I had is to "auto-blend" multiple profiles of the same gear, if you have them from the same group, as suggested in issue #188 .

You could create an N-dimensional space and place each profile on that space depending on its initial metadata about the gear settings. N would (ideally) be the amount of independent controls available on the gear, but in practice you only need as many dimensions as you have varying controls (eg if you have a group of 10 profiles where only the Gain changes, you only need a 1-dimensional space, even if the actual gear has 20+ controls).

The user could set a target point in that space (by sweeping eg the Gain control), and the plugin would blend the "nearest"/"most relevant" real data points to produce something close to the desired output, kind of like what the Libra IR loader does with its Cartesian mixer:

For that IR mixer to work as intended of course, the IRs have to be phase aligned -- The same way that in our case the profiles have to be from the same "group" (basically the same gear, levels during training, or whatever other constraints prove to be necessary for this). You could of course give the user the option to disregard this and blend whatever they want, the blend function in general I think is heavily requested, so if it's implemented, it could be expanded to support this concept as well.

[vvasilikos]

Here's another interesting take on the 2D blend concept:

https://www.bluecataudio.com/Blog/tip-of-the-day/tone-maps-a-new-approach-to-sound-design-and-tone-control/

[sdatkinson]

there's a myriad of different pieces of equipment out there with such a diverse set of controls, so I am not sure how viable something like this would be even to just make sure it's documented correctly

This is one hey hurdle. I'd rather not have it than have it done poorly.

[vvasilikos]

there's a myriad of different pieces of equipment out there with such a diverse set of controls, so I am not sure how viable something like this would be even to just make sure it's documented correctly

This is one hey hurdle. I'd rather not have it than have it done poorly.

I had an idea that might help with this:

What if this risk is delegated to the profile creator in a way that enforces consistency?

There could be a 2nd file format for these "super packs" (maybe .snam ? :D) that would require the profile creator to go through a step-by-step process of declaring all the controls that will be captured at different settings, and then to correctly assign each capture (resulting nam file?) to the entire configuration space correctly, and only then you could have a valid .snam file.

[fewtubefx]

I wonder if it is possible to make a base with analyzed profiles, maybe something like DNA, only in guitar amplification, based on the parameters that were laid down in NAM. Then it was possible to look at the “origin” of the amplifier and select similar profiles based on these parameters.