@mbbaker I don't hear dropouts either ... But I noticed, that you forgot to delete the [tabsend~] objects in copy no. 7. Not sure if this is (or should be?) a problem. Since Pd doesn't complain about it, I guess probably not.

@Muology Just another approach to the second part of your problem ...

You could use binary numbers to find all possible subsets of a list of length n: iterate the numbers from 0 to 2^n - 1 => convert to binary numbers => use digits to select list items ... like this: subsets.pd (The weird backward counting is just to give the resut in a logical order.)

It may not be the most efficient way to do it, because ALL subsets (not just those of a given length) are generated. But it's fully customizable!

@kyro Very interesting, thanks!

Conceptually this “cascade FM” is of course quite different because it’s not a feedback loop. But the point about FM and PM producing energy at 0 Hz and thus altering the pitch seems to be relevant for understanding the behavior of the feedback oscillator too:

My attempt to fix the delay time kind of works in the region where the waveform is symmetric and produces only odd harmonics, that is up to index values of about 2.45. Beyond that not only the symmetry is lost but there is also a drop in pitch (quite audible actually). So maybe it’s the increasing asymmetry that eventually leads to chaos?

BTW: The error I was talking about in the original post is probably better understood as being two samples per period (therefore one half sample per quarter period which is the delay time).

@oid Thanks a lot for the hint! The link works just fine for me too.

Another great resource that I found just recently is Risto Holopainen's website. He investigates many less common variations of FM here, also addressing the topic of chaotic behavior in some of these circuits.

As far as I can see, neither of the authors deals with delayed feedback, though.

I was just experimenting with the “classic” feedback FM and stumbled on a related technique that seems quite interesting to me, especially because of its chaotic behavior. It’s actually very simple: The output of an oscillator is delayed and, scaled by some factor, fed back into that same oscillator as its frequency. So there is no external input, no carrier frequency (or a zero carrier frequency if you will), which means that it is a symmetric “through-zero” FM.

feedback-oscillator.pd

By guessing I figured out how the delay time determines the frequency of the oscillator, but I still don’t understand a few things: Why is there a factor of 4 involved so that the delay is one quarter of a cycle? And why is there still some error? I found two ways to fix it, first by oversampling and second by reducing the delay time by the duration of one half sample. To be honest I don’t have a clue why this works ... Any ideas?

What I find particularly interesting is the path from sinusoidal tones at modulation index 1 (which seems to be a critical value) to different modes of periodic oscillation and finally to chaos when the modulation index is increased: First odd harmonics are added, then even harmonics, then a period doubling or “bifurcation” occurs, and shortly after that we get into the chaotic region. This seems to be not too different from the logistic map or related chaotic maps. So I’m wondering if it’s possible to analyze the oscillator in terms of chaos theory to better understand and control its behavior.

Apart from being mathematically interesting, I think this could also be a usable noise generator with spectral control. Other effects can be achieved by adding an external input ... but for now, I’m more interested in understanding that simpler case.

@jameslo said:

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?

Yes, I think so. I mean, an averaging factor > 1 doesn’t even make sense, right? So for all factors k, kn, kp it must be true that 0 <= k <= 1. Otherwise the filter wouldn’t be stable, I guess.

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.

It seems like you really found two typos here! You probably should suggest the auhor(s) to correct this ...

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".

Not sure, if I do understand this (probably not) ... Maybe "translation invariance" refers to the fact that adding bias doesn’t change the effect of [slop~], whereas in other waveshaping techniques it does? I may be completely wrong about this ...

@jameslo I think you’re exactly right, although I’m struggling with the terminology here too.

As far as I understand, the five arguments of [slop~] are directly correlated with the five parameters of the piecewise linear response function: k (1), n (2), kn (3), p (4), and kp (5). Using parts of the [slop~] help file I made a little patch to understand this correlation:

slop~-response.pd

