Chris Muir

Is there any way to find out the number of sliders are in a mutislider?

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

-- 
Chris Muir           | "There are many futures and only one status quo.
cbm@well.com         |  This is why conservatives mostly agree,
http://www.xfade.com |  and radicals always argue." - Brian Eno


multislider-query

You could bang it and count the number of items in the list.

Am 26.06.2007 um 23:43 schrieb Chris Muir:

> Is there any way to find out the number of sliders are in a 

>
>
> Is there any way to find out the number of sliders are in a  
> mutislider?
>
> I sure haven't found any.
>
> -C


At 11:51 PM +0200 6/26/07, Jeremy Bernstein wrote:

>You could bang it and count the number of items in the list.

Wow. So obvious, yet I didn't consider that. It presents some complications in my current project, but can be made to work. Thanks.

That said, next time somebody touches multislider, how about a length message (or similar)?

At 11:51 PM +0200 6/26/07, Jeremy Bernstein wrote:
>You could bang it and count the number of items in the list.

On 27 Jun 2007, at 05:20, Chris Muir wrote:

> At 11:51 PM +0200 6/26/07, Jeremy Bernstein wrote:

>> You could bang it and count the number of items in the list.

> Wow. So obvious, yet I didn't consider that. It presents some 

> complications in my current project, but can be made to work.

in addition to what jeremy said, you could use [grab] to "grab" the 

output list from multislider in order to count it (zl len), so asking 

for the length won't interfere with the rest of the program flow. 

maybe this makes things easier (see below).

> At 11:51 PM +0200 6/26/07, Jeremy Bernstein wrote:
>> You could bang it and count the number of items in the list.
>
> Wow. So obvious, yet I didn't consider that. It presents some  
> complications in my current project, but can be made to work.

in addition to what jeremy said, you could use [grab] to "grab" the  
output list from multislider in order to count it (zl len), so asking  
for the length won't interfere with the rest of the program flow.  
maybe this makes things easier (see below).
cheers,
volker.

I would just have a number box value for your multislider's Size attribute, then you always have that information (possible values = 1 to 4095). If you ever change the size dynamically (and might not know where it's currently at, like with a random or something) it has to go through the size $1 command anyways. This is also where you can get your Length message.

A reason not to count the output list is the zl 256-element limit which poses awkwardness with larger multisliders---do you really want to do all that slicing and counting? ;-)

A reason not to count the output list is the zl 256-element limit which poses awkwardness with larger multisliders---do you really want to do all that slicing and counting?  ;-)

> If you ever change the size dynamically (and might not know where

> it's currently at, like with a random or something) it has to go

This is not true, multislider resizes itself with the length of an

incoming list (and that's probably the reason for putting up the

thread). But you can easily use [mxj list.Length], should be no problem

Seejay James schrieb:
> If you ever change the size dynamically (and might not know where
> it's currently at, like with a random or something) it has to go
> through the size $1 command anyways.

This is not true, multislider resizes itself with the length of an
incoming list (and that's probably the reason for putting up the
thread). But you can easily use [mxj list.Length], should be no problem
with longer sizes.

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


Multislider query