Good q! I’m an audio dev who thought the general community might appreciate the project. It’s a cool effort (my primary beef with pd was always the UI)
This is great, thanks! I looked for existing unicode waveform representations before building, but didn't run into this. The unicode blocks the Julia REPL uses limits the output to magnitude (signed) vs. amplitude (unsigned), but it gets the job done!
STK is cool! I'm building a synth plugin, so that's why I'm in JUCE...
I want to hear more about the remote visualizer! I was using Jim Credland's buffer debugger (again, JUCE)[1]. It pops open a window, making it fairly easy to visualize buffers with one caveat: you actually have to tell it about the buffers you care about visualizing and then recompile. This means debugging can't really be on the fly (unless you only always care about the same buffer or two).
The other issue I ran into was viewing audio from my tests. I'd love to hear about the shared memory approach — real waveforms would be ideal!
I am just starting to learn audio programming and DSP, would definitely like to see this as I'm interesting in non-vst applications so a STK+Dear ImGUI setup seems really practical. I would certainly check that out
You found the Achilles' heel of the project! I don't mind the fonts being different sizes or not monospaced, but the fact that there's a difference in height in the font rendering between ⎺ and ‾ on different platforms is a bummer. I have a flag in the C++ implementation so they can still be rendered "correctly" in IDEs like Xcode [1].
I felt doomed to Unicode in this case because of the number of places I wanted them to show up (CLion lldb integration, GitHub actions output, terminal). I would have loved to actually render graphics! I actually never thought about how they would render on a blog article, I wouldn't generally wouldn't use them for blogging...
Thanks for the constructive feedback! It's nice to have some new ideas.
In the audio contexts I'm working in, it is a feature to have the zero crossings and errors jump out. It's less "pretty" but is as data-dense as I could get just with unicode.
> why not use color when available?
You are right, color would increase data density. In both my test context and in my debugger, color is unfortunately unavailable...
> Silence should be easy to spot, not crammed behind numbers!
The condensed 0(256) notation is ugly, it's true. However, you can't miss it, and it's information dense. This was the toughest element to design and I tried a few other styles before this, because yes, it's ugly :)
I'm often working with buffers with 256+ zeros, so zeros had to be condensed to stay legible. Simultaneously, it's often necessary to know the exact number of empty samples (they could occur at the start, middle or end of the block). A dash - for a 0 such as in [----0(256)] might have some ambiguity with a quiet part of a signal (it's important to differentiate true zeros) but your post has me thinking!...
My instinct would be to use hex for those sorts of runs, the compactness adds up. That might mean more annoyance in converting values then you're willing to tolerate, and perhaps I'm over-indexing on the 256 in your example.
Nice! I became obsessed with rendering sparkline representations of chunks of audio for the same reason: to inspect failures when writing tests / refactoring. I wrote a JUCE module (C++) and integration with lldb to make it quick to inspect chunks of audio in the IDE: https://github.com/sudara/melatonin_audio_sparklines
"Feature only the most current Apple products in the following finishes or colors: iPhone 5s in silver or space gray, iPhone 5c in white or blue, iPad Air in silver or space gray, and iPad mini in silver or space gray. If multiple Apple products are shown, display them in the correct relative sizes."
Agreed with all of that! Especially the poor sap who is reading the code wondering WTF...
So — my thinking for those two methods is to purposefully encourage being imprecise. We are always so obsessed with being exact in programming. And typically for good reasons. But in some cases, perhaps it doesn't matter if it's 50% of the time or 20% or 10% of the time. Just sometimes, not all of the time.
That being said, you bring up a fantastic point: what the hell does 'sometimes' mean? Half the time? What does rarely mean? It's certainly going to depend on the individual. No answers here, except I'm leaning towards redefining "sometimes" to mean between 15-50% of the time.
