Multislider Bug? or Osx?


    Nov 08 2007 | 8:34 pm
    Hi all, I'm having some troubles with some tables driving multisliders: when changing the reading speed of a table, the correpondent multislider shows distorted waveforms (always different ones). But this happens only in Osx. In windows Xp everything is drawn fine by multisliders, even at high speed rates when reading a table. Why this happens? Is a multislider bug or something related to Osx? Take a look at the pictures in Osx and Windows of the same patch with the same values to evaluate the problem. I'm also including the original max patch. Can someone at Cycling explain this behaviour? Or tell me how can I get a correct, non-sidetracking, behaviour? My setups:
    Notebook: MacBook Pro 17" 2.33 ghz 2 Gb ram 667mhz 100 Gb 7200 rpm HD Ati radeon 1600 video card 256 mb ram OSX 10.4.10 Max Msp 4.6.3 / Jitter 1.6.3
    Dekstop PC: AMD Athlon 64 3200+ Windows XP SP2 GeForce 6600 GT 128 Mb ram 1 Gb 7200 rpm HD Max Msp 4.6.3 / Jitter 1.6.3
    Thank you very much.
    Carlo Laurenzi

    • Nov 09 2007 | 12:41 am
      I get vastly different results in OSX with your patch depending on whether or not overdrive is switched on.
      When it's on I see similar reults to your OSX screenshots. When off the results look much more similar to the Windows screenshots.
      Perhaps this is the issue here.
      Regards,
      Alex
    • Nov 09 2007 | 1:01 am
      Really? Quite strange.. Overdrive on should guarantee better performance.. Moreover, switching overdrive on and off in Windows confirm this: if overdrive is on multislider draws prefectly at all reading speeds of the table, while switching it off gives me slight distorted graphic results (not so distorted as on my MacBookPro). I think at this point Cycling74 staff should give us an explanation about this crappy behaviour on Osx. Best,
      Carlo
    • Nov 09 2007 | 10:18 am
      cant speak on behalf of c74!
      but AFAIK overdrive isnt simply about guaranteeing better performance. its to do with the scheduler in maxmsp and what it prioritises, if switched on it will defer graphic calls to the bottom of the scheduler queue. That way it can focus on more essential tasks such as metro timing accuracy etc...
      j
      Quote: carlo-laurenzi wrote on Fri, 09 November 2007 01:01 ---------------------------------------------------- > Really? > Quite strange.. > Overdrive on should guarantee better performance.. > Moreover, switching overdrive on and off in Windows confirm this: if overdrive is on multislider draws prefectly at all reading speeds of the table, while switching it off gives me slight distorted graphic results (not so distorted as on my MacBookPro). > I think at this point Cycling74 staff should give us an explanation about this crappy behaviour on Osx. > Best, > > Carlo ----------------------------------------------------
    • Nov 09 2007 | 11:03 am
      First of all: the fact that the multisliders have drawing problems means nothing about the patch output. Screen update has about the lowest priority of anything in Max. Most everything else has higher priority.
      Second: table lookup in Max is not necessarily more efficient than calculating a log or trig function. Message passing between objects probably eats more CPU than a call to sin().
      3rd: Overdrive is not about "better performance". It's about whether scheduler events (metro & Co.) can interrupt other processing. In particular, with Overdrive off, screen redrawing is much less likely to be interrupted by metro bangs. Hence the negative effect of Overdrive on your multislider drawing.
      In summary: this is not a 'bug' in Multislider per se. You're simply feeding your multisliders data faster than they can do a complete redraw.
    • Nov 09 2007 | 11:56 am
      Dear Peter, Thanks for your reply,
      > First of all: the fact that the multisliders have drawing problems means > nothing about the patch output. Screen update has about the lowest > priority of anything in Max. Most everything else has higher priority.
      How come that in windows this drawing problem doesn't happen?
      > Second: table lookup in Max is not necessarily more efficient than > calculating a log or trig function. Message passing between objects > probably eats more CPU than a call to sin().
      Probably yes, but still, on windows max doesn't show this behaviour..
      > 3rd: Overdrive is not about "better performance". It's about whether > scheduler events (metro & Co.) can interrupt other processing. In > particular, with Overdrive off, screen redrawing is much less likely to be > interrupted by metro bangs. Hence the negative effect of Overdrive on your > multislider drawing.
      Did I mention that I had overdrive on in windows when I made the screen capture? I tried switching it off and what I had was a slightly distortion in multislider drawings.
      > In summary: this is not a 'bug' in Multislider per se. You're simply > feeding your multisliders data faster than they can do a complete redraw.
      You're definitely right. It's not a multislider bug. But something related to differences between max msp for Osx and the windows version.
      > Peter Castine
      I still would like to know why there's this difference. If on Windows Max can do it, why on Osx don't? If cycling sponsors a multislider feature that turns out to not working well on Osx I feel like to ask for a reason. (by the way, I bought a Mac just to use Max on it, believing that Max works better under osx..) Best,
      Carlo
    • Nov 09 2007 | 12:51 pm
      my take on this would be that different OS architecture = different scheduling in Max. i dont think there is much C74 can do about this, short of writing their own OS!
      if you're after something visual that is more reliable in OSX you might be better off doing it in Jitter - which IMO would give you more control with drawing calls / scheduler issues.
      j
      Quote: carlo-laurenzi wrote on Fri, 09 November 2007 11:56 ---------------------------------------------------- > I still would like to know why there's this difference. If on Windows Max > can do it, why on Osx don't? > If cycling sponsors a multislider feature that turns out to not working well > on Osx I feel like to ask for a reason. > (by the way, I bought a Mac just to use Max on it, believing that Max works > better under osx..) > Best, > > Carlo > ----------------------------------------------------
    • Nov 09 2007 | 2:22 pm
      > I still would like to know why there's this difference. If on Windows Max > can do it, why on Osx don't? > If cycling sponsors a multislider feature that turns out to not working well > on Osx I feel like to ask for a reason.
      Patch below shows that anyhow multislider is doing something quite inefficient.
      > (by the way, I bought a Mac just to use Max on it, believing that Max works > better under osx..)
      Why would you imagine so?
      _ johan
    • Nov 09 2007 | 6:49 pm
      ----- Original Message ----- From: "jvkr" To: Sent: Friday, November 09, 2007 3:22 PM Subject: [maxmsp] Re: Re: Multislider Bug? or Osx?
      > >> I still would like to know why there's this difference. If on Windows Max >> can do it, why on Osx don't? >> If cycling sponsors a multislider feature that turns out to not working >> well >> on Osx I feel like to ask for a reason. > > > Patch below shows that anyhow multislider is doing something quite > inefficient. > > >> (by the way, I bought a Mac just to use Max on it, believing that Max >> works >> better under osx..) > > Why would you imagine so? > > > _ > johan
      I didn't think about using Lcd instead of multislider.. good idea! I bought the Mac to use MaxMsp with real time algorithms, because Osx is more stable and CPU-eager than WinXP. There's more CPU headroom. If I want I can run Max and a Sequencer (like Digital Performer or Logic) at the same time without any worries. I wouldn't do that on XP, above all when using many audio tracks in the sequencer.. Best,
      Carlo
    • Nov 10 2007 | 1:11 pm
      jvkr schrieb: > Patch below shows that anyhow multislider is doing something quite inefficient.
      replace the metro with a qmetro and the visuals at least look more the same. The way the LCD is drawn is different to the way the multislider is drawn...
      It seems not to be a good idea to overflow the scheduler with such short ticks in any regard... And it also doesn't seem to be a good idea to abuse a multislider as a visual display in this case...
      Think about the concept. some things are necessary and others are just what you are used to have, but might not really be necessary...
      Stefan
      -- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
    • Nov 10 2007 | 11:11 pm
      Quote: carlo-laurenzi wrote on Fri, 09 November 2007 12:56 ---------------------------------------------------- > How come that in windows this drawing problem doesn't happen? ----------------------------------------------------
      Maybe because the Windows drawing API is different from the Mac OS drawing API?
      I don't know the Windows drawing API well enough to answer your question in detail, but these are simply two very different animals and they behave in different ways. Maybe it has to do with the way Mac OS double-buffers window contents?
      In any case, if you're asking for redraws at >3000 per second, you might want to consider that that is 30 times faster than typical screen refresh rates. What is the point of that?