@lacuna This has the same issue, doesn't it? as soon as menusave is sent to a canvas that canvas is saved, all instances of the abstraction reload? Also, [savestate] does not like being abused this way (at least in 56.1), segfaults pd if you have more than one instance; guessing [savestate] still has the canvas id of the old abstractions from before they got reloaded by the first save and then attempts to access that no longer accessible memory? or something, but maybe it works in what ever version of pd you use and has some magic I can't see? [receivecanvas 1] seems to work safely and reliably, but we still have the reload issue.

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