Hi all,

I needed to have some more long-running visualisation of waveforms in PD, so as there is no vanilla [scope~] object, I thought I'd use [tabwrite~] with [array], as commonly recommended - however, I have stumbled upon a somewhat strange behavior, which I'm not sure whether it's a bug. This is on Ubuntu 18.04, vanilla Puredata from Ubuntu repos (0.48.1-3)

So, basically I made a patch, which is mostly reused help of [tabwrite~] :

The patch itself is here: test-array-scopevis-metro.pd

So, basically, I want to view signals as if on a scope with timebase of 1 second. My PD/Media/Audio Settings tells me: Sample rate: 44100, Block size: 64, Delay (msec): 25

So, all I have in addition to what was there in the [tabwrite~] help, is a few objects to set the array98 array size to 44100 when the patch is loaded - so there is enough memory to record 1 second of signal. And then I've added a metro, so it bangs the tabwrite~ each second (each 1000 msec) - the idea being that I bang the tabwrite~, it records 44100 samples in a second and shows them, then after that second I bang again, it records 44100 samples in a second and shows them anew and so on - pretty much like an oscilloscope at a timebase of 1 sec would do.

However, the actual response is shown in this video:

test-array-scopevis-metro.ogv

That is, when I start the metro at 1000 msec, it keeps banging for at least 10 times, without the array ever refreshing the waveform display?! Then, when I stop the metro, the waveform is displayed ?! At that point, I draw whatever in the array graph so as to "reset" this display, change the metro to 1001 msec - and start the metro again. This time the display does update as expected - but only after an initial delay of some 2 seconds (or three bangs) - I would have otherwise expected a delay of 1 second (two bangs).

Does anyone knows why this happens, and how to get a more reliable behavior for this kind of case? My guess is, for a [metro 1000], PD actually does not have enough time to fill the entire array with all 44100 samples, and thus it never updates the graph - apparently 1 millisecond extra is enough for PD to realize that the array has been filled, and so it updates the graph, but then why does it take 2 sec (at 3rd bang) to update, and not only 1 second (at 2nd bang)?

@sdaau_ml Reliable will be to put the data and then bang once only for the new data.
scop.pd
Unless you want continuous update in which case you need [snapshot~] and a counter..... sort of like this....... phase meter.zip
David.

@sdaau_ml This might help......... scop2.zip
You will need to play around with the metro timing and the length of the array (and therefore the count object....... send the length of the array to it's right inlet so that it counts through the whole index), doing some range sensing (trigger) math just like a real scope if you want to auto stabilise the waveform.
{{note.... this is using [tabwrite]...... not [tabwrite~].......}}
David.

Hi @whale-av ,

Many thanks for the feedback!

First, a note - I also checked [Scope~] found in pd-extended (pd-l2ork, Purr-data) - and it has also its troubles:

• It only reacts on zero-crossings - so it basically shows phasor~ as a straight line, unless it is brought down [-~ 0.5] a bit;
• If using bufsize 1000, it basically updates more than each second - so buffer size seems not to be expressed in samples ?!

Maybe it's possible to control this somehow, since if I open a patch with [Scope~] in PD vanilla, I do get some numbers:

... but I cannot find documentation on this anywhere, and don't really have the time to reverse engineer it...

@whale-av said:

@sdaau_ml Reliable will be to put the data and then bang once only for the new data.
scop.pd

Well, I don't think this will help me much:

First, the timing of slider bangs is inconsistent, at least on Linux/Gnome (and possibly macOS) - sometimes it will hit at 30-40 ms apart, sometimes in much less than a millisecond ( see https://forum.pdpatchrepo.info/topic/8961/repost-measuring-the-elapsed-time-for-gui-hsl-slider-object-events-in-puredata ); and that means sometimes I'll get more data shown in the array98 graphs, and sometimes less (which is not how an oscilloscope display works)... Also, it will not be continually updated, as you noted:

@whale-av said:

Unless you want continuous update in which case you need [snapshot~] and a counter..... sort of like this....... phase meter.zip

Ok, this is pretty cool, thanks for that:

... but this gives me Lissajous curves, not time-domain waveform which I need. Although, I guess [snapshot~] will "lose" some data (due to artifacts of a sampling process), whereas I'd prefer to throw data directly in the array...

@whale-av said:

This might help......... scop2.zip
You will need to play around with the metro timing and the length of the array (and therefore the count object....... send the length of the array to it's right inlet so that it counts through the whole index), doing some range sensing (trigger) math just like a real scope if you want to auto stabilise the waveform.
{{note.... this is using [tabwrite]...... not [tabwrite~].......}}

Ah, this is pretty cool - and actually seems to work close to what I want:

So, I guess [tabwrite ___ $1 $2] means write value $1 at index $2 (couldn't find anything explicit about this syntax in the help file)? In any case, even if it eats quite a bit of CPU, it seems to do the trick for what I need (and thankfully, I don't really need trigger conditions right now)..

Many thanks again for the help,
Cheers!