Forums > MaxMSP

umenu confusion

May 10, 2009 | 12:02 pm

Inside a subpatch I have a umenu.

Main Patch/Subpatch with umenu.

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.

All clear so far?

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?

thanks

David


May 12, 2009 | 3:37 pm

You could use an embedded bpatcher:

– Pasted Max Patch, click to expand. –

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


May 12, 2009 | 9:07 pm

thanks J-P,

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

David


May 13, 2009 | 2:05 pm

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.


May 13, 2009 | 4:06 pm

Let’s see if I can be clearer.

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 …

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

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

Does that make more sense?

thanks

David


Viewing 5 posts - 1 through 5 (of 5 total)