@KMETE said:

One reason I needed to use the loop 1 message is that the track was always paused for some reason before it ends when no in loop mode.

Ohhhhhh... now I see what it is.

When you ask sf-play(2)~ to play a timed region, it also runs a timed envelope. When you pause / resume, the playback timing doesn't match the envelope timing, so the envelope closes before the end of the source audio.

I'd rather not complicate sf-play(2)~ to allow the envelope to be disabled. But you can back out of one layer of abstraction and use play~ directly.

play~ doesn't take "start end rate" lists like sf-play~ does -- but I have a translator object for that. Since there's already a [pd] subpatch to translate "start/resume" messages, I'd just stick the play translator in there:

Now there's no timed envelope and you should get the play~ native pause/resume behavior without interference (I hope ).

23-0219-play-control.pd

hjh

@cfry Way back when I had no real clue what I was doing I did this programmable curve Should give you a starting point. I did not understand what [vline~] did back then, it would simplify things and there is no reason for that big [expr] but I had not quite figured out order of operations yet and that is the only way I could make it work.

Edit; I went ahead and fixed it up a bit. Here it is without the input timing stuff. Just send it a message of target value, duration and a power 0.5 for log, 2 for expo and anything between or further to the extreme for steeper or gentler curves. [1 1000 2( would give an expo curve ramping too 1 over 1 second. Remembered that I did not use [vline~] because still need to time the curve value and scaling.
curver~.pd

Edit, fixed some silliness, probably still some more in there.

Here I've uploaded plot graph as an abstraction plus two other abstractions to assist in its usage make-plot and cursor-drive

plot-graph creation: plot-graph unique-name size-x size-y;
Address the settings with messages to in-unique-name (eg [s in-$0-channel-L] or connect a control-rate wire to top left corner;

make-plot creation: make-plot array-name plot-resolution;
eg [make-plot $0-left-channel 200]
make-plot is used to take the audio file size given by soundfiler and divide that by the x resolution of the plot-graph window, read the array in chunks of the min max amplitudes to plot the waveform.

cursor-drive creation: [cursor-drive x resolution] eg [cursor-drive 200] drives the play cursor if active

For best results I found it best to keep the resolution to half the window size, say 200 window 100 resolution

SETTINGS. for plot-graph
size float float (can be set as a creation arg);
min float (y value <= 0 for peaks -1 to 0);
max float (y values>= 0 for peaks 0 to 1);
index float (x value 0 to resolution cur float (x position for cursor 0 to resolution);
cur-vis float (hide/show cursor 0 or 1);
min-vis float (hide/show min plot 0 or 1);
max-vis float (hide/show max plot 0 or 1);
colour float float float float float float;
where:-;
float 1 = back colour (0 to 999 struct colours);
float 2 = border colour (0 to 999 struct colours);
float 3 = plot colour (0 to 999 struct colours);
float 4 = cursor colour (0 to 999 struct colours);
float 5 = plot thickness (1 to 5ish);
float 6 = border thickness (0 to 30ish);
plot-fill float (hide/show fill 0 or 1)
fill-col float float (0 to 999 thickness 0 to 5)

For an animated plot with fill try the following in the plot-graph-help
load audio file
click 100 resolution
click look here for more
scale x using the number-box to 200
toggle off min-vis and cursor-vis
click play (and loop if a small file)
in the more page
toggle scope plot
toggle fill plot
adjust normalise
play with the colours

plot-graph.pd and plot-graph-help.pd are read only to prevent overwriting the defaults, change this if you wish

Have fun
Cheers
Balwyn

plot-graph.zip
The picture is reduced to 70%

Thank you.

Going back to the question of overlapping graphs, in this sample patch I would like to overlay 10 graphs of random numbers:

array2.pd

What I was looking for, was to use a single array message like:

[s array $1 (

passing the values ​​to $1 from a [counter] ...but I haven't been able, it doesn't work.
So in that patch I created an object for each array in this way:

Same thing for messages to clear graphs, I was looking for something like:

[; array$1 const 0 (

but it only worked by creating one for each array.
If the graphs were 100, it would be difficult to do all this.

Regarding the quality of the graph: I have seen that no points are created but segments (evident in the image of your last post).
So, to draw a point cloud, remaining in pure data, soon I'll try with "data structures" , using for each point a circle of minimum possible radius. I just started reading some tutorials.
Otherwise of course I export the data (x, y, z) and use an external software. But I'm curious to see what I can do by always remaining in Purr-Data.

P.S.:
Purr-Data, when I use [prepend something] it always gives me a warning that says:

[prepend]: this object is a legacy replacement for prepend in cyclone library that is considered deprecated in pd-l2ork. Please use [list prepend] and [list append] instead.

So I should replace a single object with two objects:

[list prepend something]
|
[list trim]

In the patch above I tried to do this replacement, and it no longer gives me the warning.
It seems to complicate things.

Bye,

a.

@atux The OSC data you get from Iannix (on port 57120?) includes the curves.
separating them from the other data depends on whether you are using the MrPeach library so [route /curve] or for vanilla [oscparse] >>> [route curve]
[route /curve /trigger] or [route curve trigger] will give you both curves and triggers.
You will probably need the transport messages too so as to stop playback when you stop playback in iannix so [route curve trigger transport]

Then unpack the curve data [unpack s f f f f f f] and I think the 2nd 3rd and 4th outlets are xyz.
Actually you will probably need a timer in Pd...... "I have not received a coordinate in x mseconds >> stop sound" to kill the glissando when the curve ends.

Maybe you have to tell iannix to send the curve data....... I can't remember.
David.

@jameslo said:

@Bangflip Can you please post your noisy data so I can try a different smoothing algorithm on it? I'm porting something from the Arduino world for fun.

Yes, I deleted already my old data, but recorded this curve today, that you can use it. It's an strange curve.

I got this curve by send the pitchbend Data from Pure Data to Cubase and record as automation. All values linear via Mackie Mode. Then I switched Cubase to "Houston" Mode and recorded the the output of cubase with pd into the array. The result is always the same. I thought it has maybe to do with the 20 years old algorithm for my houston hardware. Because if I send the midi data via mackie mode to pd, it's much smoother, without these artefacts.

The curve you can see here is also a little bit different in what I described after starting this thread, because the artefacts are in the opposite direction. But it's clear to see with the eyes, how the curve should be. Would be cool, if you could also post, what you came up with. I am interested in the result.

For Forum Request.pd

@Bangflip I would start by making a patch that takes a lower and upper index such that curve[lower] < curve[upper]. That patch would perform the interpolation you described to substitute for the negative portions of the raw curve, and if the indexes are adjacent then it would just output the adjacent curve values. You can test that patch until you are convinced it's working. Then your problem is mostly reduced to finding all the lower and upper index pairs, with one special case if the largest curve value isn't at the end of the input table.

The (lower, upper) pairs for your example are (0,1) (1,4) (4,5) (5,6) (6,8) (8,9) and (9,10)

I tried using [lop~] but the problem is that its beginning state is always 0, which may or may not be what you want. Also, lop~ may allow some negative slope to pass through, which I'm gathering you don't want.

Here's a Pd-vanilla version of a linear-to-curved range mapping formula from SuperCollider. Published at https://github.com/jamshark70/hjh-abs . There's a message-rate and signal-rate version.

(Helpfile typo has been fixed but I won't bother to upload a new screenshot.)

This is, of course, close to cyclone's [scale]. It's close -- the symmetry is different (help file says "better" but actually that's a matter of taste, or situational need). For reciprocal values of [scale]'s "exponential" factor, the respective curves seem to be a reflection around the diagonal (x <--> y); for negated values of [lincurve]'s curve factor, one curve is a 180-degree rotation of the other (x --> -x and y --> -y). Compare -7 vs +7 lincurve against 0.2 vs 5.0 scale:

-7 curve, ~0.2 exp:

+7 curve, ~5.0 exp (lincurve and scale are very very close here!):

hjh

Amplitude modulation of any sort, including envelopes, always distorts the spectrum to some extent.

Normally we don't notice because typical sounds have a complex spectrum, which masks the distortion.

But here, you are applying it to an artificially simple spectrum, containing only DC offset. DC offset is silent, and the spectral distortion is not, so there is nothing to cover it.

I generated an audio file with a 30 ms ramp up and 50 ms ramp down. For comparison, I applied this envelope to a sine wave in the right channel. Then I opened this file in Audacity and looked at the spectrogram.

I think it's pretty easy to see here why the envelope might be audible in the case of DC * envelope, but not perceptible in the case of the audible signal * envelope.

Bottom line is, just because you hear spectral distortion in an artificial scenario which you would never encounter with audible signals, doesn't mean that it will be noticeable in real world scenarios.

(Carrying it further: If there is no envelope, there's a risk of an instantaneous transition from non-zero to zero or vice versa. Instantaneous transitions require a lot of high-frequency content, which we hear as a click. A linear transition effectively lowpass-filters the instantaneous transition -- there are still artifacts, but they are relatively low amplitude, and in a frequency range normally occupied by musical tones at a much higher amplitude. A ramp-enveloped sound will never be perfect, but it's better than a rectangular envelope.)

"replaced by something better" -- A sinusoidal envelope shows a smoother spectrogram. You might try that: cos * 0.5 + 0.5 -- from pi to 2pi is your ramp up, 0 to pi is the ramp down.

Edit: You can eliminate the +0.5 by squaring the cos and halving theta, because cos^2 x = cos(2x) * 0.5 + 0.5. Actually cos~, IIRC, scales radians down to 0 .. 1, so you could do line~ --> cos~ --> [*~] (cos~ to both inlets) and drive it by "0.25, 0.5 30" for the ramp up, and "0, 0.25 50" for the ramp down. Haven't verified this at the computer but I think it's right.

hjh

@avpd The maths is written at the beginning of the source file for [curve~]....... curve~.txt

Also take a look at this (for vanilla)....... https://forum.pdpatchrepo.info/topic/12145/curvegen-curved-ramp-generator-for-pd-vanilla .....
Download the patches from the link and they should furnish some clues for your patch if the mmb original external used the same factor values as cyclone.
David.