It's SO satisfying to have a little [hslider] moving along under an [array] which shows the waveform... maybe you can even grab the [hslider] and drag it to a new point in the file/sample...

But they're SO BIG! Any long sample is made of of many points, even if the display is shrunk down. That makes my PD hiccup whenever it needs to redraw the waveform (ie, minimize then maximize the window).

I've tried making a duplicate of the real [array], but forcing it to be "lower resolution" (say, 1000 points). Sadly, sampling every "arraySize / 1000" points and writing that to the arrayView doesn't look anything like the original. Neither does averaging all the samples within a given chunk... though it DOES take a long time!

Is there another, easier, more commonplace solution I'm overlooking?

Drawing arrays is definitely a lot of work. If you want to constantly have your array displayed, you could use [pd~] and split the drawing process from the audio one. You can have an [array define] object in the main process that runs the audio and a graphical array in the child process. Unless you can do with closing the array window when you want to redraw, but then you won't be able to have the slider the way you show in your post.

you could try to go through the pd source code and see how it does the drawing (and only draw those corresponding points)

Hi,

maybe could you have a look at waveform and hrslider abstractions from Maelstorm's GitHub.

Edit: sorry I don't have the time to test it now, maybe isn't lighter than classical technique but still neat abstractions, as is the whole "library" by the way

Nau

Thanks - it's good to know, at least, that it isn't just a simple obvious object I was overlooking. And thanks, @nau, I'll take a look at those libraries when I get home!

@Load074 Over the past few years I've also been trying out various approaches along the lines of what you're looking for, and actually tried something rather similar to your idea: pulling only one sample per x samples of the source array and sending to a smaller display array. And indeed, it doesn't work because those values are just scattered snapshots of the signal & will be discontinuous with the neighboring display samples. I realized that some kind of averaging would be needed, started to work on it, then got sidetracked & never followed through...

But, I ended up finding two pre-baked solutions:
rh_wavedisplay from netpd
pp.waveform from AudioLab

I can't quite wrap my head around how rh_wavedisplay works from looking inside the abstraction, but the result looks nice. From the help patch:
This abstraction finds the minima and maxima for each section of the source table that covers one pixel of the display array. The result is a good looking waveform that does not suffer from aliasing.
I also like that it allows for only a section of the source array to be used for display (which is important for how my performance patch uses arrays). In practice it still causes audio dropouts when updating large source arrays, unfortunately.

pp.waveform uses data structures, which is why the result looks so different visually. I don't understand data structures enough to play around with this or try to adapt it for my uses, but I would be definitely curious about whether it's any more efficient than those other graphical array manipulation methods.

I also wonder if there's simply no method that will prevent audio dropouts without some kind of array manipulation that can run on a different thread. I've been looking into the shmem library to see if it's possible to outsource the array processing to another Pd instance (similar to the Pd~ approach that @alexandros suggested), haven't gotten very far so I still don't know if there will be a bottleneck when dumping a huge array to memory.

@beep-beep Hot dog - your comment actually pointed me towards something that works good enough for me!
Using [abs] will at least keep everything positive, so the discontinuities aren't crossing the zero line... and then, to make it even prettier, I inverted it with [* -1] to make a mirror image.
Since this is just for looks, I think it'll be good enough... it may turn out that I need a smaller viewer (less than 2000 points) even still, but so far, no glitches, and it looks reasonably like the 7-minute file I loaded.
/home/scuttlebutt/Pictures/Screenshot_2024-01-23_21-42-53.png

@Load074 Glad to hear it! Nice lookin waveform there.