Thanks @willblackhurst and @lacuna for showing how to use savestate with an array.

I have a patch that has several copies of a wavetable abstraction. The abstraction has a $0 array with the "Save contents" option checked. Each instance of the abstraction has different data in its array. When I save and reopen the patch, all of the arrays are incorrectly set to the contents of one of them. This seems like a bug to me. I think that each array should have been restored to the contents it had when I saved it. How can I restore all of the arrays to the correct values? Is there a way to use [savestate] with an array?

@whale-av The bat file does open the patch, but it doesn't open a new console window like I saw previously, and I only see one pd in the Windows Task Manager. Also, the patch is able to access audio and MIDI without changing the settings. Do you know if there is a way to verify whether Windows is running the patch in a different thread?

@whale-av Thanks for the info! I'll try using a bat file to run multiple patches. My main patch does all the audio and MIDI I/O, so I think it should work as along as I start the main patch first.

Since the current behavior is inconsistent, I'm wondering if I should open an issue on GitHub. Maybe it's a bug.

Sometimes when I double click on a patch to run it on Windows, it starts a second instance of Pure Data 0.56.0. Pd opens a second console window, and all messages from the second patch go to the second console window. Why does this only happen some times? Is there a way to make it happen all the time? Do different instances run in different threads? When I get a second instance of Pure Data, it is unable to connect to my MIDI device. Are there other restrictions on multiple instances of Pure Data?

I've been looking at using [Pd~] to run different patches in different threads, but it would be easier to run each patch in a different instance of Pure Data, if there's a way to consistently start multiple instances.

I don't remember seeing this before 0.56.0. Is it a new feature?

@FFW said:

EDIT: you stack computation branch and they are released deepest to shallowest so numbers are reverted.

I don't understand your comment. Why aren't the numbers coming out in the order in which they were computed? This seems like a bug to me. Is this behavior documented?

@FFW I had the control flow correct in my example. Adding [trigger] didn't fix the problem. Here's my example with [trigger]. The numbers incremented in the [i] object still come out in the wrong order. It appears that they are coming out in LIFO order when they should be coming out in FIFO order.

loop_test.pd

I'm trying to increment two sets of numbers in a loop. One set comes out in the correct order; the other comes out in the reverse order. How can I make this work correctly? I've attached a simplified patch that demonstrates the problem. It should print
0 0
1 1
2 2
3 3
4 4
Instead it prints
0 4
1 3
2 2
3 1
4 0

loop_test.pd

Have you set Input Devices in Audio Settings?