Forums > MaxMSP

Preset object – Fetching data.

January 17, 2007 | 6:14 pm

Is there any way of obtaining the number of presets stored in a preset object as an integer?

I.e. Useful for when I have stored n presets out of a possible 256 then should I want a random stored preset I could recall random preset n but have a different random preset recalled each time.

Thanks

Rhys


January 17, 2007 | 6:21 pm

Hi Doc,

Something to count # of stored presets?
I had that in my archives.
HTH,
P.G.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 15 35 43 196617 loadbang;
#P newex 93 91 40 196617 sel 256;
#P message 281 35 21 196617 dec;
#P message 305 35 19 196617 inc;
#P newex 250 180 39 196617 del 100;
#P message 250 237 13 196617 1;
#B color 5;
#P message 250 35 28 196617 next;
#P number 250 91 25 9 1 256 35 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P message 271 237 39 196617 max $1;
#B color 5;
#P button 63 28 24 2;
#P newex 63 63 41 196617 uzi 256;
#P number 289 216 24 9 1 256 35 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 271 216 17 196617 int;
#P slider 34 158 15 128 0 1;
#P number 63 91 28 9 1 256 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N counter 1 256;
#X flags 0 0;
#P newobj 250 63 70 196617 counter 1 256;
#B color 5;
#P number 173 297 25 9 1 256 35 3 0 0 0 221 221 221 222 222 222 0 0 0;
#N vpreset 512;
#X append 1 1 6 158 34 slider int 77 ;;
#X append 2 1 6 158 34 slider int 31 ;;
#X append 3 1 6 158 34 slider int 115 ;;
#X append 4 1 6 158 34 slider int 71 ;;
#X append 5 1 6 158 34 slider int 104 ;;
#X append 6 1 6 158 34 slider int 0 ;;
#P preset 63 123 167 169;
#P window setfont "Sans Serif" 10.;
#P comment 63 13 24 196618 Init;
#B color 14;
#P connect 6 0 10 0;
#P connect 6 0 7 0;
#P fasten 13 0 3 3 255 259 329 259 329 56 300 56;
#P fasten 2 0 6 1 178 316 329 316 329 209 283 209;
#P connect 14 0 13 0;
#P connect 14 0 6 0;
#P fasten 17 0 14 0 98 114 255 114;
#P fasten 3 0 4 0 255 86 68 86;
#P connect 3 0 11 0;
#P fasten 16 0 3 0 286 56 255 56;
#P fasten 15 0 3 0 310 56 255 56;
#P connect 12 0 3 0;
#P fasten 10 0 3 0 276 259 329 259 329 56 255 56;
#P fasten 1 1 2 0 146 295 178 295;
#P fasten 1 2 2 0 224 295 178 295;
#P connect 8 2 4 0;
#P connect 8 2 17 0;
#P connect 4 0 1 0;
#P fasten 18 0 8 0 20 59 68 59;
#P connect 9 0 8 0;
#P fasten 1 0 5 0 68 298 55 298 55 153 39 153;
#P window clipboard copycount 19;


January 17, 2007 | 6:30 pm

Thats the sort of idea I’m after but unfortunately your patch will count up till the last preset added and count non filled interim presets as part of the total count rather than ignoring them.

This is still quite useful though and gives me a path to go down, thanks,


January 18, 2007 | 3:25 am

You could expand the example patch by adding a counter at the middle outlet. Then when you iterate through all possible 256, you’ll get a count of how many total are stored. You’d need to keep track of the ones that bang / send out a "preset number when recalled" (in a coll) so that you’d get a list like:

1, 1;
2, 1;
3, 0;
4, 1;

This means there are presets in slots 1 2 4 but not 3. The indices out of the Uzi would default to (index, 0) in the coll UNLESS there was an output from the middle outlet, then they would be (index, 1).

Now, randomly accessing presets wouldn’t be a problem, using an if statement after the coll access to test whether the data is a 1 or 0. If it’s a 1, access the preset number.

HOWEVER, of course, you’d have to turn off the preset’s functionality while you’re testing it, or else upon checking the length, you’d blaze through all the stored presets for your attached objects! Unless that’s a neat effect. I dunno, maybe the Uzi counter would be fast enough to not make this a problem.

–C


January 18, 2007 | 9:27 am

zum Beispiel ?
… mmh, i feel like it could be simpler …
_y.

