Multislider query

Jun 26, 2007 at 9:43pm

Multislider query

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

I sure haven’t found any.

-C


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

#32644
Jun 26, 2007 at 9:51pm

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

jb

Am 26.06.2007 um 23:43 schrieb Chris Muir:

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

#107787
Jun 27, 2007 at 3:20am

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

-C


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

#107788
Jun 27, 2007 at 6:15am

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).
cheers,
volker.

#P button 88 73 20 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 88 101 30 196617 grab;
#P number 88 302 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 88 276 34 196617 zl len;
#P number 151 302 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 151 276 34 196617 zl len;
#P user multiSlider 151 133 193 132 -1. 1. 20 2681 15 0 0 2 0 0 0;
#M frgb 0 0 0;
#M brgb 255 255 255;
#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 comment 115 76 100 196617 length?;
#P connect 7 0 6 0;
#P connect 6 0 4 0;
#P connect 6 1 1 0;
#P connect 4 0 5 0;
#P connect 2 0 3 0;
#P connect 1 0 2 0;
#P window clipboard copycount 8;

#107789
Jun 29, 2007 at 1:38am

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? ;-)

-CJ

#107790
Jul 3, 2007 at 5:42pm

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


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

#107791

You must be logged in to reply to this topic.