arne

Once again, a request to make things the same between objects...

It would be great if the multislider horizontal vs. vertical orientation was automatic, as it is with slider (which is very nicely improved!) and rslider.

And an object that I always wanted was a multi-rslider, but that's another thread...

max-5-multislider-request

Quote: arne wrote on Sat, 26 April 2008 20:18

----------------------------------------------------

> Once again, a request to make things the same between objects...

> It would be great if the multislider horizontal vs. vertical orientation was automatic, as it is with slider (which is very nicely improved!) and rslider.

I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other? see aatchment.

> And an object that I always wanted was a multi-rslider, but that's another thread...

Quote: arne wrote on Sat, 26 April 2008 20:18
----------------------------------------------------
> Once again, a request to make things the same between objects...
>
> It would be great if the multislider horizontal vs. vertical orientation was automatic, as it is with slider (which is very nicely improved!) and rslider.

I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other? see aatchment.
>
> And an object that I always wanted was a multi-rslider, but that's another thread...

> I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other?

Exactly how Max "knows" if you want a fat vertical slider vs. a narrow

>  I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other?

Exactly how Max "knows" if you want a fat vertical slider vs. a narrow
horizontal one.

Quote: arne wrote on Sat, 26 April 2008 21:21

> > I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other?

> Exactly how Max "knows" if you want a fat vertical slider vs. a narrow

as soon as i make a slider wider than it's high it will be a horizontal slider.

as soon as i make a slider higher than it's wide it will e a vertical slider.

if i make it wider than it is high i could still want either: long horizontally oriented sliders above each other or short vertically oriented sliders next to each other. 

if i make it higher than it is wide i could still want either: long vertically oriented sliders next to each other or short horizontally oriented sliders above each other.

so how do you imagine this? i don't see how the mechanism that is used for switching between horizontal and vertical in slider could be used in multislider without losing the options of having:

- short vertical sliders in a wide multislider object

- short horizontal sliders in a high multislider object

only the two "longer slider" options remain, where now there are four.

have you opened the patch i attached? with the automatically switching mechanism you suggest the top option wouldn't be possible anymore, right?