#P user multiSlider 71 126 108 66 0. 127. 8 2665 47 0 0 1 0 30 0;
#M frgb 255 255 255;
#M brgb 0 0 0;
#M rgb2 127 127 127;
#M rgb3 0 0 0;
#M rgb4 37 52 91;
#M rgb5 74 105 182;
#M rgb6 112 158 18;
#M rgb7 149 211 110;
#M rgb8 187 9 201;
#M rgb9 224 62 37;
#M rgb10 7 114 128;
#P button 234 212 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#N vpatcher 329 77 596 475;
#P window setfont "Sans Serif" 9.;
#P window linecount 0;
#P newex 54 53 72 9109513 deferlow;
#N counter 0 1 256;
#X flags 0 0;
#P newobj 138 197 74 9109513 counter 0 1 256;
#P message 73 193 33 9109513 length;
#N comlet to preset;
#P outlet 138 303 15 0;
#P window linecount 1;
#N coll ;
#P newobj 73 267 48 9109513 coll;
#P message 73 333 25 9109513 clear;
#P newex 31 333 30 9109513 + 1;
#P newex 138 139 38 9109513 gate;
#P newex 54 82 94 9109513 t 0 b 1;
#P newex 31 309 52 9109513 Urn;
#P newex 138 222 83 9109513 pack 0 0;
#N coll ;
#P newobj 138 267 48 9109513 coll;
#P newex 138 168 38 9109513 t b i;
#P newex 54 25 72 9109513 loadbang;
#P newex 96 106 38 9109513 uzi 256;
#N comlet bang random preset;
#P inlet 31 280 15 0;
#N comlet from preset middle outlet;
#P inlet 166 106 15 0;
#P connect 1 0 7 0;
#P fasten 11 0 7 0 78 356 105 356 105 302 36 302;
#P connect 7 0 10 0;
#P connect 3 0 16 0;
#P connect 16 0 8 0;
#P connect 2 1 14 0;
#P connect 6 0 12 0;
#P connect 14 0 12 0;
#P connect 12 0 7 1;
#P connect 7 1 11 0;
#P connect 8 1 2 0;
#P fasten 8 0 9 0 59 131 143 131;
#P connect 8 2 9 0;
#P connect 9 0 4 0;
#P connect 4 0 15 0;
#P connect 15 0 6 0;
#P connect 6 0 5 0;
#P fasten 10 0 5 0 36 365 196 365 196 257 143 257;
#P lcolor 4;
#P fasten 2 2 13 0 129 293 143 293;
#P connect 5 0 13 0;
#P connect 0 0 9 1;
#P fasten 4 1 6 1 171 192 216 192;
#P pop;
#P newobj 234 245 60 9109513 p presetrdm;
#N vpreset 24;
#X append 1 2 3 126 71 multiSlider list 92 94 123 60 1 69 22 1 ;;
#X append 3 2 3 126 71 multiSlider list 24 60 51 2 105 43 63 107 ;;
#X append 5 2 3 126 71 multiSlider list 82 22 98 65 30 56 120 78 ;;
#X append 8 2 3 126 71 multiSlider list 67 46 100 117 84 73 11 27 ;;
#X append 10 2 3 126 71 multiSlider list 28 40 0 65 76 72 13 5 ;;
#X append 12 2 3 126 71 multiSlider list 120 122 124 27 91 61 43 55 ;;
#X append 13 2 3 126 71 multiSlider list 26 66 31 119 53 71 119 30 ;;
#X append 17 2 3 126 71 multiSlider list 65 13 78 76 69 10 26 112 ;;
#X append 20 2 3 126 71 multiSlider list 63 52 100 95 118 5 21 58 ;;
#X append 24 2 3 126 71 multiSlider list 121 48 100 68 57 123 39 92 ;;
#P preset 256 176 66 52;
#P connect 2 0 1 0;
#P fasten 1 0 0 0 239 269 225 269 225 168 261 168;
#P connect 0 1 1 1;
#P window clipboard copycount 4;


January 18, 2007 | 10:34 am

dang, that’s about as good as it gets. the "recalled preset #" (if it doesn’t exist) doesn’t even get sent into the subpatch to be stored in the coll. no need for an if statement for the coll data, nicely done.

-C


January 18, 2007 | 11:05 am

I keep it for me!

But when a user lib for putting all those pearls???
(Je vous l’demande ;-)

Well done!

Bye,
Philippe


January 18, 2007 | 11:12 am

Wow. Thats just brilliant!

Many thanks gusanomaxlist and to the rest of you guys who helped.


January 18, 2007 | 11:38 am

Merci !
I’m glad that it helps ;)

_y.


January 18, 2007 | 1:00 pm

I’ve made some slight alterations to the patch so it can be turned on and off at will and will detect any change in the number of presets during the process. I thought somebody might find it useful.

Just attach a switch to a send object with the same name as the receive!

Thanks guys

Rhys

