RAVENFORGE

SPECTRALFORGE / BENCH NOTES / BN02

SpectralForge Chimera Development Log Part 2

Revisiting the design criteria while expanding original amp and cabinet modeling

October 12, 2026 · Record covers September 23–October 12, 2026

Figure 1. Matrix view of the Crom Cruach preset, showing the amps and cabinets for the LOW, MID and HIGH rigs. Actual Linux native UI component capture from Chimera 1.3.1-beta.1. ^[12]

The first development log documented the work of implementing Classic, Dual, and Matrix as distinct signal structures. It established the roles of a single rig, two parallel rigs, and a rig split into three frequency bands, then made those differences legible in the interface. It ended with the tasks of expanding the actual PRE and POST chains and amp and cabinet voicings, and establishing repeatable conditions for comparison. ^[1]

Since then, Chimera has gained original guitar and bass amps alongside cabinet and microphone models, reaching the 1.3.1 public beta. This entry focuses on the design decisions that changed along the way. Giving each channel a distinct response, adding distortion while preserving the bass foundation, and aligning the sound controls with the actual audio processing all became concrete development problems. ^[7]

1 Defaults that are ready to use when an amp is selected

As the PRE and POST effects and preset library expanded, the starting point for building a working rig became more important. If a high-gain amp opens with too little gain, or changing presets produces a large jump in loudness, the user has to correct the setup before comparing the character of the sounds. Default settings therefore had to become part of the product's voicing design.

For 1.1.2, I remeasured saturation and compression under low input levels and adjusted the high-gain defaults. The comparison set comprised 174 NAMs across 22 model families. References were rendered with the official NAM Core and compared against the responses of Chimera's native amps. ^[2]

I also defined the limits of those references. Even within the same amp family, a capture means something different depending on the channel, modifications, and whether it represents the preamp output or the complete amp output. I separated the aspects that could be calibrated using the available material from those that needed to remain unresolved because an exact reference was unavailable. This work did not turn Chimera's engine into a NAM playback engine. ^[2]

The principle established at this stage was to match the comparison conditions first. When input or output levels differ, the louder sound can easily be perceived as the better sound. Gain structure and default loudness need to be checked with repeatable inputs, then validated by playing real instruments.

2 The criteria behind the Náströnd and Niflheimr channels

For the original amps, there needed to be a clear reason to change channels. Náströnd was developed to distinguish its five channels by picking response, compression, low-mid density, and decay character. Taking Fenrir's fast, firm response as the reference, I adjusted the internal distribution of drive and the frequency response so the other channels could express lead-focused mids, rough grind, slow recovery, and a deep sense of impact. ^[3]

Initially, the channels were not sufficiently distinct, Fenrir sounded louder, and Fimbulvetr sounded muffled. With Fenrir left intact, I corrected the levels of the other channels and reduced Fimbulvetr's low-mid emphasis before distortion and its high-frequency attenuation. The aim was to make the attack legible while retaining the slow recovery. This work also established the rule of setting preset OUTPUT to 0 dB. That is the reference setting of the output control; it does not mean normalizing the signal to 0 dBFS. ^[3]

Figure 2. Náströnd with Fenrir selected in the enlarged front-panel view. The five channel selectors and live runtime knobs and labels are visible. Actual Linux native UI component capture from 1.3.1-beta.1. ^[13]

For the bass amp Niflheimr, a central problem was excessive low-frequency energy driving the distortion stages and detectors hard enough to blur the upper bands as well. Restoring the lows after generating distortion could not undo the interaction between frequency bands that had already occurred. I therefore separated the path that preserves the low end from the BODY and EDGE paths that create texture, and conditioned the signal before it entered the distortion stages. ^[4]

The existing responses of Hrímfaxi and Nidavellir were preserved, while Garmr, Ymir, and Hel were revised in response to reports of muddiness. This did not mean turning Hel's slow, thick response into that of a fast channel. The scope of the revision was to improve note definition while preserving each channel's role. ^[4]

Figure 3. Niflheimr with Hrímfaxi selected in the enlarged front-panel view. The front-panel controls, including BLEND, are part of the product UI. Actual Linux native UI component capture from 1.3.1-beta.1. ^[13]

Niflheimr's BLEND also needs to be understood within this structure. It mixes a conditioned CLEAN path with the distorted path; it is not equivalent to the amount of unprocessed DI bypassing the amp. Its position and function also differ from the separate DI/AMP mix in Matrix LOW. ^[4]

3 Structural limits identified during NAM training

There are two strands of NAM-related development. The comparison with external NAMs described earlier is used to calibrate the native amps. The separate Náströnd NAM project captures the original engine already built, then trains five NAMs to reproduce its responses for export. ^[2] [5]

The additional training experiment on October 11 compared ESR, the ratio of error energy to reference signal energy. Mean ESR on the new test inputs fell from 0.099505 to 0.088075, an 11.49% reduction in error. However, all five channels still fell short of the full fidelity criteria. Successful file export and reconstruction in the target engine did not, by themselves, establish that the sound had been reproduced faithfully enough. ^[5]

