@oid I have to return to treating variables. However, I would be fine with just editing a preferences text (the "registry"?)

@oid said:

Not sure what you mean by groups/exclusive groups, can you elaborate or show it with a patch?

Its midi programming language sort of, usually used when programming percussive instruments. If you have one closed and one open high hat you would like these to cut off each other. Not "poly". Same could go for the cymbals. So each of these would get their own exclusive group. High hat exclusive group 1, crash exclusive group 2 etc.

In my case I may have several instances of [tracky] (with different text files) triggering an fm synth. Here I want to have one or all of the variables to be shared. I may have a granular sampler controlled by several instances of [tracky] (with different text files), also sharing variables, but using another range (ex. 0-100, the fm synth using 0-1). The grain sampler also want its variables to be global, but not shared with the fm synth.

I could solve this by using different named variables for these different groups of global variables. But this will be convoluted and hard to get an overview. I think it may be better to use abstraction arguments to give them different groups: [tracky 0], [tracky 1], and [tracky] for not sharing variables at all.

This hotfix make the loop work as intended but just keep adding to the stack.

Could it be that since [v] does not output anything until it get a bang problems arise?

Also not sure how the stack is supposed to work in this case.

@cfry The variables are much simpler than they look and the general technique I used to implement them is a very useful one, you can also use it to implement arrays and even functions.

Completely forgot about midi groups, your idlewait subpatch now makes sense. Believe I am going to think on this one a bit, the way I deal with such things would be to use tracky for generating the modulation tracks ahead of time instead of playing/creating them in realtime so I can do everything in a single instance, but I don't think this is the solution for you? you want something you can interact with more directly? You seem to be going more towards a sequencer/programming language hybrid, which seems fun, especially when you bring in multiple instances. I think implementing basic namespaces is probably ideal, and this would allow you to change which group something is a member of on the fly or have them be members of multiple groups, redefine groupes, lots of stuff. I will play around with this at work tonight, you have given me lots of fun ideas.

Wrong select on your loop, you had that right the first time. Put a [t b f] on the right outlet of [sel 0 -1], float outlet goes to [sel] and bang outlet bangs the float. Make sure to click on that [0( message if you are not starting from the freshly opened patch, who knows what the value is otherwise. And remove your [>=] logic, but there is something to be said about using [>=] instead of the plain select as I did, you would not have to worry about clicking the [0( if things get out of whack but once you have it working it should never get out of whack so I tend towards going with the slightly more efficient option in this case. Also make sure the counter is wired proper, it needs to do the +1 before the [selec 0 -1] or it won't work, a [t f f] is not a terrible idea here, old habits. I probably was not as clear as I could have been on that, have yet to get my new computer setup and have been using my tablet or phone, which are not great for this stuff, especially since I can't get the linux VM on my tablet to share files, so can't get patches in or out of the VM where pd lives without jumping through hoops. Should be up and running this week.

@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.

@oid oh, I totally confused things for you, sorry. Nothing has changed. I will clear this up asap. Stay tuned.

@cfry I don't think you did, but maybe? Either way, no need to apologize, I have gotten a lot of good ideas for my own projects from this, simplifying my way of doing this stuff for you has been very productive for me. Is loop now working? it looks good but I did not test it. Also, sending 200 to $0pop is not a good way to clear the stack, if the last command run was something which pushes onto the stack you will end up with something still on the stack, just connect a [r $0-dump] to the right inlet of the [list store] and you can send the dump command to clear it.

@cfry Been playing with this today and reread the thread, I think we are mostly on the same track, in that previous post I just took a leap to a next step which seemed illogical to you but makes sense to me and might be a step you are not even interested in taking but it is almost free because of the stack. From what I understand, you want to have a sequence of commands which you want to step through, such as your valadd example in post 10, each time it gets a bang it adds that value to val and then loops infinitely the last three valadds; valAdd -1, valAdd -0.5, valAdd 1, goto 7, valAdd -1, valAdd -0.5, valAdd 1, goto 7, valAdd -1 etc. This would be like your [pi-cy] abstraction, sets val to 60, and then steps through each valAdd and finishing with that infinite loop between line 7 and line 9 with each step sending the result of val + valAdd's argument to SynthY's pitch? The loop command would be closer to [pi-cy] than this goto? or maybe loop would be the [cy%...] abstractions? Hopefully it is close enough for this example.

Assuming I got this down, the leap to the next step I took was to to just stick the entirety of your previous screen shot into one instance of this abstraction so you don't need dozens of text files to keep track of jumping between editing the patch and the texts, and things like sharing data between them, your groups, and a whole lot more, become trivial. The difference between the single instances for each channel and putting all this into one instance is just adding a few commands, the stack makes it easy to expand and develop things like this. But you may not want to go that way and may not even need the stack, a different data structure like a list or an array might suit your needs better and it is easy to switch this all over to a different data structure, pop and push just set and get a value from the list or array instead of literally popping and pushing. Or we can implement lists/arrays in the stack based paradigm and that is when things get fun, but that might be more than you want.

I worked out a few variations but I will wait to post them until I am certain I understand what you are going for so I can make any needed adjustments and hopefully avoid more confusion.

@oid Im just jumping in here quick to say it indeed looks like we are on the same page. I think you should go ahead just as you describe. As long as the basic functions are retained (so I can update my original performance to be stable) I wont mind a zillion of new functions to explore. That will lead to new ideas, could not be better.

Let me know if you want the original pd patch for the performance. Or bits and pieces. It is a mess though.

"the output of [r chs-$0] is a two element list, channel number and a one or a zero?"
-yes exactly

"What is the right outlet of your once? bang when reset or something else?"
-It bangs the first time a channel is active, in order to be able to, for example, send the initial settings, start pitch etc. This way I can be "monophonic"

"are they how you are implementing groups? this screen shot is one group with two synths?"
-no, actually the group handling never have been that much developed. Its more that I see that it can be useful.