Massimiliano Viel

I have a patch with, let us say, 400 UI objects and I want to store 200 in one preset and the other 200 in an other preset. With the preset object it is possible but it takes 400 patchchords to include the proper objects in the proper preset object. Pattrstorage lets do it without visible connections. So I did it with autopattr (by giving the 400 object a script name) and one pattrstorage, with the 200 object selected in the "client window". And that works fine. The I started to do this with a second pattrstorage but its client window doesn't show me any possible client object. As someone pointed out in a past thread, it seems there is some hierarchy in the pattrstorage objects so that you can use only one in a patch. Of course I could use the "including" patch chords but then the use of pattrstorage instead of preset is pointless. I could possibly use the subscription by sending a veeeery long message to the second pattrstorage, but the client windows is still showing no client.

where am I wrong? is it possible that there is still (the original thread was dated 2008) no easy way to have two preset systems in the same patch?

I would like to avoid hundreds of patchchords and ludicrously long messages. Is there an alternative?

Hi,
here is my problem:
I have a patch with, let us say, 400 UI objects and I want to store 200 in one preset and the other 200 in an other preset. With the preset object it is possible but it takes 400 patchchords to include the proper objects in the proper preset object. Pattrstorage lets do it without visible connections. So I did it with autopattr (by giving the 400 object a script name) and one pattrstorage, with the 200 object selected in the "client window". And that works fine. The I started to do this with a second pattrstorage but its client window doesn't show me any possible client object. As someone pointed out in a past thread, it seems there is some hierarchy in the pattrstorage objects so that you can use only one in a patch. Of course I could use the "including" patch chords but then the use of pattrstorage instead of preset is pointless. I could possibly use the subscription by sending a veeeery long message to the second pattrstorage, but the client windows is still showing no client.
So the question is:
where am I wrong? is it possible that there is still (the original thread was dated 2008) no easy way to have two preset systems in the same patch?
I would like to avoid hundreds of patchchords and ludicrously long messages. Is there an alternative?
Thank you for all the help!


again-multiple-pattrstorage-objects-in-a-patcher

No answer?! it's because it's a stupid question or because nobody knows the answer? :-(

"I would like to avoid hundreds of patchchords and ludicrously long messages. Is there an alternative?"

If there is no clear spatial/functional division between the first group of ~200 UI objects and the second group in your patch, then there is no obvious way (that I can think of) to avoid the work i.e.'patchchords and ludicrously long messages' . On the other hand, if there is a way to draw a clear distinction between the two groups of 200 UI objects, it may be worth dividing them up into independent BPatchers each with their own Pattrstorage ...

autopattr exposes objects with a scripting name to pattrstorage.

Naming the preset object in inspector with the same name as the pattrstorage should make them unique. (not behind the computer now though)

autopattr exposes objects with a scripting name to pattrstorage.
Naming the preset object in inspector with the same name as the pattrstorage should make them unique. (not behind the computer now though)
sooooo.
1 autopattr

pattrstorage @name system-1
preset (in inspector) system-1

pattrstorage @name system-2
preset (in inspector) system-2

@SPECTRO well the 200+200 object are well mixed up in the patch. But it is true that I didn't use bpatchers. No easy though... I have 16 functional units each one with 20 UIobjects, 16 for one preset and 4 for the other one. I think bpatchers might risk simply to mess things up more.

@ANDRO the thing is that when I have the first pattrstorage I can see all the client available in the "client window",but as soon as I create a second pattrstorage these clients are no available for the second pattrstorage, as they are already taken by the first one! That is the problem!

By the way: if I use only two preset objects (three actually) with their include/exclude chords, the thing works fine... only I hate to navigate through these 400 patch chords (and the RAM hates it too). And by the way receive/send works fine with the include connection, but it doesn't seem to work with the exclude one. Why?!?

If you are using 16 identical modules, I can't believe you aren't working with bpatchers anyway, but that's just a style preference, I guess...

The way pattrstorage is designed, I'm pretty sure your only options are multiple psto's or using subscribe/unsubscribe. (If I have very long message lists I have to send to objects, btw, I usually put them in a coll, and just dump the coll into the receiving object, which is much tidier than a huge message box.) Although it may seem a like a ridiculously long message, it's a lot less inconvenience, and probably far more efficient, than having 400 patch cords getting in the way of everything else in your patch.

If you use bpatchers,think of each module as having its own two pattrstorages. Even if you wind up with 32 pattrstorage files, it's not so hard to architect that so it will be pretty transparent to you as a user. Also remember that you can put bpatchers inside of bpatchers so your 16 controls could be on one level, and the 4 in a bpatcher inside that one.

the biggest thing that is going to hurt your speed in any of this is having 400 UI objects in one patch....

The way pattrstorage is designed, I'm pretty sure your only options are multiple psto's  or using subscribe/unsubscribe.  (If I have very long message lists I have to send to objects, btw, I usually put them in a coll, and just dump the coll into the receiving object, which is much tidier than a huge message box.)  Although it may seem a like a ridiculously long message, it's a lot less inconvenience, and probably far more efficient, than having 400 patch cords getting in the way of everything else in your patch.

If you use bpatchers,think of each module as having its own two pattrstorages. Even if you wind up with 32 pattrstorage files, it's not so hard to architect that so it will be pretty transparent to you as a user.  Also remember that you can put bpatchers inside of bpatchers so your 16 controls could be on one level, and the 4 in a bpatcher inside that one. 

Again: multiple pattrstorage objects in a patcher