Nice to see this has triggered a discussion. I will be the first to admit that I don't know what this is for. As with most things AI, this is a solution in search of a problem. Here are the examples that I have provided in the repository:

1. LSTM/GRU emulation of guitar pedals (this is the same inference engine that is used in Proteus and Aida-X guitar distortion modeling engines - you can even load those models with rtneural~)
2. RNN note and rhythm prediction
3. Multi-layer perceptron as control (similar to FluidMLPRegressor)
4. Mult-layer perceptron as a wavetable oscillator
5. GRU sine wave to saw hocus pocus

RNN distortion and RNN time series prediction were, as far as I know, not possible before in pd. They definitely weren't possible in sc, which is where I mostly hang out. Thus, people haven't yet had time to play around with them. And I think people will figure out what to do with them given the time. That is the point of the project: to provide a framework that will work on any network if you train it correctly and save it in the right format. If someone wants to build a WaveNet or AutoEncoder, they can train it in python and now they can run it on real-time audio or as data in pd.

The sine wave to sawtooth example is just there to show a magic trick that is really difficult with traditional dsp (btw - it isn't just a sawtooth, but is a band-limited sawtooth, which opens up far more possibilities). This is where much of the possibility lies - in dsp development. The guitar distortion models are the best example of the possibilities. Lots of development has happened in this arena because it is low hanging fruit that is highly marketable. To be able to contort a signal like these trainings can, with one object, is pretty amazing. What other kinds of distortions are possible? I don't know!

The other thing that could be very useful for people right off the bat is RNN time series prediction, predicting notes and rhythms or whatever. Siri is an LSTM, so we are all familiar with this technology. As far as I know, this kind of inference was not available before in pd.

Last thought - conflating the big tech LLM stuff with small-scale AI technologies is not correct. These are different technologies and different ecosystems. Their data sets, training times, trajectories and uses are completely different. This is a small-scale, open source audio project with no aspirations to take over the world. But hopefully it can open up some new possibilities in music creation and dsp.

Sam

@Blades_Prod said:

@whale-av thank you for your reply! I tried using the limiter and reduced the volume using [*~] however, this did not fix the issue. Overdubbing 'Track 1' does not have any distortion, but the rest do even though it's the exact same code in each track's sub patch. I genuinely don't know what else I can try lol.

In the patch you posted you are not overdubbing in Track 1 I think, as there is no feedback from [tabread4~] to [tabwrite~].

You seem to have a large gain on your [adc~] input...... 15 loadbanged to the input.
Maybe that is correct?... but..? 15 is a massive amount of gain and could be the source of your problem.

If you turn your track modules into abstractions then you will be able to see your input meters while you are working..... like this... wall.zip
The disadvantage (maybe) is that they will all be the same.... change one and they will all change.
The $1 within [track] is the argument for the abstraction...... 1 2 3 4 for the track numbers.
I have added an output meter as well, and because they are all the same they now all have feedback from [tabread4~] to [tabwrite~] (overdubbing).
You might be better able to see what is happening on the meters as you work.

The array is overwritten on every pass, so I cannot see why it should be stable for 3 overdubs and then suddenly distort on the 4th.

P.S. I noticed with your original patch that the input gain 15 did not seem to have loadbanged in every track sub-patch. Very strange.

No promotion.... I have just found that I did update to Pd Vanilla a looper that I built for a client back in the days of Pd extended.
It has only one "track" and it uses a delay line instead of an array. It has a visual metronome, and an audio click, and will automatically stop at the end of a pattern when the "Cue seen" button is clicked.
It might have some features that you could use although translating to an array based looper would take some time.
You might not get away with using the visual metronome for a class assignment.
I had found that keeping the [adc~] input low enough was the solution for stopping the patch from climbing to distortion...... PdLoop.zip
David.

@Blades_Prod You have put a [clip~] before your final output, and that will effectively create a "fuzz box" on the output when the audio signal exceeds +/-1.
Pd has a massive internal dynamic range, so it is very unlikely that there is any distortion before that point.
It would be better to simply reduce the final volume with your [*~] and [fader] combo, and remove the [clip~].
You could also put a soft limiter in place of [clip~]..... with a feed forward delay..... using something like [limiter~] and [z~] before your output fader (see the help file for [limiter~]).

The final output must not exceed +/-1 or your sound card will distort.

The feedback will be acoustic probably..... and headphones would help. If you are using a microphone and listening to the loop with speakers then there will be some of the previous loop fed back to the loop with a delay, and it will get very muddy very fast.
The 100% feedback from [tabread4~] to [tabwrite~] shouldn't be producing "feedback" as such.
David.

I'm having problems with a strange distortion sound a patch of mine is making, perhaps related to FFT processing.

The patch uses a preset system to change between settings. The system will mute the input to FFT objects during preset changes to avoid audio issues. However, when the preset changes I'm often getting a sort of distortion, which strangely clears up if I add & delete an object.

I've demonstrated it here:

My DAW is looping audio which is sent to PD for processing. The loop is on top of a preset change to demonstrate the issue.

Any clues as to what this could be?

@oid Not sure where the "character" in your filter with extra delay comes from ... It's probably some kind of distortion. To recreate this effect in a more controllable way you could set the resonance frequency to some percentage of the cut-off frequency, like this:

resonance-fix-extended.pd

For values smaller than 100 the resonance is somehow distorted. Try feeding the filter with impulses at high resonance to hear the effect more clearly.

I removed the arctangent, so there isn't any nonlinearity in the feedback loop, just the [clip~ -1 1].

Edit: Would it be more reasonable to set the cut-off frequency to a percentage of the resonant frequency instead? I'm not sure ...

@Schlamborius Pd audio out to [dac~] has to be values between +1 and -1. Outside that range there will be distortion with most soundcards (there is a very tiny margin of leeway).

As you are able to produce undistorted output I think that there is nothing wrong with the UDP stream.

You say that there is no distortion when Pd sends very low levels to the [dac~]...... maybe when there is distortion those values are outside that range, and so the only option is to increase the analogue levels post [dac~] if you need to listen at a higher volume.
You can use [print~] to see in the console the values of 64 samples as you bang its inlet.
Let us know what you find.
If you want better resolution for post processing you can send 32-bit (see [udpsend~-help]...) but feeding the dac 16-bit is good enough for humans.
Pd internal processing is 32-bit floating point.
David.

@whale-av thanks! I finally managed to send audio from Python to pd, where i can receive it. the problem, though, is - that the audio i send (I use some music for testing that i send to python thru virtual sound card) seems to be distorted when played out from pd's [dac~] unless its played at a very low volume. Any slightly higher volume turns the sound very fast to distorted noise. This seemed to me to be a problem with unmatching bitrate, but I didnt find any proof for this.
What I have managed to find out until now is, that in order to send the audio from Python to pd [udpreceive~] object, it is necessary to send it in a certain format (which i found out by receiving data from [udpsend~] to Python) - the format being two alternating messages sent together - first one containing "header" - set of 24 integers somehow defining the bitrate, channel count, chunk size etc., second one containing one chunk of audio data. I dont understand much the meaning of the 24 integers, but what i did is that i sent 16 bit audio with 512 blocksize thru [udpsend~] to Python and copied the header to use it for reverse direction (which i need). I send the data thru pyaudio in a 16 bit format and use the header I copied from [udpsend~]. Even the [udpreceive~] help file shows the incoming audio format as 16 bit, so I suppose it is not a bitrate problem. Do you have any idea why this is happening? thanks.

o I connected the UGREEN to my Pi and selected it (USB Audio Device (Hardware)) as an output on my pd.
Same problem as before. the audio distorted at unity gain (I'm multiple the audio playback by 1 and then send it to the dac~
In order to have clean sound I need to multiple the playback audio by 0.1 - 0.05. I don't understand why is happening?

Could it be something with my pi audio setting?

Thanks

edit: I connected my Motu ultra lite mk4 and the output is not distorted even when multiple by 1 (as it should be)
So I can assume the USB Audio Interface I bought is just not good enough?

What you can recommend me for small audio interface with stereo output? that for sure is not distorted the audio...

Now I'v got it ..( I hope )
The line~ into sqrt does phase distortion
I compared it with ( cyclone ) kink~ (phasor into kink~) which adds a variabe breakpoint to the linear ramp of the phasor
First screenshot shows phasor into sqrt~(upper ) and lower phasor into kink~ .
Second screenshot shows both outputs (left sqrt,right kink ) multiplied and into separate cosines .
The cosine when driven by kink ~ is obviously played a higher pitches before the breakpoint ( steeper rise ) and a steady lower pitch .after that . ( when using mul*)
The sqrt ~ becasue of the conitinous rise has a fallen pitchbend
Always worked with phase disrtion to distort ramps into lookuptables , kind of asurprise its capable of pitchbend

I have a patch in pd playing an audio files. the audio itself is not distorted and I'm output it at unity gain (multiple it by 1 before connect it to the DAC

the output sound using the pi 4 audio jack out is completely distorted. I needed to multiple the audio file be 0.05 instead of by 1 in order to have ok sound (that is not distorted)
Clearly something is wrong. What shall I do in order to fix that? Maybe it is something in the pi audio out configurations?

Thanks