@lacuna iemguts could make that a bit cleaner.

[receivecanvas 1]
|
[route menusave]
|
[dirty 1(
|
[sendcanvas]

And this lets us automate further by replacing [dirty 1( with [menusave( to get things so they don't require user input and everything just works. The catch would be this won't work if you have more than one instance of the middle abstraction since saving will reload all other instances and make them have identical state to the one that was saved. Or am I missing something?

@jamcultur I think this might be intended behavior? [savestate] does its thing when the parent patch receives a save, in the case of an abstraction within an abstraction the parent patch is the abstraction that contains it, the patch is the grandparent? Docs don't clear this up and nothing on the github, there is a feature request for adding a depth argument to [savestate], but I did not read it to see if it is meant as a "fix" or extend how [savestate] works. But it seems like if this is how it always worked, this thread would be at least an annual event and it would be spelled out in the docs, so maybe a new bug?

In this case I would change how I structure my patch and abstractions to avoid having [savestate] in nested abstractions, anything else will probably result in slowly implementing your own adhoc state saving abstraction. One of the old state saving abstractions from before the days of [savestate] might work, but I remember them as not being much fun to use.

@pureQuestion Guess they moved them and did not update the docs, the makefiles now live in directories for each platform, pd-0.5x-x/linux.

@cfry Finally have time to get back to this. Quick question, what is the source of the sequences in the cycle abstractions? Generated, entered in manually, gotten from somewhere else. something else? Do they share a sequence and each use different parts of it? Realized I made a few assumptions on how I went about dealing with that part of your patch and it could be terribly inefficient in some cases. Think I have things mostly worked out, just need to fix a few minor things and document the commands.

@jameslo I sort of agree but honestly, thinking too hard about [text] is something I have learned to avoid doing. If memory serves I did not really devise a separator, I did a [text tolist], dripped and escaped the escapes of the commas, then [text fromlist] so my delimiter was \,. I used my list search abstraction to find the delimiters and fetch the message I was looking for. I am pretty sure that version of [l-find] can do it with ease, not yet on the new laptop and don't have time right now to dig. I probably used [l-find] to replace the commas as well. These days, I think I would just use [pdlua] and get actual tables.

Edit: actually I don't think that version of [l-find] will find all instances and output a list of their indices, so not quite easy. I can upload that later if you want it.

@jameslo In the past I just used something other than a comma (or had pd replace the commas) to separate messages so I could get the whole line, dump it into a [list store], find the appropriate delimiters and get the message I wanted. Not as efficient as your method but don't need to keep two [text]s synced. I almost made an abstraction of your way but the ugliness of automating the generation of the mask [text] sapped my motivation, the [text[ way of doing things just fights you here.

@Moothart You just need to stick a [t f f] after the [list store] so you can pass the value forward and store it. Another one of those very common idioms like list dripping which you will use a great deal.

@Moothart [expr] also has some options here, rint, round, nearbyint, ceil and floor can round out the options. Open the help for [expr], and then the subpatch that is something like [pd all functions and operations] and then into the subpatch that is something like [pd misc numeric operations] for more info, going from memory on those subpatches. [i ] often works but it always rounds down, 0.999 will be 0 which can be irritating and not at all what you want. And you can stick the division right in there, [expr round($f1)/10]. [expr] is not as efficient as the normal math objects, generally we don't need to worry about this much with modern cpus unless you are using [fexpr~] or [expr~] in a subpatch with a small blocksize, but it is good to keep in mind and not just use it because it is easy.

@Moothart In this case it does not matter if it is the left or the right inlet and it would work the same. The general convention when something is patched as I did is that the connection does not cross inlets/outlets and is connected to the first it comes to since anything else would be ambiguous. Vast majority of those who patch like this, follow this convention.

Going to the right inlet it loads 0 into the float, than the [until] is banged sending [get 0 1( to [list store], the [until] then bangs until the [list store] gets an out of bounds get which sends a bang out of its right outlet to the left inlet of [until] which stops the [until]. Going to the left inlet the [f ] immediately outputs a zero which sends the [get 0 1( message to [list store], adds 1 to it and sends 1 to the right inlet of [f ], the [until] then starts and sends 1 out giving us [get 1 1(. Only difference between the two is that the [until] will bang one time less if you send [0( to the left inlet than it would if you send it to the right.

@Moothart It is just another slight variation on dripping lists, we just change the list we are dripping and how it is triggered.

This is pretty much the same as @whale-av's solution but updated to use [list store] which was not around when list-abs was made. Most of the list-abs abstractions can be made more efficient with [list store], especially those ones which drip the list.

Personally I find @jameslo's solution the best, most efficient (probably want to add in a [change] after the [int]) and cleanest. It is also a nicely circular with your misunderstanding of my initial response (assuming I understood you correctly and did not misunderstand), I have a fondness for that sort of ending up where you started path, tend to learn a lot from it despite the time spent going in circles.

@Moothart In the above example the array would only contain 2 5 6 7 10, so it would work as expected as long as the number are arranged sequentially from lowest to greatest, but [array] is not so good for this since it is a fixed size, [list store] is the better option here since it resizes itself to the list you give it.

This little block of code built around the [list store] is called a list drip, this variant being the slow variety, every time it receives a bang it drips the next element of the list. The list drip is a very common and useful paradigm in pd, good one to learn and really understand since there are countless variations you can patch up for various needs. Here I am using a [s value] for the output which sets the right inlet of the [>=] and makes it easy to get the current value anywhere else in the patch through [r value] or [v value], each having their advantages and disadvantages. I also added a [s bang] which bangs after each time the value changes, which also can be useful. That [change] I added in after the [>=] is quite important and an oversight in my previous example.

One thing to be aware of when using [v ], especially when you are also using [s ] to set that [v ], creation order can bite you.

Pd sends the new value to the [r ]s and [v ]s in the order they were created and [r ]s often execute more code, if there is a [v ] in that branch of code the [r ] executes and that [v ] was created after the [r ], the [v ] will have the old value. Generally it is fairly easy to find these bugs once you understand how creation order affects [r ] and [v ], but it can be very difficult to sort out in large complex patches. The above patch also demonstrates the importance of using [trigger], it is generally wise to just use [trigger] anytime you need to connect more than one object to a single outlet, beyond being more reliable it also tends to make patches more readable and neater even in those situations where order does not matter and you can get away without using a trigger.

@Moothart For the first question, just connect the outlet of [line] to the right inlet of [i ], bang the left inlet of [i ] when you want to sample the output. Checking for numbers is a bit more difficult since you can not be certain [line] will ever hit those numbers, it might go from 0.99 to 1.01 and never hit 1 but since you just want to know when it passes it, that is a bit easier. if the numbers in the array/list are always sequential as in your example it is pretty easy, you just need a [>=]->[sel 1] which goes into a counter that gets the next element from the list/array and dumps it into the right inlet of the [>=].

If this is not what you want, some more details about what you are trying to accomplish would help but someone else might see what you are going for.

@stefano_zorzanello A copy and paste of that patch works fine for me and scanning through the text I don't see any issues, but I did not look closely. Did you save it as plain text? or just let the text editor decide the format? rtf or other fancy formats used by word processors might cause a crash. Here is the patch I get, maybe it will work if saving as plaintext does not work for you.
Untitled-1.pd

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

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

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

@soundproofskin That makes sense since pd's text editor is the Tk text widget and it has those features, have not used the editor since I made my abstraction to get around other issues with the text editor.

I am not sure if we can add this in with a plugin, the binding is not an issue but we also need to retrieve the text of the object currently being edited so we can find that next space to navigate too when shift-right is pressed, and I have not found a way to do that, only the last object clicked on, which means this would not play well with autopatching. If we can get the current object these features would be simple to implement, maybe @seb-harmonik.ar knows of a variable holding the value of the current object being edited or an array holding the text currently being edited? I have a vague memory of once finding such an array, but it is not in my notes and the one time I tried to find it again I came up empty.

You could easily bind it to move the insertion cursor a fixed number of characters, shift-right moves the cursor 4 or 5 characters to the right, but I don't think that would be much use since to get good with it you would have to constantly count characters. One of the other flavors of pd (plugdata, purrdata, pd-ceammc, pd-l2ork) might provide this if using one of them is an option but as you progress and get better with pd, i am not sure you will find much utility in navigating text this way; years ago I also used to try and shit-arrow my way through objects but as I became more familiar with pd it became rare there was a need, anytime I want the cursor somewhere other than at the end is when I am editing an object which is not currently selected so I have to use the mouse anyways and putting the cursor where I need it is less work than keyboard navigation.

@soundproofskin Pd's built in text editor seems a low priority and just a convienence that is not meant to replace a proper editor. I have an abstraction which you use in place of [text define] and instead of opening the internal editor it opens the text in an external editor and reloads the text anytime it is saved, I will upload it later this week after I get some computer stuff sorted out.

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