Figure 4. Mean ESR before and after additional Náströnd A2 training, averaged over five channels on new test inputs. ESR is error energy divided by reference-signal energy. The 11.49% figure is an error reduction, not similarity or a fidelity pass rate. All five channels still fail the full fidelity criteria. ^[5]

Fimbulvetr also revealed a region that could not be resolved simply by spending more time on training. In a particular decay segment, all of the input history accessible to A2, the NAM model architecture used in this experiment, had already become zero, while the original engine's decay continued. For that input and the fixed evaluation conditions, the current A2 architecture with its finite memory length could not meet the required criterion. ^[5]

The next experiments therefore need to consider architectures with longer memory or approaches incorporating recursive filters. This conclusion cannot be generalized to every channel and every input. It does, however, establish a clear limit to the assumption that the current five-channel set can pass simply through more training iterations. Public release of the trained models and listening assessment with real instruments remain pending. ^[5]

4 Combining cabinets and microphones directly

The cabinet work aimed to give users direct control over speaker and microphone selection and microphone placement. Alongside the IR loader, where the user selects a file, I expanded the native CAB path so changes inside the cabinet could be understood through both the interface and the sound.

The current model defines speaker resonance and damping, high-frequency response, microphone frequency characteristics, and proximity effect separately. Mic A and Mic B can use different microphones and point at the same driver or at different drivers. Position and distance feed into the actual response calculation. The two-microphone placement interface and the DSP thus refer to the same objects. ^[6]

I also revised cabinet proportions and driver layouts. Adopting a 6×10 configuration and fixing the supported driver diameters for each cabinet resolved inconsistencies such as the cabinet enclosure itself growing when a different driver was selected. A common scale for heads and cabinets, the appearance of front-facing drivers, and the rendering of horns and exterior materials all mattered to understanding selection and interaction. ^[11]

Figure 5. Conceptual example of Mic A and Mic B targeting different drivers in a 6×10 cabinet; both can also target the same driver. The diagram explains independent microphone, driver, position and distance choices. It is not an actual UI or a measured dimensional or response drawing. Room acoustics remain future work. ^[6] [11]

This implementation is a linear reduced-order model based on authored numerical assumptions. It should not be read as a complete replica of a particular measured cabinet or as a model that includes speaker thermal compression. The rooms in Dual and Matrix currently provide a space for arranging equipment and opening its detail view. Room acoustics that calculate reflections and reverberation remain part of future development. ^[6] [10]

The IR loader retains its own role. An imported IR is a record whose microphone conditions are already fixed, so it cannot be remiked in the way that moving a microphone in the native CAB interface changes the model. The interface is responsible for making it clear which path the user is adjusting. ^[6]

5 Adjusting the sound from the amp's front panel

As the amp-head images became more concrete, inconsistencies in the controls also became apparent. A head could look three-dimensional while its knobs appeared flat and detached, or knob sizes and spacing could vary across models in ways that made them difficult to read. The top corners, handles, and sense of depth also needed revision. ^[7]

Version 1.3.1 introduced a workflow in Classic, Dual, and Matrix for selecting a head, enlarging it, and adjusting its front-panel knobs directly. Knob shapes and material appearance were matched to each model, label contrast was adjusted, and numeric values were made visible during interaction or direct entry. Essential controls sit on the front panel, with a route into the detailed controls. ^[7]

Signal Path currently shows where the signal branches and rejoins and provides navigation to the relevant editor. However, depicting the route in detail also leaves utilities such as Gate and Transpose too prominent in the default view. A later revision is planned to reduce display density, emphasizing the main editing stages while allowing the detailed path to be expanded. ^[7] [10]

This follows the same issue identified in Part 1. Even when the implementation reuses many internal modules, the interface should be organized around the tasks the user needs to understand. The criteria are whether the mode differences, the equipment currently being adjusted, and the next place to go can be understood naturally. ^[1]

6 The EQ analyzer and editing workflow

Tone EQ and Final EQ each provide an independent 12-band bank, seven filter types, a response curve, and input and output spectra. The foundation for adjusting frequency, gain, and Q through the graph and numeric controls is implemented. The readability of the analyzer and the editing workflow in actual use, however, have not met expectations. ^[8]

The existing analyzer uses a 2048-point FFT and a fixed display range. At 48 kHz, the frequency-bin spacing is approximately 23.44 Hz. This limits the detail available in the low end, and drawing a smoother line does not improve the underlying resolution. The display also needs a time response that makes attack and decay legible, a clear distinction between input and output, and a visual hierarchy that keeps the EQ curve readable. ^[8]

The follow-up design includes a larger editing view for the selected EQ, analyzer resolution and temporal smoothing controls, Freeze and Peak Hold, adding and deleting bands, multiple selection and band audition, and Undo and Redo at the EQ level. These are improvement specifications and are not recorded here as completed features. ^[8]

