Dr. Spankenstein

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.

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

preset-object-fetching-data

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,

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:

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.

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.

... mmh, i feel like it could be simpler ...

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.

But when a user lib for putting all those pearls???

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

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

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!

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.  

> But when a user lib for putting all those pearls???

I have a "3rd party examples" folder within my examples folder. I just 

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

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)

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

presets. A route object and some garden-variety Max

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

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


> 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

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?

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?

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

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.

> 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 

"Most users ever online was 8841 on Mon, 01 January 2007 14:02"

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

and still no direct link (meaning no support?) from Cycling' forum to this website :-(

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

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 :-(

Preset object - Fetching data.