davidestevens

Using textedit, I can change the names stored in the umenu slots.

(I'm using this for loading and saving colls, so I'm entering a new name into a umenu slot everytime I add a new storage line to a coll).

If I change the item name while editing the subpatch itself, and then save, the changed items in the umenu are saved with it, and if I open the main patch, the changed names are there in the subpatch.

But if I load the main patch, open the subpatcher, and change the name of one of the umenu items, then save and reload the main patch, the name changes haven't been stored.

So it seems that changed items in a umenu are only saved if the actual patch containing the umenu is itself saved.

Surely this can't be right? There's something I'm missing, but I can't see any obvious reference to this in the Docs.

I want to be able to change the name stored in umenu in the subpatch, and have it saved with the main patch. What am I missing?

Using textedit, I can change the names stored in the umenu slots.
(I'm using this for loading and saving colls, so I'm entering a new name into a umenu slot everytime I add a new storage line to a coll).
If I change the item name while editing the subpatch itself, and then save, the changed items in the umenu are saved with it, and if I open the main patch, the changed names are there in the subpatch.

But if I load the main patch, open the subpatcher, and change the name of one of the umenu items, then save and reload the main patch, the name changes haven't been stored. 

umenu-confusion

(to explore the bpatcher, right-click -> Open -> New view of...)

(to explore the bpatcher, right-click -> Open -> New view of...)
J-F


I'm getting ready to use my patcher in an installation next week, so Im not going to play with this at the moment (!).

I'm not clear how embedding the umenu solves the problem of it (seeming to) not save new items entered into it when it's in a subpatcher inside an existing instrument. I wondered if there was a umenu flag that needed setting - kind of like the coll one you have to set for it to remember data when you save a patch. 

I also wondered if it was something to do with the patch being dirtied (new or renamed items in the umenu) and though the top level patch is being saved, changes in a subpatcher are _not being saved.

Does the problem I'm having make sense? (I've worked around it for now by storing menu items in a coll as well (which _does save the names when the main patch is saved) and then reloading the umenu from the coll when the main patch is launched.)

I'm not clear how embedding the umenu solves the problem of it (seeming to) not save new items entered into it when it's in a subpatcher inside an existing instrument. I wondered if there was a umenu flag that needed setting  - kind of like the coll one you have to set for it to remember data when you save a patch. 
I also wondered if it was something to do with the patch being dirtied (new or renamed items in the umenu) and though the top level patch is being saved, changes in a subpatcher are _not being saved. 

I'm afraid I don't understand your question.

With the patch I sent, click on one of the message boxes, save your patch, close, open, the content of the menu is saved with the patch.

But maybe you just need a bpatcher that be not embedded (the usual way of using bpatchers).

I'm afraid I don't understand your question.
With the patch I sent, click on one of the message boxes, save your patch, close, open, the content of the menu is saved with the patch.
But maybe you just need a bpatcher that be not embedded (the usual way of using bpatchers).
J-F.


Main patch contains a number of subpatchers (as abstractions)(_not bpatchers, for UI reasons). In fact, the subpatcher containing the umenu is 3 layers deep ...

seqSR and patterncreate are abstractions -

[patterncreate] contains a umenu with 20 pre-existing slots (named "empty"). You can change the name of any of the slots using a textedit.

These changes are also sent to another umenu in the level above (seqSR).

If I load [patterncreate] on its own and change one of the umenu slot names, then save the patch, the name change is retained, as I would expect. 

If however, I load the main patch (sensorRoom), 

open seqSR (a sort of sequencer), and then [patterncreate] (where I can programme different sequences), 

create a new set of patterns, then name the relevant umenu slot (that relates to a coll line that stores the sequence values) ... 

then close all that, save the main patch and close it, 

then re load the main patch ... the name change in the umenu _hasn't been saved.

My underlying assumptions are that umenu retains changes made in it when a patch is saved (which is what happens), and that the same thing should apply if the umenu is inside an abstraction (which is what _isn't happening).

[sensorRoom 
......[seqSR 
..........[patterncreate]]]

seqSR and patterncreate are abstractions - 

If I load [patterncreate] on its own and change one of the umenu slot names, then save the patch, the name change is retained, as I would expect. 
If however, I load the main patch (sensorRoom), 
open seqSR (a sort of sequencer), and then [patterncreate] (where I can programme different sequences), 
create a new set of patterns, then name the relevant umenu slot (that relates to a coll line that stores the sequence values) ... 
then close all that, save the main patch and close it, 
then re load the main patch ... the name change in the umenu _hasn't been saved.

umenu confusion