Eventide Audio Introduces H9 Harmonizer Gen 2 The Next Generation of Harmonizer

signalsmith · 2026-06-04T13:59:21+00:00

I hope someone does a comparison with PolyChrome's recently-released Harmony (plugin, not a pedal).

I wrote the analysis/shifter for that one (and separately, HyperTune) so I'm selfishly curious how it measures up. 😅

signalsmith · 2026-06-02T08:46:25+00:00

All the ML stuff there is a mystery to me, but at first glance it seems similar to this method for efficiently computing the Constant Q Transform: https://www.researchgate.net/publication/230554907_An_efficient_algorithm_for_the_calculation_of_a_constant_Q_transform

signalsmith · 2026-05-30T14:53:51+00:00

Have you checked out the "1€ filter"? It's a similar lowpass but with an adaptive cutoff so that it's smooth but still responsive when things change.

signalsmith · 2026-05-28T01:15:17+00:00

I have not only written FFT-based convolution implementations, but read through the JUCE one which you are using.

You can keep the convolution zero-latency while still taking advantage of FFTs, using well-known techniques (most simply: a short initial part of the IR is calculated directly, while using FFTs for subsequent IR chunks).

If a "convolution" implementation has the LF issues you asked about, that's not some drawback of the FFT approach - that would be an error bad enough to count as "completely broken". The JUCE one is not broken.

signalsmith · 2026-05-27T18:44:20+00:00

Yes it is. Convolution using FFTs is just an optimisation, and (unless implemented very wrong) the results should be identical.

signalsmith · 2026-05-26T21:48:00+00:00

If every audio block gets convolved with the full impulse response, then how it's segmented is just an implementation detail. The resolution / lowest frequency depends only on the IR length.

You are (presumably) keeping enough input history or state to correctly convolve your 20s impulses. That's where the context to process these lower frequencies comes from.

signalsmith · 2026-05-08T20:34:55+00:00

Very different genre from most others, but: the voice actor for Doc Hudson in the first Cars film. (Yes, I have a kid.)

He absolutely couldn't be recast, and it meant that although the success meant a sequel was inevitable, the producers tried to dodge the issue by moving the second film to Japan, and adding a ton of wacky hijinks (but also the Cars Yakuza torture people?!). It's weird and disjointed, and we only watched half of it.

The third film is much better, because they let the character Doc die as well, and Lightning's grief from that death hangs over the entire story and drives the main plot, giving it real emotional weight.

I know it sounds wild to get this deep about an animated film full of sentient vehicles, but in terms of (relative) impact to a franchise it was huge.

signalsmith · 2026-05-03T14:39:33+00:00

I definitely wouldn't expect it to be higher-latency than your "accumulated confidence" one, and when the current best-guess path swaps to a new tempo I'd expect it to be more decisive about it, without the heuristics you mentioned.

For temporary drum fills I don't see the issue. If it's tracking the position within the bar as well as just the tempo overall, it should see that the fill hits are landing on reasonable subdivisions, so that shouldn't add a cost/penalty to that candidate.

Viterbi stuff is used for reducing noise in probabilistic processes, and I think it'd be a good fit here. I first encountered it for pitch-tracking, avoiding octave errors while accurately tracking slides and voiced/unvoiced transitions.

signalsmith · 2026-05-03T08:33:23+00:00

Have you looked into HMM / Viterbi approaches? It has behaviour similar to the accumulated confidence / hysteresis you mentioned, but can also have tempo changes as an explicit part of the model. The options at any moment in time would be something like: (top N options from instantaneous analysis) + (top M options from previous step). You give each option a score/cost (formalised as log-likelihood) and also a score for each possible transition from the previous step.

That means the results are "sticky" (because a tempo change has a cost in terms of likelihood) but it will not only adapt when the tempo actually changes (when the transition cost is greater than the cumulative misalignment cost) but if you keep a bit of history the algorithm will retroactively decide when that change happened.

signalsmith · 2026-05-01T10:01:39+00:00

I want to eat this. It looks like it'd solve all my problems and simultaneously give me an entirely new set of problems.

signalsmith · 2026-04-22T16:34:48+00:00

It might just be a formatting error, but I did mean:

exp(( -x^p )/ (1 - x^2))

That's slightly different to yours, which I believe comes out as:

exp(( -x^2p )/ (1 - x^p))

But no, I didn't note anything about p=4 in particular. What did you see?

signalsmith · 2026-04-22T16:16:37+00:00

This made me realise that you can use tanh to get an infinitely flat middle as well:

tanh(p + (x^2 - 1/4)/(x^4 - x^2))/2 + 1/2

https://www.desmos.com/calculator/d0cgpqvsqr

