Preset object - Fetching data.
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
Hi Doc,
Something to count # of stored presets?
I had that in my archives.
HTH,
P.G.
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,
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
zum Beispiel ?
... mmh, i feel like it could be simpler ...
_y.
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
I keep it for me!
But when a user lib for putting all those pearls???
(Je vous l'demande ;-)
Well done!
Bye,
Philippe
Wow. Thats just brilliant!
Many thanks gusanomaxlist and to the rest of you guys who helped.
Merci !
I'm glad that it helps ;)
_y.
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
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
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
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...
>> 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 ,
and still no direct link (meaning no support?) from Cycling' forum to this website :-(
Bye,
Philippe
in case anyone is looking for a solution that also updates the list when you delete a preset, check out this patch. Anyway, I think it would only make sense if the getslotlist message updated when you delete a preset and not sure why the smart guys at cycling didnt think of that.