@alexandros said:

@ddw_music you can't really square the value in case it's a volume envelope, because that will square the sustain value as well, and that will reduce the actual value.

Fair -- squaring is a bit of a hack to make up for the lack of a curved-segment envelope generator (like EnvGen in SC, where segments can be linear, exponential, sinusoidal, curved by a curve factor, maybe a couple others, built-in ).

hjh

@vulturev1 Use the right outlet of [sigmund~] with [>] and [spigot] to filter out "silence".
Look at [moses], you can use it to filter big jumps. Maybe use feedback to dynamically adapt the right inlet.
Also play with sigmunds window-size and hop-size.

This is a Vanilla moving average (EDIT now with [arraysum]) :

movingaverage3.pd
movingaverage3-help.pd
Moving average is a low pass and it also distorts the good data portion.
Reading your description, maybe a median filter with uneven windowsize is better suited, see this screenshot, made with else/median: https://forum.pdpatchrepo.info/topic/13849/how-to-smoothe-out-arrays/11

EDIT: Pd 0.54 Also study helpfile with -minpower, -quality, tracks ect !

@vulturev1 Processing the input can help a great deal with [sigmund~] jumping around but how to best go about this depends on what your input is and what you want on the output. When I was using [sigmund~] a lot I found filtering, frequency multiplication and compression all to be useful for getting stable output, especially frequency multiplication. I always found it easier to address the problem on the input instead of the output.

FWIW -- Pd's native interface for sound files is difficult. While that's consistent with the "minimal core" philosophy, I find it annoying enough to work with that I would sometimes be tempted to avoid using sound files just because of rebuilding basic functionality.

For example, a couple of factors that haven't been mentioned in this thread yet:

• What if the sound file is at a different sample rate from the audio system?
• Also, audio engineering 101, every audio segment hitting the speakers should have an envelope, even if it's just a trapezoidal envelope with a very short attack and release. Otherwise you will get clicks at every splice point. This means, then, using two players and toggling between them (because the ideal splice is a short crossfade, not a jump cut).

A while back, I made a set of abstractions to simplify these problems. Using those, this is how I would do it.

24-0210-segmenter.pd

Here, the logic is:

• Choose a random duration.
• Choose a random direction, +1 or -1.
• Random starting position is chosen based on dur * direction.
  • Random range is 0 to (soundfile dur - abs(dur)).
  • Then, if dur is negative, we have to shift the entire random range up, by subtracting the negative number.
• Then the endpoint in the sound file is start + (dur * direction). Backwards playback is start > end.
• Last, toggle 0 or 1 to choose one of two sound file players.

monofile and sf-play~ are abstractions of mine. sf-play~ uses cyclone. Note that cyclone's play~ claims to take time indices in ms, but it doesn't compensate for sample rate. My abstraction does this automatically -- ms go in, ms come out.

YMMV but I find working with sound files is much easier when the programming interface is more usable.

hjh

I am attempting to use sigmund~ to detect low frequencies.

I am putting an osc~ to detect lowest frequencies.

It seems sigmund~ cannot detect frequencies below 45 hertz.

Here is the object I am using:

sigmund~ -hop 65536

@kaimo An envelope follower you want to patch?

Depending on how accurate it should be, such simple tasks can quickly become quite complicated.

Scaling of [sigmund~] or [env~] also depends on your input:
https://en.wikipedia.org/wiki/Root_mean_square#In_common_waveforms

Edit:
crest factor https://en.wikipedia.org/wiki/Crest_factor#Examples

Hi All,

I’m trying to figure out how to scale the output of a sigmund~ object so that its value is between 0 and 1.0. Basically I want to make it so that the louder the input the louder the output for an oscillator. I figured I could then multiply the output of the sigmund object with the oscillator.

Any tips are greatly appreciated! Thanks

@manuels Oh wow, you did a great job on that investigative patch, thanks. It answers many of the follow-up questions I was going to ask:

• what would the avging factor graph look like for those three examples?
• how do you compute the segment slope from the cutoff frequency?
• how is the width of the "linear" segment related to n and p?

And it also looks like you were able to write the equivalent slop~ filter using expr~. So helpful. I didn't understand that that digital low-pass filter equation was literally what they were computing.

So would you agree that it's impossible to make any of the response segment slopes > 1? And is that equivalent to saying that this (or maybe any) low pass filter can't amplify a signal?

From the jitter example, is "either by setting n = 0, p = 1..." a typo? Shouldn't it be "either by setting n = 0, p = a..."? Also, from that same example, "setting kn = kp = inf" must be a typo, right? They meant "set the corresponding frequency input of [slop~] to inf" I think, or they should've been setting kn = kp = 1.

Do you understand the statement about translation-invariance in the Rationale section? And can you anticipate what kind of skullduggery they're referring to that they didn't finish writing up? I'm assuming "soft saturation" means "soft clipping".

The html documentation for [slop~] starts by introducing the idea of a low pass filter that has a non-linear (i.e. piecewise linear) averaging factor. But then in the slew limiter example it refers to the "linear-response" frequency, and in the peak meter example refers to the "linear region". I'm not following. In the second case I'm guessing that the linear region is the segment between -n and p, is that correct? If so, then the linear-response frequency must be related to the slope of that segment, k?

@manuels said:

Let’s say we have a sample rate of 48000 Hz, which means 48000 samples per second. Then the duration of one sample is 1/48000 s or about 0.02 ms. So if you run the metro at 0.01 ms, one period of the wave would only have about 6 samples! Now it’s obvious that it’s impossible to create line segments between 12 points with just 6 samples, isn’t it?

That's a good catch.

The phasor~ approach that I demo'ed would inherently decimate the given waveform -- plenty of aliasing but the frequency would be correct. However that approach seemed not to be very popular in the thread (though I have to admit it wouldn't handle the random segment time gracefully -- you could modulate the phasor~ frequency but the ramps between points would not be straight lines -- I thought about how to do that but it seems tricky).

hjh