Comment by praash | Hacker News Reader

Comment by praash | Hacker News Reader

I think the additional zeroes, letters and crosses work heavily against visual intuition. In a single line of monospaced text, their disproportionate size breaks continuity and you're forced to reconstruct the actual shape in your head.

    [0⎻⎺⎻x—x⎻x—⎼⎽_E_⎽⎼—x⎻⎺‾E‾⎺⎻x_⎽⎼—0(234)]

Inserting bracketed numbers throws the whole sparkline concept out the window.

If terminal output is the use case here, why not use color when available? Zero crossings could be highlighted in blue, and out-of-bound clipping could be shown in red. Long sequences of zeroes could just be represented with a red line, or even empty space:

    [        ]
    [----    ]

Silence should be easy to spot, not crammed behind numbers!

    [0(512)]
    [----0(256)]

Which style would you find easier to understand at a glance?

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!...

For zero-crossings my first thought would be either bullet (•), to not break the visual flow; or multiply (×), since it's at least vertically centered

OMG, I thought I was already using ×, but that was a different project. Good call!

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.

Reply on news.ycombinator.com