Improving the analyzer also brings processing costs that need to be accounted for. Adjusting the analysis window's resolution and response speed must not add latency to the audio path. State used for display needs to remain distinct from the state that defines the saved sound, and the changes must preserve existing project parameters and automation. ^[8]

7 The numbers that matter for real-time processing

Real-time audio requires each audio block to finish before its next processing deadline. Even with low average CPU usage, an occasional long callback can cause problems during playing. I therefore recorded both whether the defined performance criteria passed and how many callbacks actually missed their deadlines.

In CAB measurements on the final 1.3.1 source, all three operating systems passed the p99 criteria for all 66 paths. The p99 is the 99th percentile of the processing-time distribution. On macOS, however, 54 of the 105,600 measured callbacks missed their individual deadlines. The values below are observations for that source and those CI environments. ^[7]

The maximum callback wall time on macOS was approximately 29.9 ms. Because a p99 criterion evaluates a defined point in the distribution, passing it does not mean that every rare delay has been eliminated. Interaction, state restoration, and shutdown still need to be validated separately on real hardware and in DAWs. ^[7]

Transpose has a different form of latency to address. Its algorithmic latency is approximately 46.4 ms at 44.1 kHz and 42.7 ms at 48 kHz, still above the target of 10 ms or less. Listening feedback that the body of the note and successive attacks become blurred when the bass B string is shifted down two semitones also remains an open issue. ^[9]

Figure 6. Transpose algorithmic latency at two sample rates and the target of 10 ms or less. These baseline values are distinct from total interface-and-DAW round-trip latency and from CAB callback execution time. Low-note quality and latency require joint reassessment. ^[9]

This problem requires evaluating low-register quality and latency together. Using the same DI, pitch, attack, and sustain need to be compared between the original and shifted signals, with the influence of Gate assessed separately. Reducing the FFT window merely to lower the reported latency must be supported by actual playing comparisons. DAW latency compensation also does not remove the waiting felt when playing through a live input. ^[9]

8 Weekly updates and a shared foundation for the next products

I also revised how I judge development pace. Pursuing several features and verification schedules over a short period made it necessary to reconsider the scope of each update. The intention is to deliver an actual improvement or maintenance result every week while managing each update's scope and verification conditions more explicitly. ^[10]

The schedule needs targets for test builds and public releases, with the next scope adjusted when work slips. Throughout that process, the principle is to keep incomplete verification and remaining problems visible rather than relabeling them as passes. ^[10]

The plans for separate, streamlined Náströnd and Niflheimr plug-ins start from the same criteria. They will share the existing engines, with controls and effects selected for each product's playing purpose. Where additional DSP is needed, the intention is to develop it as shared modules that Chimera can also use. The separate products, NAM packs, and AAX support remain follow-up work, each requiring its own implementation and verification. ^[10]

For guitar PRE, the current priority is a booster that shapes the low end, attack, and input level before the amp. TRIAX is the closest reference for this role. Once the required behavior is defined, I will assess which parts can be covered by the existing engine and which need new development.

The next development entry should be able to document the results of editing and playing through the improved EQ, the comparison inputs for low-register Transpose, and the experiments with alternative NAM architectures. I intend to carry this record forward through the conditions used to reassess the limits identified here in the next build.

Evidence and current assessment

Next research and verification conditions

EQ: Compare low-frequency readability, editing actions and analyzer time response between the existing and revised views using the same input. Check audio-path latency and compatibility with existing automation. ^[8]

Transpose: Fix the comparison DI and settings for lowering the bass B string by two semitones. Separate the Gate's influence and record pitch, attacks, sustain and algorithmic latency. ^[9]

NAM: Compare longer input histories and alternatives involving recursive filters using the same test inputs and criteria. Report export and restoration success separately from fidelity acceptance. ^[5]

Sources and development records

Read implementation and measurement records at their linked source revisions. UI figures document layout and controls; they do not replace performance measurements. The new infographics reproduce recorded values or explicitly identified concepts. The roadmap and EQ specifications describe follow-up plans as of 12 October 2026.

[1] Chimera Amp Matrix Development Log Vol. 1

[2] 1.1.2 public beta and the scope of native amp calibration

[3] Náströnd channel character, level, and clarity revisions

[4] Niflheimr native implementation and low-end clarity revisions

[5] Náströnd A2 additional training and structural limits report, October 11, 2026

[6] Expanded CAB speaker and microphone models

[7] 1.3.1 public beta features and real-time performance observations

[8] EQ analyzer and editing workflow improvement specification

[9] Long-term Transpose improvements and latency criteria

[10] Development roadmap, October 2026–December 2027

[11] Cabinet layouts and driver-diameter compatibility rules

[12] Native Matrix UI capture provenance for beta 1.3.1

[13] Native amp-head UI capture provenance for beta 1.3.1