So I am working with [clone -s 1 OBSongPlaylistItemClone 128] displayed in the first screen shot. I have been tidying things up and ran into a somewhat annoying error and Ive been stuck on it for a solid week. :/

The second screenshot shows how data is changed for the cloned objects. Which is almost working but the issue happens when which ever cloned object was changed last will end up overwriting to the newly changed object with a different index which should be [r selsongitem] i think i am missing a trigger somewhere to updated the new index for the cloned object before data is written. So the new item changes is receiving old data. :/

I hope that makes sense.

So to break it down if I was to change the value of the atom for Patts the new value will be written to file just fine. but then when I edit the Patts atom for lets say the 5th index the values that was set for the 1st index item will replace the newly changed 5th atmos its kind of hard to explain apologizes.

I should mention i just noticed that the txt file shown in the second screenshot does not reflect its current state. as described above it would read like this which is incorrect.

Lastly on a fresh boot [r persongbank] would read the value of 16. Sixteen cloned items are visible at one time. I quickly save the patch before taking the screenshot which reset this value to 0. this value is set correctly and issues still occur is my point.

tmpProject 0 0 0 0 0 0 0 0 102.4;
3 1 0;
1 1 0;
1 1 0;
1 1 0;
3 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;

The end result should read like this

tmpProject 0 0 0 0 0 0 0 0 102.4;
3 1 0;
1 1 0;
1 1 0;
1 1 0;
14 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;
1 1 0;

@RetroMaximus Yes, order of operations seems likely.
You should work from the object that starts the operation and follow each leg (including through send/receives) to the very end.
Remember that a trigger [t x y] will not send "x" until every operation of "y" has finished......
If you connect "y" to another trigger [t b c] then "c" first and then "b" must be complete before x will start.

Sends >>> multiple receives are problematic because you probably don't remember in which order you created them.
You might need to create new triggers and send/receive pairs to force the order of operations to various parts of your patch.

You have used [delay] a few times. That will reschedule the operation that comes afterwards and is not really a good solution for forcing the order of operations. [delay] might seem to solve an immediately obvious problem, but then makes it really impossible (in all circumstances) to be sure of the state of the other data when the scheduled operation actually "happens".
David.

@whale-av Thx for the input I figured thats what is up I just cant seam to find where im going wrong. I tried this portion without using delays and I cant ever seam to get the proper output from a [pack f f] So if i was to [t f b] I would send the float then to actually send the package connect the bang to the 0 message but this never works correctly without using a delay. This is the reason for the few delays I used. Is there a different way to send a [pack] directly after a float value is received? The patch titled SendSelectedIndex is a perfect example of what I need to correct without using delays.

@RetroMaximus If you change the [trigger] before [pd SendSelectedIndexToClone] like so:
You can have this [pd SendSelectedIndexToClone] with the same functionality but without delay:
But then again, you put in a float and get the same float out of it.

You can also only trigger the float first:
And from there get the bang:

Also possible to use [list prepend]:

@RetroMaximus Also...... adding to @ingox tips....... you can store floats in [f] and lists in [list] and symbols in [symbol] on their right inlets and then bang them through via their left inlets when ready.
Maybe use [f] or [list] or [symbol] where appropriate at the end of all your chains, and then use a [t b b b b b ........] at the top of your chain to bang them all onwards in the correct order once all the data is set?
David.

OMG I cant believe I just fixed it...

I had to take a few steps back and look at an example for using cloned objects.
During the process of cleaning this portion up I managed to remove some key objects that are needed to get data from a cloned object. that was #1. And well for #2 it was just a mess I was doing way to much.

Thank you for all the tips it made me want to go back and take a different look at the patch. While i thought i was making things easier to look at i mess it up big time. lol

oh well you live and you learn.

Now I'm stuck with a bit less annoying bug. the values don't seam to match up but the data is being written to the correct index now. Simply the values seam to be
-1 or +1 depending on which direction the atom is scrolled. I found this weird.

@RetroMaximus Are you not banging in "state" for example instead of "get_state" and the trigger should be [t b f] and not [t f f]......?
If so then the same error for all the other outlets of [route].... ?
David.

Then what do I connect the bang to? the [state< $1 message? but wont that change the $1 to 0 and not the actual state value? or the bang will simply bang what is received from [t f b] to the final [s]. Im going to test it real quick

Scratch that I Think know what you mean

@RetroMaximus .... what I noticed is that "get_state" is never sent on from the [f] where it is stored.
It is simply overwritten by an incoming float from "state" when that arrives at the left inlet of [f]..... and it is that float that is sent onwards.

+..... if [t f f] receives a bang and not a float then it will send 0... zero. Hopefully not the case..!
David.