When I attempt to play the karplus strong formula (With a modification or two) at 392 and many other lower frequencies it works as it should. But when I put any number above 698.456 no sound is outputted.

@Joseph-Mikkelson maybe it has to do with the fact that you have a [vd~] going into a [delwrite~] at a block size of 64 samples? (so for that part you might need a subpatch with a block size of 1). (see the help file G05.execution.order.pd)
Another thing it might be is if the delay is sending [*~ ] 1 and 0 within the same block. In reality, messages are only processed every 64 samples, so they are sent to the object but then when they get to the audio processing part they "write over" each other (because the delay is so short). So it will just send [0 ( to the [*~ ].
here's my solution: use [vline~] instead of [delay] (here's my own karplus-strong)

Thanks! although I am a little confused on how that changed it everything works fine now!

@seb-harmonik.ar The screenshot of the formula I sent is now fixed, but I spoke too soon. I am putting multiple formulas together. And when I try to replace a few of my other formulas. None of the frequencies work.

@Joseph-Mikkelson Aaaaaaaaarrrgggh.
Your desktop looks like mine.

But you need to at least spend an hour tidying your patch.......
Drag things that really belong together about, and make them into small groups, maybe with as many vertical connections as possible, to keep it small and neat. I would start with the audio bits.
Maybe attach your bangs G4 C4 etc. to send objects [send G4] and [send C4].... etc,
Attach a receive object [r G4] to each message that G4 is sending to and then delete the strings.
Get rid of as much string as you can.
Then post again, but you might have then already spotted the problem.
David.

@whale-av

Only my first formula functions, the others do not produce audio

@whale-av F# C# and G# also do not work

@Joseph-Mikkelson The buffer error is easy to solve. You have multiple delay lines with the same name and you just need to make them individual so........ [delwrite~ buffer1 1000] [delwrite~ buffer2 1000] etc.
Change [vd~] as well to match and they should then all work.

I cannot see the $1 argument out of range error.
I would guess that something is receiving a bang when it expects a float but......

It is much easier to read now. Each delay line could be an abstraction, as they are identical, and more string could be removed using direct messaging.
For example the frequency number box for buffer2 could have a [r buff2freq] object attached and the message box [1901.88( could be sent into another message.....
[;
buff2freq $1(
.......... semicolon, enter, message address, dollar1.
That would send 1901.88 to buff2freq when it receives the frequency float from [1901.88(.

If you right-click the bang for the delay of buffer2 and give it a receive name buff2delbang.
Attach a [r buff2vol] object to the right inlet of [*~ 0.99] before the [dac] of buffer2.........
Then a message.....
[;
buff2freq $1;
buff2delbang bang
(buff2vol 0.5(
...... will send the frequency and then bang the delay, and then set the volume to 0.5.

It is very hard work for us to problem search an image of a patch.
If you upload the patch rather than the screenshot then we don't need to make it again for testing.
David.

@Joseph-Mikkelson Use find last error from the find menu or clicking on the error message with control key (?) hold to find the source of the error

@whale-av Ukele sim.pd

@Joseph-Mikkelson That's great.
So I looked in [pd G] and separated out the very left hand part...... see...... [left part]
Then I tidied it up....... [left-part-tidy]
I left in the string / cord that looks like it might be a mistake.
Then I copied all the audio part into another patch called [buffer]
And then I used that to make a new left part........ [left-part-buffer-abstraction]
That "mistake"...? cord I have left out of the last patch.

In that last patch is [buffer 1 0]
The 1 is an argument, and replaces $1 in an object inside [buffer]
For the next (second) part you would use [buffer 2 0] and the delwrite inside would become [delwrite~ buffer-2 1000]......... and then arguments 3, 4, etc. so that the delay names are all different, and the messages receiving the frequency etc. are different for each one too.
That solves the buffer created multiple times problem, that you have solved already I see..

I have added a second argument to [buffer].
When it is 0 [buffer] will use [vline~] and when it is 1 it will use [del]
So actually for the 2nd part of [pd G] you would use [buffer 2 1] so that [del] is used instead of [vline~]

The $1 in the envelope message to [vline~] is receiving a bang when it needs a float...... I don't know what you intended there. The output of [expr] is sending the value for $1, and so banging the message through, and I don't think you need the extra bang at the same time.
A $1 in a message does not take the argument of the abstraction. It takes the first float or symbol sent into the message.
That is the $1 that is complaining in the terminal....... because it has not been sent a value, just a bang.

I hope that helps you to see where any other mistakes might be.
Abstractions are great. If you change [buffer] and save it then every copy will change, so if you want to add some effects into it...... that is very easy.... you only have to do it once.
all_that.zip ..... don't forget to unzip.
David.