@cfry I think variables might be the best way to go about this even though they do not give you your easy to read argument, but you can just use the name of the text to show that and have the text as an argument? You could also use a single text for all instances, have each one execute just the code that is relevant to them, this has the advantage of keeping it all in one place and you will never have to remember what was in the other texts but you could end up having to scroll a whole lot more. Could also go with a startup script which all instances in a patch would run at startup, a way to setup the environment and create globals, setup initial state of each, load programs into them, etc. Having a master instance which controls the rest might is also a possible solution, like the control track some trackers have, it would be able to feed each instance shared values and then they would react on that data as their code tells them. Other solutions I have come up with move things away from the tracker style and towards it being a scripting language, so it would greatly change how you interact with the abstractions and your entire workflow, which I am not sure you want to do?

I should have time to get my computer setup tomorrow so I can get back to patching, on Friday or Saturday (assuming thing go well with the computer) I will throw a few demos together for you to play with so you can get a better idea.

Or maybe just have arguments be code, at startup each instance runs their arguments, then you could do numbered groups with an if statements or a case statement, that would probably work best with the startup script idea so you don't have to have the exact same thing repeated in every instance.

@oid I fixed the loop as per your instructions, works fine.

My primarily reason for this patch is to have a specific performance set I do technically solid, and updatable. So that I will use "[tracky]" for but I do not want to hinder your ideas (and mine) with this purpose. I want to keep it open and see where it goes.

That said here is an explanation on how I use it:

this video show the interface and how I perform with it:

(at 11:47 maybe it is easier to see what is happening, starting and stopping)

The coil springs you see act as switches (short ground to digital inputs of four Arduino). I control them by hand and by adding weights to get different pulses. In pd the switches have their own logic, how they affect the synthesis. In the default mode there are no automatic triggering at all, it is just me starting and stopping pulses.

This is how this part of the patch looks. [r chs-$0]-[route 25] etc are the incoming pulses. The subpatches with "graph on parent" like [pi-cy] (=pitch cycle) and [piAdd2] (=add pitch) are what I want to replace with [tracky] (probably will rename it later btw. Depending on what it becomes!)

So these boxes all do "hard coded" functions that you edit with number2 atom that are set to retain values upon save. The benefit with this setup is that I can just copy these around even between patches. It is not totally bad, you can work quick with it and improvise it. But I think it is awkward to edit afterwards. I just believe [tracky] will be better for this. If I can load the text file with commands as an argument in [tracky] I can name the text so I can see what it is meant to do. One way to do it.

But what I am after is the functions, not this particular work flow or visual layout. I think of it that each of the switches (coil springs etc on the physical interface) trigger an independent channel as in a tracker where it trigger pitches and manipulations. This approach I like very much and intend to explore it further.

Current version of [tracky] over here: tracky.pd

...and sorry for being slow in response. I am moving between cites and it is chaos in general. In a week or so I will have more structure in my life.

@cfry Slow is fine with me and I am generally not going to exceed a post a day anyways unless I can just give a quick answer that I don't have to think about much. So the output of [r chs-$0] is a two element list, channel number and a one or a zero? What is the right outlet of your once? bang when reset or something else? are they how you are implementing groups? this screen shot is one group with two synths? I think I got a bit hungup on the tracker aspect and was not quite seeing what you were trying to do. We should get this sorted out quite nicely after a bit of a Q&A and get you a more flexible and dynamic setup in the process.