max v2;
#N vpatcher 559 47 1029 647;
#P origin 30 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 159 178 14 196617 0;
#P flonum 256 274 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 5 48 55 196617 select 0 1;
#P message 5 240 33 196617 clear;
#P newex 5 27 93 196617 r RandomPresetOn;
#P newex 27 90 72 196617 deferlow;
#P window linecount 2;
#N counter 0 1 256;
#X flags 0 0;
#P newobj 111 213 74 196617 counter 0 1 256;
#P window linecount 1;
#P message 46 209 33 196617 length;
#N comlet to preset;
#P outlet 111 367 15 0;
#N coll ;
#P newobj 46 331 48 196617 coll;
#P message 46 397 39 196617 clear;
#P newex 4 397 30 196617 + 1;
#P newex 111 155 38 196617 gate;
#P newex 27 110 40 196617 t 0 b 1;
#P newex 4 373 52 196617 Urn;
#P newex 111 251 83 196617 pack 0 0;
#N coll ;
#P newobj 111 335 48 196617 coll;
#P newex 111 184 38 196617 t b i;
#P newex 49 168 52 196617 uzi 256;
#N comlet bang random preset;
#P inlet 4 344 15 0;
#N comlet from preset middle outlet;
#P inlet 139 122 15 0;
#P window linecount 6;
#P comment 176 29 93 196617 HUGE thanks goes out to gusanomaxlist from the cycling74 forums for help with this one!;
#P connect 2 0 7 0;
#P fasten 11 0 7 0 51 420 89 420 89 366 9 366;
#P connect 7 0 10 0;
#P connect 17 0 19 0;
#P connect 19 0 18 0;
#P connect 19 1 16 0;
#P connect 16 0 8 0;
#P fasten 3 1 14 0 75 200 51 200;
#P fasten 18 0 12 0 10 270 51 270;
#P connect 14 0 12 0;
#P connect 6 0 12 0;
#P connect 12 0 7 1;
#P connect 7 1 11 0;
#P fasten 8 1 3 0 47 160 54 160;
#P fasten 8 2 9 0 62 137 116 137;
#P fasten 8 0 9 0 32 130 116 130;
#P connect 9 0 4 0;
#P connect 4 0 15 0;
#P connect 15 0 6 0;
#P fasten 10 0 5 0 9 429 169 429 169 321 116 321;
#P lcolor 4;
#P connect 6 0 5 0;
#P fasten 18 0 5 0 10 325 116 325;
#P fasten 3 2 13 0 96 309 116 309;
#P connect 5 0 13 0;
#P connect 1 0 9 1;
#P fasten 19 0 21 0 10 76 164 76;
#P connect 21 0 15 3;
#P fasten 4 1 6 1 144 208 189 208;
#P connect 15 0 20 0;
#P pop;


January 19, 2007 | 11:17 am

Philippe Gruchet wrote:
> But when a user lib for putting all those pearls???
> (Je vous l’demande ;-)

I have a "3rd party examples" folder within my examples folder. I just
store all the pearls there…
elsewise they remain within the archives…

What could be done is a kind of rating system for patches within the
list/forum. Based on the number of replies to a posted patch, and/or
user interaction/votes including categorisation (it should consider that
a lot never touch the forum though, like me)

But thats something for Wallace to consider…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


January 19, 2007 | 4:29 pm

Quote: Dr. Spankenstein wrote on Wed, 17 January 2007 11:14
—————————————————-
> Is there any way of obtaining the number of presets stored in a preset object as an integer?

Since, like many people, I’ve more or less abandoned
the preset object in favor of pattr, I thought I’d
mention that if you send the message getslotlist to
any given pattrstorage you’re using, it’ll obligingly
send the list "slotlist " out its outlet, where
is a list of all the currently stored
presets. A route object and some garden-variety Max
list processing, and presto.

Should you be the sort of person who’s slavishly
addicted to that little box thingie, there are various
things written for the js object that will obligingly
create something for you that looks like it. I know
that Ali Momeni has a version out there. I’m sure you
can find it at http://www.maxobjects.com


January 20, 2007 | 2:00 am

Stefan Tiedje wrote:
> What could be done is a kind of rating system for patches within the
> list/forum. Based on the number of replies to a posted patch, and/or
> user interaction/votes including categorisation (it should consider
> that a lot never touch the forum though, like me)

A standardized way of storing patch metadata (title, subject, keywords,
whatever) might help in an automated collection system for posted
patches. It would be particularly nice to have a flag for "question"
and "answer". Of course this would require a bit of human effort, but
people that are posting pedagogical replies might be inclined to follow
through on that anyway.

So what is the best way to create this metadata so that it is included
in a text patch in a format efficiently parsed by the forum server?

Another question for Wallace…


January 20, 2007 | 1:47 pm

>> But when a user lib for putting all those pearls?
—————————————————-
Stefan Tiedje wrote on Fri, 19 January 2007 12:17
> I have a "3rd party examples" folder within my examples folder.
> I just store all the pearls there…

Yes, it’s also what I do, but needing to put comments about all of them in a separate document. I’m using "URL Manager Pro" for that: not bad.

> elsewise they remain within the archives

Could be useful with a good built-in search engine.
That’s not so easy to find, currently.

> What could be done is a kind of rating system for patches
> within the list/forum. Based on the number of replies to a
> posted patch, and/or user interaction/votes including
> categorisation (it should consider that a lot never touch the
> forum though, like me)
—————————————————-
Not yet! ;-)
"Most users ever online was 8841 on Mon, 01 January 2007 14:02"
That’s a lot!

I was just thinking about a standard way of storing documents through an onboard forum.
The NI’s Reaktor user repertory seems to me the best ‘template’ for storing & sharing our Max patchers, abstractions, externals, js, Pluggo plug-ins, etc.
(The NI’s user lib has grandly contributed to the commercial success of Reaktor, btw.)
Currently, the only repertory is < http://www.maxobjects.com>,
and still no direct link (meaning no support?) from Cycling’ forum to this website :-(

Bye,
Philippe


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