Multislider Bug (?)
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.
I can’t reproduce that, could you post an example?
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…
You did not post your patch…
Haha, sorry. Here goes:
-- Pasted Max Patch, click to expand. --Copy all of the following text. Then, in Max, select New From Clipboard.----------begin_max5_patcher---------- 348.3occRssiCBBD8Y8qvvyVCh3E1eklMMHkzxtJZ.roca5+9NB5V8g0Dmvb Fl4LmS3YbDpc3tzhR9H4XRTzy3nHOzLPzRdDpmeWzws9qg5m5bJam5rzfRC0 uwMZduLTNeEczHsRsi6TC5SFovEXojlgSSpJxJgHF9lSKgXxmKMZkN2iQ+3v KPtqJw2ZYXExW.Eb8YEDjjvjwYETLqljBmnr7lF57olxlJVUZR9dF5UZPVqM BqPwl55InbmzsitQtSbUourQKGvYDPFGx+ewr0E1NM0YucMz90ABghdS7vja kYxeLa.60IMmjZda2NmwNxEvRsczsWDCcClUs0TPqYEyVAivn4d6ggqI006M k.wqN+wDDJE9e6Ype7EJw32tn08HrN4yPuhimC9VP7wwaRicQ19mRvCouB6U UpOUoCo9MGYj2Tq22KcD2.NtCr6IS3008lJT7LOuh+0pJLpR -----------end_max5_patcher-----------
i see nothing but a multislider in your patch.
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?
60000px wide, that’s a hell of a screen that you’ve got ;-)
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.
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?
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;-)
Thanks Peter for that very complete explanation. That makes much sense. Also, yes, I’m indeed a little crazy.
Forums > MaxMSP