Actually the graphics are the easy part, the bulk of the time in the "inner loop" is in the audio analysis. Not to give away any secret sauce but in my experience naively using `AnalyserNode.getFloatFrequencyData` does not provide adequate performance or even accuracy when under "noisy" conditions. FATpick uses a "proprietary" (custom) pitch detection algorithm, but, other than a few domain-specific insights maybe, there's nothing particularly groundbreaking about it -- it's doing the same kind of things you'll find in academic literature on the topic, just judiciously selected and tuned by endless (and ongoing) lab-testing.
But from a quick scan I think FATpick's tablature view is a little different what VexFlow does. FATpick's view is like a "piano-roll" - the x-axis maps directly to time such that the notes scroll from right to left at a constant rate, with the width of each "bubble" directly corresponding to the duration of that note. VexFlow does "traditional" tablature (and stave) notation, like the sheet music most people are familiar with, in which all notes are more-or-less the same width on the score, independent of duration.
That said, adding conventional (stave) notation to the player view (instead of or in addition to tabs) is on the roadmap, and VexFlow seems like it be very useful for that.
That's also on the roadmap. Right now FATpick renders chords just like any other set of notes in tablature, which is less than ideal once you have much experience with playing chords at all.
Also curious what did you use for painting the tabs. DIY in Canvas? Or vexflow?
Btw there’s a nice talk from Adrian Holovaty on perf challenges with soundslice and its drawing/updating of notation (standard and tabs)