Nice. To the folks saying "nothing to see here" this appears to be a variation of filter-bank spectral analysis where each band varies in frequency to track "the" in-band sinusoid. Somewhat like a bank of PLLs each with its own tracking bandpass filter. By using IIR filters rather than FFTs you avoid the latency of buffering up a full frame of data before you can run the FFT analysis. I am curious how this handles input containing broadband transients. It might be interesting to use CIC filters rather than an IIR lowpass to get better time selectivity, but maybe that's already been addressed, I didn't read the papers.
I used the Exponentially Weighted Moving Average (aka low-pass filter) because it has a very nice iterative form and is very computationally efficient. My objective was low-latency for real-time systems (so no looking into the future either). I haven't looked into using other types of filters because I haven't felt the need for my own applications.
Also my primary objective was tonal analysis so that's where I focused my limited time and resources.
I haven't had time to explore what to do with broadband transients much. A tracking resonator bank will certainly capture the energy (either in tracking mode or not). To me the synthesis examples I have posted on the project site sounds very comparable to traditional vocoder results; not bad but not great, especially with transients (as expected...)
From an analysis point of view, I anticipate that a Novelty measure computed from a tracking resonator bank would be quite usable...
Agree re transients. I think Miller Puckette's "bonk" object did transient detection using filter bank. Can't find the paper right now. In general I think detecting rapid changes in phase performs better than changes in amplitude for transient detection.
I believe that the good sounding phase vocoder algorithms do transient detection and instantaneously reset the phase of the spectral peaks associated with the transient (effectively passing through the original transient without smearing it).
I think you have it sideways. STUN [1] is the NAT traversal / "NAT hole punching" process that allows peers to discover their public IP addresses and establish direct P2P bidirectional UDP communication. WebRTC depends on STUN to establish P2P communication. You may be thinking of TURN [2] which amounts to routing traffic through an intermediary node that is visible to the two peers.
Wild hypothesising here on HN but if you read to the end of the GH issue users have been reporting that STUN has been failing (i.e. no P2P link establishment, fallback to high-latency relay servers.) Multiple users have been able to work around the issue by manually substituting older Valve WebRTC dlls. I'd love to read a postmortem from the Valve devs.
"requires" is of course subjective, there are always multiple ways to do something. But sometimes it is convenient to model a system as concurrent execution streams, for example: multiple sessions (servers), multiple entities (games, robotics), multiple in-flight transactions (any kind of i/o or concurrent compute). Agreed these are often C++ use-cases but there are obvious benefits to using Erlang or other virtual machines: memory safety, isolation, fault tolerance.
> The first group are still thinking fairly deeply about design and interfaces and data structures, and are doing fairly heavy review in those areas.
I can't speak for others, but I'd go further and say that LLMs allow me to go deeper on the design side. I can survey alternative data structures, brainstorm conversationally, play design golf, work out a consistent domain taxonomy and from there function, data structure and field names, draft and redraft code, and then rewrite or edit the code myself when the AI cost/benefit trade off breaks down.
GP and this is where I stand with it too. Additionally, the cost of "exploring" down a riskier design path and discovering the unknown unknowns is substantially reduced too, which I think ultimately leads to better decision-making on the design side. It's less "let's just stick to the pattern/tools that we know for sure works because we've done it before" and more "here's a vibed up mockup of it working, we can all see how this actually works and the better pattern that it enables".
Obviously technical and design choices have risks beyond just initial implementation, and those have to be considered too (do we trust the dependency, will it still be there in a year, can we get fixes merged upstream), but I think there's significant value in driving down the cost of code sketches involving unfamiliar libraries and tools.
reply