@oid I had a bunch to deal last week with so i'm just getting back to this. Prodding around with slew in the feedback of my ladder code ended up being quite weird and perhaps a bit to sensitive to dynamics. I don't fully understand why but it sets off a very strong and weird sounding self-oscillation at higher resonance if not carefully tuned. Sound good at some volumes but absolute rubbish at others.. I don't think it is that missing link i've been looking for.
Regarding the formulation of ladder filters i find that stacking 4 one pole filters gets closer to the real deal than for example using 2 biquads. Especially of we ad some "random tolerances" by offsetting the cutoff frequency of a couple of poles as well as introduce some slightly asymmetrical clipping between stages. But it is hard balancing these things I think the most important aspect is probably finding a balance between the clipping points of the feedback and the "filter". I'm actually surprised by how close one can come to authenticity with just a little clipping in the right places. It's just that illusive last 5-10% or so that is just bugging me endlessly

LTSpice is definitively available for OSX, it just looks a bit different. My guess is that chematics are allso cross-platform, but i'm not well versed in the software. Best of luck with your endevours!

@oid Just to clear things up, I don't use in ear monitors intended for live use, I have a couple of different models from AKG, Bang Olufsen, and some big asian ones. But your point still holds i guess.
That work on transistor ladders sounds very interesting! I do my work on mac, are LTspice models not cross compatible?
A big difference between slew and recursive filters is that slew does not alter phase afaik, so one can add slewlimiting to the feedback of a filter without things getting to whack. My initial tests didn't show any revolutionary changes in adding slew between the poles, but it does give a nice effect in the feedback loop. If you have a favorite ladder implementation in pure data I would love to try it

Highly appreciate your answers I guess it's hard to find one definitive answer but I feel better about my assumptions at least.
An additional detail in my case is that I almost exclusively use in-ear monitors, i think that could make a difference as they probably face all kinds of resistances in trying to pressurize the ear in one direction and the body of the earbud in the other. Much like closed back speaker cabinets vs open backs.. My Genelecs are banished from apartment use but I think I have to do a comparison next time I have some time over in the studio
I kind of wish I had some old synthesizer that could produce both directions of sawtooth waves to see how they compare in an oscilloscope.

@oid slew is such a powerful phenomenon that is quite new to me. I've found that incorporating slew distortion can really bring a digital synthesizer that extra bit towards that illusive analog warmth It's just hard finding data on it.. I've been working on a "ladder filter" that has some burn to it from just clipping but maybe the slewlimit of the transistors could be what it is lacking. Time to look up some datasheets i guess
And speaking of which, I recently modified Else's "slew~" to limit with a atan function instead of hardlimiting. It doesnt make a huge difference but I imagine it "softens" the effect a bit.. I'm still a bit new to coding for pure data so i'm sure there is some dead code in there and whatnot left from the original, i wasn't planning on sharing it really. But in case that sounds interesting I'll share the source: softslew~.c ((Inlet 2 or argument is "gain" and just multiplies the input + divides the output. Things start to happen at around 25 gain with unity level in..))

Goodnight

Has anyone else noticed this? Isn't it a bit strange? I wonder if it's hardware specific and due to that some speakers work differently in the two directions so to say. Or do healthy ears actually notice a difference between the two?
I sometimes imagine i can hear differences from inverting the phase of the master bus in a DAW but iv'e always just shrugged it off as some artifact or auditory illusion or whatever, but this phenomenon just keeps bugging me. Or are my ears shot and i pick up pressure better in one direction? Or is this some artifact introduced by pure data that has got me confused?

Help me find my mind

I threw this together a couple of weeks ago and have found it to be a nice and useful saturation source.

The theory and implementation is based on the hysteresis emulation in Jatin Chowdhury's CHOW Tape plugin as presented in this article https://dafx2019.bcu.ac.uk/papers/DAFx2019_paper_3.pdf .

The code is then founded on ggee's moog~, because i'm pretty much clueless in C# and needed a starting point.

I'm not sure how to give "proper" credits so i hope this doesn't step on any toes.

There are also some 'original' parts to this so I will claim some credit. It took a lot of trial and error to find the best interpolation and filtering methods and to make it stable and sonically pleasing. I think about 500+ builds after all was said and done..
NOTE* This is fairly stable but i've noticed that it can get a bit upset sometimes and need a reset right after loading a patch. Don't know whats up with that but you can work around it by, for example, using 'threshold' to trigger a reset.

It's only tested on OSX but the makefile should work on other systems.. Just navigate the terminal to the correct folder and "make hysteresis~"
and you should be GTG.

Hysteresis~1.0.zip

