My first patch, would love to hear thoughts on coding style/efficiency. Plays fine in vanilla but GUI is optimized for Purr Data. Looking for tips on how to run two instances in the same patch without running into duplicate problems with the control arrays. Do I have to open up all the subpatches inside to use $0 in the array names to keep it local? Thanks for taking a look, let me know what ya think.

pop these guys in the same folder and open summer to check it out:
summer.pd
addosc.pd

@HollyB I am near useless with pd audio so I can offer no help there but it seems to work and I am having fun with it. Best to ask technical questions in the tech help section of the forum, such questions rarely get answered in the patch/abstraction sections. Your input setup can be troublesome as it always responds to all midi channels. [pdcontrol] makes it possible to have a more elegant setup. With something like this you can call your abstraction with [summer 5] and it will run summer on midi channel 5, or you can turn midi on/off by sending the messages [midi-on{ or [midi-off( and you can change the channel with [mchannel #(. If you load [summer] with no arguments it turns off midi input and uses the [inlet] only.
midi-in-args.pd

It's sounds GREAT, but very CPU heavy.

@oid Oh cool! Thanks for the tip, hadn't thought about channel conflicts I'll definitely implement this.

@tungee Thanks for the feedback, I was worried about that. I've been trying to figure out how to get some [switch~] objects in there to kill inactive voices to lighten the load.

@HollyB Looks like I had a slight error in that patch, forgot to set the initial states for the spigots so it fails if the abstraction is called without an argument. The right one should be [spigot 1]. Not sure why I used [pdcontrol] for that, it is not really needed here. Lots of ways to do it.
midi-in-args1.pd

I took a shot at optimizing a bit. the main patch looks good but in addosc there are a few little things (which may add up bc you have 224 of them):

[tabread~] is taking a control-rate input. So, it isn't doing anything that [tabread] couldn't do, and have it translated to a signal later down the graph instead. The difference is that [tabread~] will still process the last input every sample whereas [tabread] will only output when it gets a new message. (so you'll be doing about samplerate times fewer computations if you have a new input every second)

similarly [+~ ] and [*~ ] are more efficient if you use the versions with a control-rate right inlet bc the loops can be vectorized and maybe predicted better. (to do this supply them with a float argument).

generally the arithmetic objects are more efficient than the [expr~] family. And, [expr~ 1 - $v1] is also another case of not needing the signal version bc the input is control-rate (after changing it to [tabread]). Instead you can change it to [1 $1( going into a [- ]. (tho in this case idk if it is actually better than [expr 1 - $f1] bc we also have to process/send the list from the message box.. the main thing is making it control-rate tho)

The final little thing is replacing the division [/ 127] in the adsr subpatch by multiplication with the reciprocal, bc processors are better at multiplying than dividing. You can do this any time you're dividing by a value that won't change.

hope it helps
addosc.pd

as for locality I think the only way is to use $0 in your arrays like you say.. you might consider making addvoice an abstraction as well. Then you could supply $0 as the argument, and inside supply it as the 2nd argument of [addosc] with $1, which could then use it as $2 in the [tabread]s to refer to the grandparent's $0

that way you'd only have to edit 28 [addosc]s instead of 224

@oid This is super helpful. I'm not great with the control level logic stuff and learned a lot from looking at how that patch works.

@seb-harmonik.ar Amazing, thank you for digging in and poking around. Those changes were very helpful, lots of stuff I didn't know about. The [tabread~} objects were for a feature I was considering that would modify those arrays while the note is active but I'll try a different approach because the performance gains were significant after changing them out.

Also thank you so much for explaining how to pass arguments like that. I didn't know that was possible and it worked perfectly.