(i wouldn't want to lose the option of having the bottom two multisliders..)

Quote: arne wrote on Sat, 26 April 2008 21:21
----------------------------------------------------
> 2008/4/26 Klaas-Jan Govaart:
>
> >  I don't think it would work.. How does Max "know" if I want 10 short sliders next to each other, vs 10 long sliders above each other?
>
> Exactly how Max "knows" if you want a fat vertical slider vs. a narrow
> horizontal one.
>
> It doesn't, but assumes generality.
>
----------------------------------------------------

as soon as i make a slider wider than it's high it will be a horizontal slider.
as soon as i make a slider higher than it's wide it will e a vertical slider.

if i make it wider than it is high i could still want either: long horizontally oriented sliders above each other or short vertically oriented sliders next to each other. 
if i make it higher than it is wide i could still want either: long vertically oriented sliders next to each other or short horizontally oriented sliders above each other. 

so how do you imagine this? i don't see how the mechanism that is used for switching between horizontal and vertical in slider could be used in multislider without losing the options of having: 

- short vertical sliders in a wide multislider object
- short horizontal sliders in a high multislider object

have you opened the patch i attached? with the automatically switching mechanism you suggest the top option wouldn't be possible anymore, right?
or am i not understanding you?

patches speak louder than words:
(i wouldn't want to lose the option of having the bottom two multisliders..)

> as soon as i make a slider wider than it's high it will be a horizontal slider.

> as soon as i make a slider higher than it's wide it will e a vertical slider.

Both slider and multislider can be edited in the inspector.

I would simply assume that the long orientation becomes the default.

>  as soon as i make a slider wider than it's high it will be a horizontal slider.
>  as soon as i make a slider higher than it's wide it will e a vertical slider.
>
>  with multislider this won't work.

I would simply assume that the long orientation becomes the default.


Quote: arne wrote on Sun, 27 April 2008 02:25

> Both slider and multislider can be edited in the inspector.

> I would simply assume that the long orientation becomes the default.

so you trade in one option that needs to be set from time to time for another. ok.

Quote: arne wrote on Sun, 27 April 2008 02:25
----------------------------------------------------
> OK, this is getting silly.
>
> Both slider and multislider can be edited in the inspector.
>
> I would simply assume that the long orientation becomes the default.
>
----------------------------------------------------

In 99% of all cases of my personal use, it is correct as it is now.

What I would like though, if I type in an object box [multislider 20] 

that it would instantiate with 20 sliders.

I have to open the inspector usually always to define the number of 

sliders which is never 1 (the actual default)...

Arne Eigenfeldt schrieb:
> I would simply assume that the long orientation becomes the default.

In 99% of all cases of my personal use, it is correct as it is now.
Seems a matter of taste...

What I would like though, if I type in an object box [multislider 20] 
that it would instantiate with 20 sliders.

I have to open the inspector usually always to define the number of 
sliders which is never 1 (the actual default)...

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

On 28 avr. 08, at 09:38, Stefan Tiedje wrote:

> What I would like though, if I type in an object box [multislider 

> 20] that it would instantiate with 20 sliders.

> What I would like though, if I type in an object box [multislider  
> 20] that it would instantiate with 20 sliders.

That works nicely, but I am not sure if opening the inspector or typing 

@size is more hassle... (that means I still would like to see it... ;-)

This would also apply to bpatcher for example, if I'd type a patcher 

name as argument, I'd like bpatcher to load it...

I guess there are equivalently other UI's which would benefit from 

passing arguments to initiate them: jsui, fpic, pictslider to name a few 

(all which load a file, and some which have an obvious main attribute 

Not urgent for sure, but would be nice...

Emmanuel Jourdan schrieb:
> How about [multlisder @size 20]?

That works nicely, but I am not sure if opening the inspector or typing 
@size is more hassle... (that means I still would like to see it... ;-)

This would also apply to bpatcher for example, if I'd type a patcher 
name as argument, I'd like bpatcher to load it...

I guess there are equivalently other UI's which would benefit from 
passing arguments to initiate them: jsui, fpic, pictslider to name a few 
(all which load a file, and some which have an obvious main attribute 
like multislider...)

On 29 avr. 08, at 09:58, Stefan Tiedje wrote:

> That works nicely, but I am not sure if opening the inspector or 

> typing @size is more hassle... (that means I still would like to see 

> This would also apply to bpatcher for example, if I'd type a patcher 

> name as argument, I'd like bpatcher to load it...

> I guess there are equivalently other UI's which would benefit from 

> passing arguments to initiate them: jsui, fpic, pictslider to name a 

> few (all which load a file, and some which have an obvious main 

> Not urgent for sure, but would be nice...

I'm not sure it's ever going to happen. When you write [multislider 

@size 50], you can pass any of the attributes of the objects, so it's 

completely transparent. Otherwise that would mean to treat each object 

independently to have their own way of dealing with arguments. You can 

also add a keycommand for that if you want, like the one you have now 

> That works nicely, but I am not sure if opening the inspector or  
> typing @size is more hassle... (that means I still would like to see  
> it... ;-)
>
> This would also apply to bpatcher for example, if I'd type a patcher  
> name as argument, I'd like bpatcher to load it...
>
> I guess there are equivalently other UI's which would benefit from  
> passing arguments to initiate them: jsui, fpic, pictslider to name a  
> few (all which load a file, and some which have an obvious main  
> attribute like multislider...)
>
> Not urgent for sure, but would be nice...

I'm not sure it's ever going to happen. When you write [multislider  
@size 50], you can pass any of the attributes of the objects, so it's  
completely transparent. Otherwise that would mean to treat each object  
independently to have their own way of dealing with arguments. You can  
also add a keycommand for that if you want, like the one you have now  
in 5.0.1 for jitter objects (press 'j').

I use a waveform~ instead of a rslider, since the interface is better with the loop tool. you just have to load in a dummy buffer for it to go. Then you could have multiple ones linked together, or do each separately. The waveform~ provides all the functions of the rslider but adds the loop tool, which is really nice.

Max 5 Multislider request