A very fast and simple method i almost always use is writing tables in the audio domain.
There are examples in the docs that showcase this, one i can remember is the one about transition splice oscillators...
I'll include a slightly descriptive version of my goto setup: tablewriter.pd
(That uses a couple of audio-maths objects from externals for shaping the slopes i'm writing, but if you are using extended those are probably included in your library.)

The one flaw with this is that you will start loosing 'accuracy' with bigger tables. if you are writing a 500'000+ index table you will need to fiddle a bit with the frequency and phase onset of the phasor~.
But for fast prototyping with transfer-functions it is a very good, and fast, alternative!

Happy hunting!

@artureczq thanks for the heads up!
A completely unrelated question, how is your general experience with the M1's ARM architecture? Do you need to make any externals yourself? Or do the arm compilations on deken work?

I haven't seen this method posted anywhere so i thought i'd share it. It doesn't alias audibly, within my hearing range at least, at 96k sr.

It works by clipping the peaks of the wave and replacing them with a sine function.
Theres some maths involved in scaling it with frequency, and patching the triangle and the sine parts together, but nothing too heavy. Uses under 1% cpu per instance on my 2010 mackbook, at 96k.

Note.
-I scaled the cutoff frequency (Above which it outputs a pure sine wave) for a 96k samplerate, so that might have to be adjusted a bit for lower rates. Just play with the cutoff constant (now 18800).
-The overall amplitude diminishes as the frequency increases. Because i prefer it this way.

splicetri~.pd splicetri~-Help.pd

edit. Apparently abs~ is from zexy. It will work without it, but won't handle negative frequencies correctly..

Oh yeah, if i would experiment further i might try having a lowpass filter in a loop set at something like 1/8th or 1/16th of the fundamental frequency, and then use a multiplier to compensate for the volume loss (and some transfer function to save your ears when it inevitably blows up!). As you probably know, a lopass filter is basically just a 1 sample delay loop, so you could probably use that fact in some way.. Please share what you end up with

I was inspired to put something together you might find useful
KStest-Booberg.pd

The big thing there is the impulse generator, it generates one cycle 'waveforms' with a period according to the frequency. I made one that is continuously variable between saw and triangle
In the example the delay time was controlled at control speed, using smooth signals to control the time removes the ugly glitches when changing pitch.
Also, if you want to use noise to exite the loops you might try using brown noise instead to get more low en out of it

Now, i've never messed around with 'KS' and don't really follow what is happening, so i might be completely off topic here. But if low frequencies start making things unstable or crunchy in bad ways you might want to try doing what is often done in analog circuits: Shelf or cut low end at the input and boost it back up at the output. The clip sounded very cool, love a crunchy bass-synth

I was in a rush last night.. I removed some junk, fixed some filter phasing and corrected a mistake i made with the Hysteresis subpatch. Sounds pretty tight now IMHO.
After a quick rundown i think its just dependant on two externals, Zexy and Else.
z~ , one sample delay, from Zexy. And lag2~ + glide2~ from Else.

I hope someone finds this entertaining I recommend using a cabinet convolution with this. I've used partconv from AudioLab (loaded with an ownhammer alnico silver IR) on the recording of the attached sound sample.

ThurboDriveGuitarV2.mp3 ThurboDriveGuitar2.2~.pd

Oh now i see "dA" and some "number~"s in there.. that stuff shouldnt be there so i might have beefed it and uploaded the wrong file or something. I'll take a look at it tomorrow.

I don't really keep track of that im affraid.. usually keep to else, cyclone and maybe brickwall is from audiolab? If i wasn't lazy i think all those tanh~ objects are in there for writing tables for the transfer functions.. im not so sure how precise or heavy they are to run so i usually stay clear of them.. it's very possible to change those for a mathematical equivalent/approximation. And the brickwall~ is just for anti aliasing when downsampling so you might use other filters for that.

I actually continued working on this for some time, specifically for guitar. I didn't really reach all the way i was hoping to, i found that it's hard to induce "shimmer" digitally... alas, i might upload the results during the week.
Ps. A big facepalm moment when i realized that my 'pseudo-integration' method is really just a naive lopass filter with a bunch of gain :,) so that saves a lot of cpu for V2 atleast..

Cheers

This is my best attempt at a "vacuum tube" style overdrive.
(Edited)
Look below for the latest version. This relies on Zexy ( for simple single sample delay) and Else. The only thing i could not easily build in vanilla was the Hysteresis emulation, which relies on lag2~ and glide2~.

This older version is quite different and messy. Mostly experimentation.
ThurboDrive~.pd ThurboDriveExample.mp3

I'm wondering if there is consensus in what effects "turning subpatches on/off with swtich~ objects" has, mostly in terms of cpu-spikes.
I'm pondering if "turning off" modulation sends/receives, controlled by a modwheel for example, would be computationally beneficial. This would mean that the switch~ could trigger fairly often, and be "on" for short durations.
So the question is:
Do switch~'es operations cause spikes in cpu-usage in a way that would make this kind of thing counterproductive?
A lazy secondary question: Is it reasonable to expect switches to respond smoothly in a real time application? Will there be a delay noticeable delay or are they pretty much instantaneous? (a 64s block or two is to me fully acceptable).

Cheers!

Don't know what to call this really. I put this together to prevent unwanted control changes after loading presets. A useful utility for hardware-controlled patches with presets.

-Inlet 1 passes control signal to the outlet.
-A bang to inlet 2 activates the temporary threshold/gate.

After activated, no control changes will pass through until a change that exceeds the threshold value is registered. (Relative to the control value at activation).

-(optional) Set threshold through inlet 3. Default is 10.

Example:
*Control signal through inlet 1 is at 50 when gate gets activated with a bang to inlet 2 (threshold set at default value, 10).
*Values of 41-59 will not pass through.
*A control signal <=10 or >=30 opens the gate.
*After the gate is opened, the control signal passes through until another bang is sent to inlet 2.
TemporaryThreshold.pd

If there is already an abstraction or external out there that does this in a better way please let me know

Noticed a possible source or errors, if the 'float-box' were to send its value to the hot inlet of the 'subtraction-box' before it does the cold inlet. Not a problem on my system but this might be safer with a trigger to make sure..
Cheers!

Here we have it! I didn't test it all to much but I think it's fairly robust. Maybe it could be done in a simpler way? I added that "middle" spigot to hopefully keep it from doing redundant computations when not active.

TemporaryThreshold.pd

@whale-av

That's food for thought! It isn't enough for the application as is (since it's impossible to know how far or close any of the controls might be to one of the "threshold values" so to say). But here's the plan. If i save the current control value at the point of loading i could then take the value of the difference between the "real" controller value and the saved one and apply that suggested threshold method, connected to a spigot.. I'll be right back with a patch.

Thanks for helping out again!