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)?

@willgerwat Sorry to be so slow..... it was dinner time....
No, it's not the samplerate. It's the sample size that changes with each recording. [soundfiler] outputs the total number of samples.

So as the faders are all 0-1..... and the array has been resized to equal the samplesize......
Start point = left limit fader value x samplesize
End point = right limit fader value x samplesize
Samplerate will always be 44100 if Pd is set to that.

The phasor ramps from 0 to 1...... and is set to do so in the time that is required to play the range of samples.
So it's frequency is samplerate / (end point - start point) (e.g. ramp every 2sec for 88200 samples between the points....... 0.5Hz) if you want it to play at the correct speed.
Vary that frequency if you want to change the playback speed.

When it is at zero, you want it to output the starting sample number......
..... and when it is at 1 you want the endpoint sample number.
So the output of [phasor~] is multiplied by the "playback length" and then the Start point is added.
So (phasor output x (end point - start point) ) + start point........ is sent to tabread~
I hope that is easy to understand (and correct....... )

This might work........ bspoke.pd ..... or at least get you part way.......
I have not dived into your glitch patch yet to understand what it does..... how it works........... but that math should apply regardless.

David.

@whale-av Thank you for your respons.

I tried to install pd-extended by the repo, but there are in 404 status :/
So i download pd-extended.deb to install on my 64 bits host but i miss these depedancies:

pd-extended:i386 dépend de libfftw3-3.
 pd-extended:i386 dépend de libflite1.
 pd-extended:i386 dépend de libftgl2 (>= 2.1.3~rc5).
 pd-extended:i386 dépend de libgl1-mesa-glx | libgl1.
 pd-extended:i386 dépend de libglu1-mesa | libglu1.
 pd-extended:i386 dépend de libgsl0ldbl (>= 1.9).
 pd-extended:i386 dépend de libice6 (>= 1:1.0.0).
 pd-extended:i386 dépend de liblua5.1-0.
 pd-extended:i386 dépend de libmp3lame0.
 pd-extended:i386 dépend de libpng12-0 (>= 1.2.13-4).
 pd-extended:i386 dépend de libquicktime2 (>= 2:1.2.2).
 pd-extended:i386 dépend de libsdl1.2debian (>= 1.2.11).
 pd-extended:i386 dépend de libsm6.
 pd-extended:i386 dépend de libspeex1 (>= 1.2~beta3-1).
 pd-extended:i386 dépend de libvorbisfile3 (>= 1.1.2).
 pd-extended:i386 dépend de libx11-6.
 pd-extended:i386 dépend de libxext6.
 pd-extended:i386 dépend de libxv1.
 pd-extended:i386 dépend de libxxf86vm1.
 pd-extended:i386 dépend de ttf-de

i can also find pd-extended:i386 in the repo list.
But still these deps are missing. Should i installed them one by one ?

Edit :
After trying to install each dept its not working.. some deps can't be satisfied..

how can i installed pd-extended:i386 on 64 bits host :/

This abstraction creates a regular Pd graphical array, where color and line width can be set.

Download: colarray.zip

The attributes of the array can be dynamically set by messages. As it is a regular array, it can be accessed by the usual array functions like [array get], [array set] etc. Save contents is the only feature [colarray] doesn't support, as the array is within the abstraction.

[colarray] makes use of the undocumented (?) fields for color and line width, that are hidden in the Pd source code. The regular graphical array is made from a data structure template, that is defined in a hidden patch, which is opened in the background on startup. [colarray] adds a send object to that patch to get messages from the [struct] object there. After creating the array, a mouse message to that array triggers a click message from the [struct] with the pointer to the array. This pointer is used to set color and line width.

To see the hidden patch that holds the template, you can use this patch: show-hidden-template.pd

@H.H.-Alejandro I finally found the work I did months ago on the effects...... so here we go:

The messages I have coming from Iannix look like /curve "number" f f f "time" f f.
Which are Y and Z?..... Probably /curve "number" "Y" "Z" f "time" f f?

I can build exactly as you have drawn your curves, but what do "reverb" "chorus" etc. control?
Is it just the "amount" of the effect (volume) or for reverb the "decay time"?

**But for the long term I need to build a patch that you can easily make as you want without my help...... or you will always be waiting!
So I think changes will have to be made for the effect curves.... one curve for each effect.
The curves have 3 "floats" unused? The first unused float (before "time") seems always to be zero. The last two floats seem to change sometimes. Can they, or will they be used?

Timbre is missing...... is that what you now call volume?
If it is then I will add a curve for Y=pan Z=master voice volume

One curve for each effect would allow something like this at least.....
Reverb Y=reverb time Z=volume(dry>wet)
Delay Y=delay time Z=volume(dry>wet)
WahWah Y=speed or Q Z=depth
(( I put them this way around to match the note curve..... Y=Pitch Z=volume))
If these parameters can be fixed for each effect type curve (the curve number can change though) then you would be able to change for a newer better effect when you find one (without my help).... and better control the effects.

To add voices you will just have to add a [voice_gen] for each, with its unique number..... [voice_genX] and its argument for the "notes curve number". Then you can re-order any effect curves, swap effects in and out, change the timbre curves etc..... and save the [voice_gen].

David.

