Code Review: ISpectrogramControl

This is a substantial and well-designed addition to the IGraphics control library. The PR adds a spectrogram visualization control with colormap support. Overall, the implementation is solid, but I've identified several issues that should be addressed.

Critical Issues

1. Typo in Method Name ⚠️

RezizeBuffers() should be ResizeBuffers() throughout the codebase.

• Found at: ISpectrogramControl.h:65, 76, 80, 248, 256, 382

2. Potential Division by Zero

ISpectrogramControl.h:262

SetFreqRange(NyquistFreq()/mFFTSize, NyquistFreq());

If mFFTSize is 0, this will crash. While the assertions at lines 245-246 prevent this after initialization, consider validating in SetSampleRate() or adding a guard.

3. Missing Bounds Check

ISpectrogramControl.h:368

const float v1 = powerSpectrum[(bin0 + 1) & (numBins-1)];

The bitwise AND assumes numBins is a power of 2 for wrapping. However, numBins = mFFTSize / 2 is only a power of 2 if mFFTSize is a power of 4. For mFFTSize = 128 (allowed in menu), numBins = 64 works, but this should use proper bounds checking: std::min(bin0 + 1, numBins - 1).

4. Unsafe Type Conversion

ISpectrogramControl.h:128, 134

int fftSize = atoi(pSelectedMenu->GetChosenItem()->GetText());
int overlap = atoi(pSelectedMenu->GetChosenItem()->GetText());

atoi() is unsafe and returns 0 on failure without error indication. Use std::stoi() or std::from_chars() with proper error handling.

Code Quality Issues

5. IsDirty() Always Returns True

ISpectrogramControl.h:141-144

bool IsDirty() override
{
  return true;
}

This forces redraw every frame regardless of whether data changed. This is inefficient and should only return true when the spectrogram actually updates. Track dirty state properly.

6. Platform-Specific Code Without Guards

ISpectrogramControl.h:152-167
The entire Draw() method is wrapped in #ifdef IGRAPHICS_NANOVG. What happens on other backends (Skia, Cairo)? Either:

• Document that this control only works with NanoVG
• Provide implementations for other backends
• Fail gracefully with a clear message

7. Inconsistent Member Initialization

ISpectrogramControl.h:454-478
Some members are initialized in-class, others in the constructor initializer list, and some not at all:

• mTextureBufWriteIndex = 0 (line 467) - initialized in-class
• mFFTSize, mOverlap - initialized in constructor
• mCursorFreq = -1.0 (line 473) - initialized in-class

Follow the iPlug2 style: prefer constructor initialization for clarity.

8. Magic Numbers

ISpectrogramControl.h:428-430

float coeff = (mSampleRate / 44100.0) * (1024.0 / mFFTSize);
int numRows = std::round(coeff * mNumRows);

The values 44100.0 and 1024.0 are magic numbers. Extract as named constants with documentation explaining the scaling rationale.

Best Practice Recommendations

9. Prefer std::clamp Consistency

You use std::clamp at lines 324 and 341, which is good. However, there's no validation when values are set via SetColorMapRange() and SetColorMapContrast(). Consider clamping in the setters.

10. Memory Allocation in Resize

ISpectrogramControl.h:382-389
RezizeBuffers() is called from OnResize() and OnRescale(), which may happen frequently. The std::vector::resize() could allocate. Consider:

• Only resizing if the size actually changed
• Using reserve() to avoid repeated allocations

11. String Comparisons

ISpectrogramControl.h:111-137
Multiple strcmp() calls in OnPopupMenuSelection(). Consider using a more modern approach (e.g., std::string_view) or at minimum use == 0 explicitly rather than relying on truthiness.

12. Missing Documentation

The class has minimal documentation. Add:

• Usage example
• Expected data format for TDataPacket
• Thread safety notes (audio thread → UI thread communication)
• Explanation of frequency scale transformations

Security/Safety Concerns

13. Assert in Release Builds

ISpectrogramControl.h:245-246, 254

assert(fftSize > 0);
assert(fftSize <= MAX_FFT_SIZE);

Asserts are disabled in release builds. Use runtime checks or static_assert where possible. For runtime values from UI, validate and handle gracefully.

14. Unchecked Pointer Dereferences

ISpectrogramControl.h:107, 123, 128, 134

if (pSelectedMenu)
{
  const char* title = pSelectedMenu->GetRootTitle();
  // ...
  const char* colormap = pSelectedMenu->GetChosenItem()->GetText();

GetChosenItem() could return nullptr. Check before dereferencing.

Dependency Integration

15. Colormap-Shaders Library

The integration of the MIT-licensed colormap-shaders library looks clean:

• License is properly included ✓
• Header-only integration is appropriate ✓
• Placed in Dependencies/IGraphics/ following iPlug2 conventions ✓

However, consider:

• Adding a note in the main README about this dependency
• Including version/commit hash in a comment for tracking upstream updates

Performance Considerations

16. Texture Updates Every Frame

UpdateSpectrogramBitmap() is called in Draw() every frame. This processes every pixel of the bitmap. Consider:

• Only updating when new spectrum data arrives
• Updating incrementally (only the new row)
• Using a dirty flag

17. Unnecessary Logarithm Calculations

ISpectrogramControl.h:279-280

mAmpLo = std::log(std::pow(10.f, dbLo / 10.0f));
mAmpHi = std::log(std::pow(10.f, dbHi / 10.0f));

This simplifies to mAmpLo = dbLo / 10.0f * std::log(10.f). Apply the logarithmic identity.

Test Coverage

❌ No test coverage identified

• No unit tests for frequency scale transformations
• No tests for edge cases (FFT size changes, sample rate changes)
• No visual regression tests

Consider adding tests in the Tests/ directory.

Positive Notes

✅ Uses modern C++17 features appropriately (std::array, std::transform, std::clamp)
✅ Proper RAII pattern with destructor handling texture cleanup
✅ Good separation of concerns (data processing vs rendering)
✅ Interactive UI with right-click menu for parameter control
✅ Follows iPlug2 conventions for ISender integration
✅ Example project demonstrates usage effectively

Summary

This is a valuable addition to iPlug2 that fills a real need. The core implementation is sound, but please address the critical issues (especially the typo, bounds checking, and safety issues) before merging. The quality and performance suggestions would improve maintainability and user experience.

Recommendation: Approve with required changes for critical issues.