I am working on a Noise Generator that uses the Linear Feedback Shift Register algorithm, but I am stuck. LFSR was used for the Noise channel in the NES and GameBoy, and that's the sound I am going for. LFSR generates a pseudorandom sequence through bit shift. The feedback loop works like this:

You start with a fixed-length register as the seed (I am using 15 bits in the example). And then, every time the LSFR is triggered, it does the following:

XOR bits 0 and 1 (the two right-most bits in the sequence)
Right-shift the sequence (It's now 1 bit shorter)
Put the XOR result into the empty last bit (the left-most bit)

I got it to work in Message Land with no problem:
[Left: verbose version - Right: condensed version]

But I am stuck trying to move this to signal, mostly because I don't fully understand fexpr~:
I guess I should use fexpr~ since I am using feedback here? Also because every bit in the sequence corresponds to a sample and I need to look up earlier samples to generate the next step (Again, guessing). I am also unsure about the difference between $x and $y. I am guessing I would have to use $y too for this, not just $x. But how do I send an output back as an input, to keep the loop running?

Here's an attempt at converting the above message version to signal, but it obviously doesn't work (I stubbornly tried to connect the right-most outlet to the left-most inlet but that gives a DSP Loop Error of course):

I would also like to be able to control the clock speed for this, but that would probably just be with sample and hold once the main part is done.

Here's the patch so far:
lfsr_expr_stuck.pd

Thanks for having a look!

And here are the websites I used as sources if anyone is interested:
https://gbadev.net/gbadoc/audio/sound4.html
https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware
https://www.mjsyts.com/development/lfsr-noise-part-1/

If you want to feed your signal back to the same object, you must use a [s~]/[r~] pair, otherwise Pd will correctly complain about a DSP loop. Also, I don't see any real reason for using [fexpr~], as you only reference the current sample of the input with x1[0]. If you did something like x1[-1] to reference the last sample. it would make sense, but the way you wrote this, [expr~] with $v1 should suffice.

@Ice-Ice Ha! I went down this same rabbit hole but I was thinking about the TR-909
https://electricdruid.net/tr-909-noise-generator/
and I didn't use fexpr~ or expr~. The algorithm definitely requires feedback.
TR909 LFSR.zip
It might not be the most efficient way, but I like how the patch looks like the circuit.

Edit: Thanks for the fun problem. I tried to make the example in the last link you posted using [fexpr~], see what you think.
srNoiseFexpr~.pd (use [metro~] from the zipfile I uploaded earlier)

Edit 2: Hmm, there might be something wrong with the expression for the first outlet of fexpr~. See how it references the last value of the 2nd outlet? I don't think that value is calculated yet, and so it's using 1 sample old data. Maybe I should've xor'd the 2 bits that are 1 bit to the left?

@jameslo Thanks a lot! I really appreciate your help. I have spent quite some time now looking at your initial 909 version (always takes me a bit to understand code written by someone else). I like the approach you're taking in the [shiftReg16~] abstraction, this makes all the taps accessible which gives some flexible routing possibilities for trying different combinations.

Now I'm looking at your edit. I think I am finally understanding how $x and $y are related! So $x and a $y of the same number are the respective input and output of the samples in one block of a discrete "stream", and then $x2 creates a new, separate stream of samples and so on (stream might not be proper terminology). So now I also understand why the fexpr~ version doesn't need a block size of 1 (which your 909 version requires).
And I can see what you mean by using 1 sample old data, it would indeed be the case. It does sound right to me when I listen to it though, but then, my hearing isn't sample-accurate Thanks for this, I've come a bit closer to understanding fexpr~ now through your help, never used fexpr~ before.

@alexandros I understand what you mean, it was a naive attempt at porting from the message version to a signal version. I think I will try an expr~ version to see if I can make it work, thanks for your input.