Whether or not the term “linear region” is a good name for the middle region ... I don’t know. But what I find even more confusing is that “slope” is seemingly used as a kind of synonym for “slew” in some of the examples. I’m constantly getting confused when I’m thinking of the slope being the input of the limiting function, because really what’s limited is the slew, that is the difference between the current input and the previous output (shown on the horizontal axis of the response graph). So I guess the main difficulty of the whole concept is that you are controlling the slope by limiting the slew. If, instead, you limited the slope, I’d expect that the output just wouldn’t follow the input any more and the amounts by which the input is “corrected” would all add up forever.

Sorry, this might not be helpful to answer your question.

Maybe someone else can explain better ....

There is, by the way, a simple explanation, why your first measurement didn’t match the true mathematical relationship between metro time and pitch (and therefore made it pretty much impossible to guess just by looking at the numbers):
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?
If you are interested in the effects of sampling more generally, you may want to search for “aliasing” or “foldover”. It’s an important topic in all of DSP, so it might be worth it.

@murkrellr Here is a slightly extended version of the patch, also allowing to randomly vary the time of each segment (which Xenakis described in his book "Formalized Music"). I hope my comments help to clarify the conversion from metro time to pitch: gendy.pd
I have to say I kind of like that dirty sound ...

@esaruoho You could also replace the select object in your patch by the logical operator [==] to got 1/0 instead of bang as output. That's how I would do it.

@manuels and @Obineg so I tried with opposite signs which was fun waveshaping weardness, but no 90° phase shift.

Hm, strange ... Did you make sure you only changed the signs of the feedback coefficients (first two arguments of biquad~)? I tried that, and it kind of seems to work: hilberto-test.pd

The reason for the opposite signs, as I understand it, is that in Pd the difference equation only uses additions. (Not sure if this is just a matter of taste or maybe a more efficient implementation.)
The topic is also discussed here: https://cycling74.com/forums/converting-pure-data-biquad-coefficients

I think the feedback coefficients in your hilberto~ implementation should have opposite signs (all positive). And yes, the second sideband seems to be a product of the imperfect orthogonality. With a perfect 90° phase relationship it should completely disappear. That's why it's called "single sideband modulation", I guess.

I can't open the video, but what you describe seems to refer to reverberators based on feedback delay networks (FDN). You can find a lot of useful information about this and other techniques in Julius O. Smith's "Physical Audio Signal Processing" book, including references to the original papers by Gerzon and Stautner/Puckette, and there is also a section about different matrices used in FDN reverberators. As for the implementation in Pd: Both rev2~ and rev3~ use Hadamard matrices. So you are guessing exactly right: It's just adding and subtracting/inverting delayed signals, and then normalizing by a factor of 1/sqrt(2) per stage. See also G08.reverb.pd from the audio examples.

As an alternative to [lop~] in method #1 you could also use [slop~] ... just came to my mind.
Edit: Hm, I don't know ... But you should definately try a higher-order filter like [butterworth3~] in the Pd audio examples! It will do a much better job removing high frequencies.

@MarcoDonnarumma Sorry, I should have explained ... So the "samplerate" should be that of the incoming data, 500 Hz or whatever it might be. And [tabread4~] will then convert to Pd's standard samplerate. Maybe there is even a way to drop the metro and use the incoming data as a clock, but I'm not sure if this can possibly work without timestamp. Good luck and thanks for sharing your efforts with us!

As far as I know, [sig~] only changes at block boundaries, so it's not really useful for converting fast changing numbers to a signal. You could use [vline~] instead, but I think @jameslo's array solution is probably more suitable anyway. Here's how it can be used in "real time", that is with a min. delay of 2/"SR" for 4-point interpolation (in your case 4 ms). upsampling.pd

@jameslo That's quite an issue here, indeed! I think, it could be fixed by putting the wrap~ into the loop (which is, of course, a bit more expensive).
@whale-av Hm, I guess it can somehow. The way I tried might not be the most elegant and I'm not sure if the phases remain in sync over time ... (probably not)
So here is another try: phasor-unwrap2.pd

Isn't phasor~ itself simply a wrapped line? So what about unwrapping it? phasor-unwrap.pd

@teakaytee Sorry, I can't open your patch ... But I guess you just have to do exponential instead of linear scaling. Maybe something like this: delay.pd