Load on startup at instance not patcher level

[twhiston]

Currently it appears that load on startup applies at a patcher level, so setting this will change all patchers on next load. This makes it really difficult to set up complex setups where you have multiple instances of an rnbo patcher, where each should have different settings. Would it be possible to set this on an instance level instead?

[x37v]

are you referring to instance presets?

we have set presets that allow for unique values per instance in your set

[twhiston]

yes sorry, i am referring to instance presets, I should have been clearer.

Honestly I don't think that the way it currently works is particularly useful when dealing with large sets of objects. In a complex setup you are most likely going to have many instances of the same patcher (eg signal routing utilities) and you will want to have some instances which start with preset A, some with preset B, and some which simply load with their init values (eg. because you control them from somewhere else). On top of this you're going to be working and testing in this set/preset, which means values in your instances changing (eg from ingestion of control signals) and you might not know it. This last part in particular means that you need a way to return easily to a well defined, but probably quite complex, startup state.

With the way presets work currently you cannot easily have a well defined complex startup state. Because set level presets capture every value in every instance, including any value that might have been changed in the course of development/testing/using, it is therefore a snapshot of the runtime state rather than a collection of predictable values. On the other hand patcher level presets selected for load on startup cannot be used to set up a complex predictable state because they apply on a global and not instance level, it's all or nothing.

So to have a predictable startup state where certain instances have different sets of well defined values I would have to go through every object in my graph before ever saving and reset the object values to what I want their initial state to be, which I guess I need to write down somewhere or something!

So my suggestion would be to allow the instances of a patcher to individually store and recall their startup preset. It would give you so much more flexibility and allow you to set up much more complex states. You could still have exactly the same behaviour as today by applying the logic on instance load of "if instance does not have a preset bound then load initial preset". This would literally be the preset called initial (which I guess you should not be able to delete!) and as per today, by allow a user to overwrite what the initial preset values are you could still change all instances of a patcher (which doesn't have a specific preset set) with a single action. This would give you so much extra flexibility to set up complex scenarios, and I think is actually clearer to a user than the current implementation.

I hope I made my reasoning and idea are clear here!

[x37v]

I see what you're saying here, I'll have to think it through a little bit it makes a lot of sense. Basically, you want to be able to refine presets for a specific patcher and have those refinements show up when you load a set that has instances of that patcher and associated "initial" preset settings for instances of the patcher in the set, where the "initial" preset for each instance may not be the same.

[twhiston]

I think were on the same page here, I've been trying to think of the easiest way to explain what I want though and I think it basically boils down to: I would like Graph sets to save both the object layout, their connections and an initial selected preset for each individual object in the graph.

My graph has a silly amount of objects in it and about 100 parameters mapped to midi controls within those objects. Trying to have a well defined startup state for a graph like this is almost impossible atm, but if I knew for a fact that when starting up all my objects would be in well defined states, defined by presets which I selected in each object, my life would be a lot easier (especially since this setup is for playing live!)