@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