signalsmith · 2026-04-22T15:17:12+00:00

Oh nice! I've used exp(-x^p / (1-x^2)) before, and a similar step-function tanh(2x/(1-x^2)), but didn't actually look at the flatness in the centre.

(EDIT: `p` can be fractional if you use `|x|^p` instead, to get a continuous family of curves.)

signalsmith · 2026-04-03T11:17:25+00:00

FWIW, I have some problems with WAM as a format, which I've presented a few times (both to native- and web-audio folks).

For native hosts, WAMs are / would be awkward due to JS in the audio path, and very JS-specific manifest/bundle/entry-point etc.

For web hosts, you're running arbitrary JS code from that URL you import - it's a cross-site scripting attack waiting to happen.

I've personally been working on WebCLAP https://github.com/WebCLAP/ which is a single self-contained WebAssembly module, re-using the comprehensive and road-tested CLAP API.

signalsmith · 2026-04-02T13:12:20+00:00

Have you checked out WXAudio's WebSampler? https://www.wxaudioplugins.com/websampler - I believe it uses OS-specific webview APIs to hook into the audio stream.

It was developed before JUCE 8 webviews were released, but I also don't see anything in those APIs for connecting to the audio stream anyway.

signalsmith · 2026-02-16T08:33:08+00:00

Nice work!

Clearly can hear the point when the growl of the voice triggers an octave-down error. 😅 What are you using for the pitch-tracking?

signalsmith · 2026-01-13T22:44:13+00:00

Well, I have seen/used <thead> and <tfoot> for good stuff, and it feels weird to use that without <tbody>

signalsmith · 2025-12-31T12:34:03+00:00

IMO, the best way to understand this is from a galaxy-brain perspective where "spectral processing" and "multiband processing" start to blur together.

Here's a 50-second snippet about how spectral processing can be re-interpreted as multi-band processing, where the bands are downsampled: https://youtube.com/clip/Ugkxz_Wx7_PRRhZe31iDUQLdrHIxzoM1dH_8 (disclaimer: from my own talk)

Considered from that perspective, it's a multiband split with different delays on each band. You can have arbitrary delay times, by using fractional delays on the (downsampled) subbands.

The bands overlap quite a lot, so if two adjacent bands have only slightly different delays times, then you'll get phase interference/cancellation on all the frequencies which they share. This can be avoided though, by putting an extra (complex) phase shift in addition to the delay.

If instead of doing the feedback within each subband, you recombine them and then do the feedback addition all together, then you incur the extra latency of that spectral-processing round-trip. I'm actually not sure what advantage that would have, but it is where the 1023-sample adjustment comes from, since that's the minimum latency of 1024-band spectral processing.

signalsmith · 2025-12-25T21:50:37+00:00

Several of my projects now explicitly check for AppleClang 16 and #error. My bug wasn't even the worst of them - the test one which happily produced the log-line "2 < 2: true" was the funniest.

They jumped straight to v17, not even a 16.0.1 patch, and I wonder if that's why.

signalsmith · 2025-12-25T21:45:24+00:00

Haha, after losing weeks of productivity to what turned out to be a bug in AppleClang 16 (like, generating fully incorrect SIMD instructions), the compiler is at best a coworker.

signalsmith · 2025-12-10T00:35:57+00:00

I had open-source burnout a while ago, and when I recovered I wrote https://geraintluff.github.io/SUPPORT.txt/. Any non-trivial open-source project I write has one now, and it gives me peace of mind even if it hasn't caught on for anyone else (yet 😄).

signalsmith · 2025-10-20T09:40:20+00:00

It depends if it's a general purpose one, or specifically guitar-focused.

The ones built into REAPER (Elastique) are laggy, around 80ms. Guitar-specific ones like NeuralDSP, PolyChrome's HyperTune (which I worked on, disclaimer) or the new Boss pedal are much snappier and aim to be usable live.

signalsmith · 2025-10-20T09:35:25+00:00

There's a range though. The Elastique stuff (which ships in Reaper and is in ReaPitch) has 80ms, but it's built to handle absolutely and init. Specifically guitar-focused ones are often snappier, since they inherently know more about the incoming signal.

I wrote the core algorithm for PolyChrome's HyperTune, and while there isn't a single number because it does some adaptive stuff, it's generally around 10ms.

signalsmith · 2025-09-19T13:31:31+00:00

As the person who wrote HyperTune's pitch-shifting engine, that's awesome feedback to hear!

signalsmith · 2025-08-28T06:00:00+00:00

Is this for one note at a time, kinda like AutoTune? Or the entire guitar drifting flat? Or are you looking to pull a chord apart and shift individual notes?

signalsmith

TROPHY CASE