Completely overlooked this multislider feature


    Nov 28 2007 | 1:54 pm
    I'm sure this is old news for a lot of you, but I just discovered (by total accident) a feature of multislider that's really useful.
    Apparently you can set values in a scrolling display of multisliders as well as in Thin Line or Bar mode. I had thought these modes were display-only, as there's nothing in the Help file about this. The documentation also reads (p. 362):
    "The way that a multislider responds to the mouse is determined by its chosen display style (see Arguments, below). A multislider will respond to mouse clicks when its display style is non-scrolling (Thin Line or Bar). Clicking on a forward or reverse scrolling display multislider (Point Scroll or Line Scroll) has no effect."
    Well, on XP and 4.6.2, I can set the values of a scrolling display as well, but only when it's in Reverse Scroll mode (point or line). You just have to know where in the X axis to click / drag (if in horiz. mode, opposite for vertical). So in the example patch there's a "ruler" at the bottom to keep track of the divisions. (The ruler isn't clickable in this patch, for clarity.)
    Like I said, totally by accident. Wondering if this was some kind of oversight in the docs? Will the R to L versions be active in Max 5? Scrolling is a really great alternative to the regular modes, because you can see the history. But I thought it was limited by being read-only... apparently not. Very cool!
    --CJ
    -----------------------------

    • Nov 28 2007 | 9:29 pm
      Quote: seejayjames wrote on Wed, 28 November 2007 14:54
      ----------------------------------------------------
      > I'm sure this is old news for a lot of you, but I just discovered (by total accident) a feature of multislider that's really useful.
      Not sure if this is a intended feature, it's almost too exotic. It seems that multislider is still tracking vertical fader setting while behing in horizontal scrolling mode. If it is useful, you could anyhow build something using a ubutton, then it could also work for scrolling in the other direction.
      _
      johan
    • Nov 28 2007 | 11:50 pm
      very nice find... great patch too. thanks for sharing
    • Nov 29 2007 | 6:55 am
      Thanks, it was pretty fun to experiment with. I think it'll be useful because of the history it shows (like for amp / effect levels over time, or real-time user ratings of something). So there's also a way to change the sliders as well as view the history, this gives a second dimension to the interaction (comparison of present to past). Probably should add some sort of timeline to see how long the overall picture represents... overall horiz. pixel size * update rate. Looks like the "hold Shift to constrain to one slider" works too.
      I wonder if this was an intended feature but they only got it to work going one direction so they didn't document it? I can certainly sympathize with that... you probably don't want people to say "what the heck is going on?" Maybe ignorance is bliss in that case ;)
      At any rate, it's pretty interesting in my book. I suppose a "snapshot" feature to save all the visible history data is too much to ask, but that's what happens when you have a cool UI object and you start to get ideas, heh. It would be nice though, especially if one worked out some kind of playback or scrub of the history list values.
      --CJ
    • Nov 29 2007 | 7:32 am
      On 29 nov. 07, at 07:55, Seejay James wrote:
      > I wonder if this was an intended feature but they only got it to
      > work going one direction so they didn't document it? I can certainly
      > sympathize with that... you probably don't want people to say "what
      > the heck is going on?" Maybe ignorance is bliss in that case ;)
      Well, it's a bug. I wouldn't count on it too much in the future. Other
      alternative like using ubutton, mousestate seems to be more appropriate.
      Cheers,
      ej