(working title) 2 dimensional chaos generator

[Architeuthis]

the final nail to the coffin: A sine under Nyquist and a DC value don't alias, but modulate the frequency or phase of anything and you're always technically aliasing. The sidebands are infinite, so some always cross Nyquist. Amplitude modulation and waveshaping alias too, unless you deliberately band-limit them. So alias-free is a razor-thin set: static, band-limited signals. Everything that moves: aliases, which means the real question was never "does it alias", it's "does it sound good."


the rationale: I've shown you can alias pleasingly, alias unpleasantly, filter it, or dither it. Aliasing becomes a design decision. Want it clean? Band-limit it (costs effort, sometimes a lot, but it's there). Want character? Let it alias nicely. Want it to just sound nice? Mask the ugly parts.

the universe's antialiasing filter is a singularity

[antto]

if you want to have aliasing that sounds good in analog(ue), then just make an analog decimator - run the signal thru a Sample&Hold, modulate it with 40kHz or whatever you like and enjoy

Yes, I've done that with flower child filter downsampled mode to demonstrate analog-style sample & hold (already implemented in soundemote.io/sandbox).

no, i think you didn't understand what i said
i meant "decimator" as in the decimator "effect" that intentionally does things wrong to allow aliasing
and i meant "analog(ue)" as in: electronics, circuits, real physical things, not some code in a PC... no "sampling rate", no circuit simulation either

because, do note that when you're making a decimator in DSP, if the "frequency parameter" of it is adjustable, then you have 2 different kinds of aliasing going on, not just 1:
1) the "desired" aliasing from the input signal "interacting" with the Sample&Hold (both the digital and the analog(ue) implementation will have this, of course)
2) the aliasing that happens (only on the digital implementation) from the sample&hold every time it retriggers and its output "held" value jumps, which can happen anywhere in time when the frequency is adjustable

[Architeuthis]

..

[antto]

Everything that moves: aliases, which means the real question was never "does it alias", it's "does it sound good."


the rationale: I've shown you can alias pleasingly, alias unpleasantly, filter it, or dither it. Aliasing becomes a design decision. Want it clean? Band-limit it (costs effort, sometimes a lot, but it's there). Want character? Let it alias nicely. Want it to just sound nice? Mask the ugly parts.

i've been on this side too since very long ago, except with a slight but very important nuance:

i agree that from a music/art POV, aliasing may happen to just be what works better for a particular case for a particular sound in the ears of a particular artist - "this has audible aliasing, but it's actually sounding good" - e.g. this is the exact reason why "decimator" effects exist and are quite often used especially in some electronic music sub-genres

but, the problem is not with the "decimator" effect since the majority (or all, if done right) of the aliasing of it is made intentionally... the problem is with the actual normal aliasing, like from when you're playing a .wav file with "nearest-neighbour", or running a naive ramp wave and LFO'ing it up near nyquist.
because, this aliasing depend on the Fs, and the Fs is a parameter the user is allowed to change.
e.g. the artist is fiddling with something (no matter how or what), and suddenly he stops touching - it sounds PERFECT ... and now suppose that some of that sound includes aliasing reflections, normal ones.. the problem is that if the artist (or someone else) changes Fs - the aliasing reflections will change too, and now does it still sound "good", or did some of the "magic" get lost? the fact is, it will sound different at different Fs

thus "in my book", if the user is allowed to change Fs, (the normal) aliasing should be either avoided as much as possible (what everybody does and all the books teach you to do), or there should be some info clearly in the documentation stating that there IS aliasing, and how to use it "reliably" ... sortof

for DAW plugins, Fs is unknown, thus i see (the normal) aliasing as a mostly bad thing
but for things where i'm in control of Fs and the user can't change it (e.g. in my hardware DSP thing) then i can allow aliasing to be usable as an effect

[antto]

all these chaotic-like math constructs, strange attractors and such - they are very cool and all, i've made some in the past too, the problem is that they are tied to the sampling rate, so according to "my book" (what i said in my previous post), they don't have too much place in my stuff

[Architeuthis]

..

[Architeuthis]

..

[antto]

antto, yeah — we're on the same page, and i think there's a cleaner answer to the Fs-fragility part.

that fragility is really a parameter-coupling problem: changing Fs unintentionally changes the aliasing — a parameter the user never meant to touch. the fix is to make aliasing a first-class, controlled parameter instead of an accidental byproduct. X shouldn't move Y unless you want it to. that's just instrument design.

and for the specific "Fs changes and the magic is lost" case: make the aliased sound Fs-independent. resynthesize it additively — place the partials where the aliasing would land — so it sounds the same at any sample rate. that's what my antisaw does: the aliased character, generated so it doesn't depend on Fs at all.
---
⬆ AI

im sorry, im using ai to reply now, because i just "cant" anymore. im going to bed. it's either the AI reply above or my human reply below, you can choose which one you want to read, im out.

P.S. NO IMAGES WERE GENERATED BY AI IN THIS THREAD, ALL IMAGES ARE FROM PRETTYSCOPE USING CHAOTIC ALGORITHMS

⬇ HUMAN
---
antto, i need you to hear this: you stated a problem, i gave you the solution, and your conclusion is: not for me

if aliasing sounds pleasing and then the user changes a parameter which changes the aliasing,

first: i am fully aware of the problem.
second: i am also fully aware of a solution.

solution: stop changing multiple things about the sound at the same time, it's a dimensional problem of too many parameters in the sound being changed when the user didn't want that. a user wants to change X without changing Y, that's instrument design 101, aliasing is a parameter now.

