Multislider Bug (?)

    May 10 2013 | 8:05 pm
    I've been fiddling with a dozen [multisliders] inside a medium size patch. I am resizing these [multisliders] in real-time, and sometimes give them fairly big numbers (like 3,000 sliders pero object). The problem is that Max will repeatedly crash upon some random resizing.
    I realize that perhaps [multislider] is not the best object to be playing with in terms of a hundred variables, but is this normal? If it is, can someone suggest a better UI alternative? I don't want [matrixtctrl} because it relies on rasterized graphics so when I resize the object the patch will slow down notoriously. Thanks.

    • May 10 2013 | 8:37 pm
      I can't reproduce that, could you post an example?
    • May 10 2013 | 10:11 pm
      Yes you are right Emmanuel, my mistake.
      Now, one other question:
      I just found there is a limit to a patching windows working size. Please see below the example, where [multislider] is cut above the 60,000px width point (actually it is cut at around 45,000px). Is there a way to circumvent this? And I know, whatever I'm trying to do, this is probably not the most elegant solution...
    • May 10 2013 | 10:54 pm
      You did not post your patch...
    • May 10 2013 | 10:56 pm
      Haha, sorry. Here goes:
    • May 11 2013 | 9:16 am
      i see nothing but a multislider in your patch.
    • May 13 2013 | 1:32 pm
      Yes, the patch is supposed to show how the multislider is chopped at its right end because it is longer than the (I suppose) patcher window's display capability. If you scroll to the extreme right you will see this clearly. I kind of switched my approach, but since the question is still floating I decided to reply to your message, out of curiosity and for posterity.
      So, is this a bug, or expected behavior? Can you change the patcher window's total working area?
    • May 13 2013 | 4:47 pm
      60000px wide, that's a hell of a screen that you've got ;-)
    • May 14 2013 | 9:42 pm
      LOL --- send me one a them monitors!
      I remember running into this in Max 4, where I think the screen wrapped at 32,768. Will have to check out how 5 and 6 deal with this.
    • May 15 2013 | 3:00 am
      Hehehe, I didn't know about that LITTLE detail.  I still don't understand the technicality behind this, namely, is it my screen, Max, or both? What is the  difference between vertical scrolling a la Tumblr and horizontal scrolling like in this patch? Is it that tumblr uses a scripted buffer of some sorts?
    • May 16 2013 | 9:58 am
      The limitation is, at least partly, historic. In the QuickDraw drawing environment on Classic Mac OS, window coordinates were signed shorts (16-bit) integers, usually positive. So that put a hard limit of 32,767 pixels on anything you wanted to draw.
      QuickDraw has long since been superseded, several times for that matter. But many objects may still make low-level assumptions about size limits, etc., that date from QD days. If you're doing crazy things with drawing, then you ought to make yourself aware of these limitations. They'll come and bite you otherwise.
      In case there's any doubt, a 60,000-pixel multislider is crazy.
      Wait, scratch that. Terribly impolite to express myself like that, mate. Sorry.
      A 60,000-pixel multislider is fucking crazy. There, that's better;-)
    • May 16 2013 | 2:46 pm
      Thanks Peter for that very complete explanation. That makes much sense. Also, yes, I'm indeed a little crazy.