@Ale-H.H. I am behind your curve....... always other things to do....... so maybe this will not work for you...... so just for testing if that is so.
NEW8.zip

curve 1 = time
curve 6 = notes
curve 7 = timbre
curve 8 = intensity
curve 9 = pan
curve 10 = reverb

If you want the "notes" curve to be curve 2 then change [voice_gen8 6] to [voice_gen8 2]
Time will only be once on curve 1 I imagine.
The other curves will follow automatically...... timbre curve 3 etc............
David.

"graph" is just a [pd] sub-patch with the Graph on Parent option turned on. This is like an empty container where you can put an array into (using the "put array into last graph" option) or anything else you want.

As far as I know, there are three (plus one) option for storing arrays:

• "Array" from the put menu. This stores the data in a graph, which you can draw manually.

• the "table" object, ie. [table sound1]. This is basically an array but in a closed sub-patch, saving on CPU power as discussed earlier.

• the new "array" object in Vanilla 0.45 and higher, ie. [array define myarray], distinct from the "array" in the put menu. This functions more like [table], but has the additional functionality of [array get], [array set], [array random] etc. (see the helpfile for information on this). Like table, if you click on [array define], you'll see the graph, but you won't have access to the familiar options (points, polygon, etc).

All three of these objects can be written to and read from using the same tabread and tabwrite objects, and there's no difference between them that I know of in terms of playback. I think that the put menu "array" is the only one that will allow you to save the contents in the patch, though.

It might seem strange that there are three versions of roughly the same thing, but the explanation is probably that they were created at different times. Instead of replacing and updating old and obsolete objects, which tends to render old patches as incompatible, Miller likes to make new objects and leave the old ones in place.

The "plus one" method is to store arrays in data structures, but this is pointless for what you're doing because a: it's very difficult and b: these arrays can't be read and written to by tabread/write objects.

You can dynamically create an array with the commands written here here. Just send the message to the canvas instead of to an existing array, ie. using [namecanvas] or [iemguts/sendcanvas].

But are you sure you want to do this? It will almost certainly lead to audio dropouts, and there might be a simpler way of limiting your patch, ie. with array resizing.

If you are sure that array creation is what you want, you should consider using the [table] object instead of the GUI array. This functions the same as an array, but doesn't plot out the points on the canvas, saving a lot of CPU.

Consider the following trivial patch (testing on Pd 0.45.4 on Ubuntu 14.04):

In it, I have a [pd mysubpatch A]. As far as I remember, the A is now an argument of/to the subpatch, in particular it is the first argument - and references to $1 inside the subpatch should expand to A.

So, I've decided to place an array inside the subpatch, and call it $1-array, similar to how in abstractions, arrays are/can be called $0-array - except there the $0 doesn't expand to any arguments, but instead expands to a random number (Dollar signs in objects and messages | PURE DATA forum~). My expectation is that the $1 in my case would expand to the first argument, A, and thus the array name at instantiation time of the object [pd mysubpatch A] would expand to A-array.

The idea is thus to be able to put multiple subpatches in a patch, and control their internal arrays' names by supplying unique arguments. So, I try to copy/duplicate the [pd mysubpatch A] into a [pd mysubpatch B], expecting its array would ultimately be called B-array. So far so good, because I can do this without any problems.

Now consider a slightly more complicated case where I also have a tabwrite~ in the subpatch:

Now that I have [tabwrite~ $1-array] referencing the $1-array in the subpatch, as soon as I turn on DSP/audio, I get a ton of warning: $1-array: multiply defined messages. As I don't get this message when I have only the $1-array in the subpatch, I'm assuming it is not the logic in naming the arrays $1-array via subpatch arguments that is the problem, but instead it is the reference in the [tabwrite~ $1-array] which is causing the warning message.

Note that exactly the same happens, if I save the subpatch as an abstraction mysubpatch.pd, and use it as two objects [pd mysubpatch.pd A] and [pd mysubpatch.pd B]:

But then, in this case, how would I reference such a subpatch/abstraction array, named through an argument, from inside the subpatch/abstraction itself? Note that I need fixed, explicit, known names of arrays, so a workaround like $0-$1-array wouldn't work for me, since the $0 would expand to a random number, which I in principle do not know from the outside (and I'm not sure $0 even applies to subpatches).

Yes, but not like in the video.

The morphing I want to do is not just morphing using an x-y-pad.
It's more like morphing from a certain point "A" towards a movable point "X" on a kind of sailcloth that's clamped between 4 or 8 points like this http://www.lisori-sonnensegel.de/tl_files/lisori_referenz/lisori-sonnensegel-referenz_21.JPG in a coordinate system in which every possible point is a certain sound.

The points B,C,D,E span the sailcloth and A is an outside point. Point X is a movable point on the sailcloth like the point of a laserpointer that hits it. It defines the end-position of the distance A-X that is the morphing path.
Every point represents a parameter set that results in a certain sound and all possible positions X can be, are sharing aspects of all edge-points B,C,D,E in a certain ratio to one another.

I want to know, how this curved sailcloth and the point X on it can be calculated and how to move X around.
Is there a mathematical equation that describes that anyhow?

Sorry, I couldn't exaclty say yesterday, what I try to find out...I haven't been sure how to articulate my thoughts so others understand me.