edit: or, more accurately, for this case: change X and Y relationally.

i thought i'm talking to a human, why is there a chatbot in the conversation? (are you held against your will somewhere? (do you need help? (should we call 911?)))

alright, i was trying to discuss things, seems you do not need it, i get it, you have big plans, big projects

[Music Engineer]

I love the pitch dithering

Try using a single pitch-dithered sawtooth wave and pass it through a waveshaper (without oversampling!). The result is still a pitch-dithered, "anti-aliased" waveform. The (pseudo) anti-aliasedness of pitch-dithered waveforms survives waveshaping!

[antto]

Architeuthis: too bad you couldn't act chill and that other thread vanished, so i'll respond here
(this is my non-scientific explanation)
((if it seems too long - don't read it))

a 1-sample "spike" doesn't "alias" .... a signal that has a sample of value 1.0 and then all other samples are of 0.0 is perfectly fine

i think you are confusing some things here so let me try to give you a simple point of view:

a digital/sampled signal is "fine" ... there is a mathematically perfect way to convert it to a continuous signal, and a mathematically perfect way to convert the continuous to digital

sinc() - you should get familiar with this function/curve, it's so magical and it's entangled with many of the other funky math functions

when you look at sinc() you may wonder wtf is this, it's like some sine wave which at 0 peaks to 1.0 and decays out away from 0, so what's so special about it?
- if you scale this sinc the right way, the places where small oscillations cross zero will align at exactly the integer values of x (that is your time axis usually) ... in other words, this is your 1-sample spike - it's 1.0 for one sample, and for all other samples it's 0
- ideally your 1-sample spike digital signal converted to a continuous signal will look exactly like the sinc() function
- sinc() is the IR (impulse-response) of the ideal brickwall lowpass filter (think about this)
- sinc() is fundamental for digital signals
- in a digital signal, the samples are actually weights for the sinc() function ... take a wav file, for each sample - multiply a whole sinc() function by the sample value, and sum the results together - that's how you get the "values between the samples"

remember that waveform displays usually don't show you the truth, when a waveform is shown with straight lines between the samples - that's maybe not far from the truth when the signal doesn't have high freq content, but as soon as you have high freq content (frequencies close to nyquist or sharp transients) - then those straight lines are plain wrong... showing the truth will be expensive, the simplest thing is to show just the samples as points, but usually that's not too cool and people will naively want at least straight lines between them - and this is what we usually get, just don't forget that it's not correct.
the correct way would be to do it properly, you have a .wav with some sampling rate, and you wanna display it on screen - well, altho the screen is not a speaker, the correct way is to still resample it, you want to display it at some "zoom level" (in the time axis) ... you already know that when you use linear interpolation for audio resampling - that sounds bad particularly on the high frequencies - well, is it surprising that drawing lines between the samples on the waveform display is wrong too?
it's that doing proper sinc() resampling just to display the waveform on screen would be... heavy on the CPU, remember you usually wanna be able to quickly zoom around, that would need re-resampling again and again... so probably no program does this... so we get straight lines

ehm, so the 1-sample spike is a sinc()

it doesn't "alias", this doesn't make sense at all
but i think i know why you said it:

aliasing happens when you break the sampling rules - like, if you run a sine wave faster than 0.5*Fs.
once that signal is sampled - everything above 0.5*Fs becomes restricted between 0 and nyquist due to the way things work
once this happens - you can't do anything.

frequencies above 0.5*Fs cannot be represented:
the highest frequency you can represent in a digital signal needs at least 2 samples per period, here's one such signal:
+1, -1, +1, -1, +1, -1, ....
this can get reconstructed perfectly as a sine wave (or maybe a cosine wave) and it's frequency is - guess what - Fs/period_length == Fs/2 == 0.5*Fs == "nyquist"
the moment you try to make the sine wave run faster than this (without any kind of bandlimiting, just naive math) - the result you would record into the signal would have values which will not reconstruct to your "intended" sine wave

aliasing can happen in other ways too, but those are more complicated to explain
just one example: when you apply a nonlinear process (say, a hard-clipper) over a sinewave that has a frequency very close to nyquist...
hint: synthesize a sine wave at some frequency very close to nyquist (or synthesize a slow sine sweep that is entirely up there near nyquist) - then zoom in and look at the samples, you will see how things look "weird" and irregular (this kinda depends on the particular frequency), you will see at some periods of time that a bunch of samples seem to be going more positive while at the same time - the negative samples seem not "as tall" (yet, sin() is symmetric), so it looks like at those times the waveform is more positive biased, for a duration of many samples, and then some time later it similarly goes looking more negative...
and yet if you do all the perfect sinc() reconstruction - the uglyness will be gone and you will get the perfect sine wave you originally intended. no sign of what looked like "bias".
so, this "uglyness" is only an unfortunate visual artefact of the samples being weights for the sinc() function, and as i said earlier - when the signal has high frequencies - the "values" between the samples are very much not straight lines, and the samples themselves don't "intuitively" tell you how the continuous signal looks like
and now, when you toss a hard-clipper over this - you f*ck up the magical weights in a bad way - if the signal had very high freqs - the non-linear process over them has worse effect...

to say this another way:
every sample is a weight coefficient for a sinc() impulse.
- if the signal is a DC offset - throwing it into a nonlinear function would give you the right result (that's boring tho)
- if the signal has low frequencies only - throwing it into a nonlinear function will result in kinda wrong results
- if the signal has very high frequencies - throwing it into a nonlinear function will mess up the weights big time and the reconstruction will not give you the result you wanted