Carlo

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?

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

multislider-bug-or-osx

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.

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.

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,

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...

https://cycling74.com/story/2005/5/2/133649/9742

Quote: carlo-laurenzi wrote on Fri, 09 November 2007 01:01

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

> 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.

full article available here:
https://cycling74.com/story/2005/5/2/133649/9742

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
----------------------------------------------------


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.

> 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 

Did I mention that I had overdrive on in windows when I made the screen 

I tried switching it off and what I had was a slightly distortion in 

> 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.

I still would like to know why there's this difference. If on Windows Max 

If cycling sponsors a multislider feature that turns out to not working well 

(by the way, I bought a Mac just to use Max on it, believing that Max works 

> 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().

 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.

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,

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.

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 

> 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 

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.

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 
>
----------------------------------------------------


Patch below shows that anyhow multislider is doing something quite inefficient.

> 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..)

Subject: [maxmsp] Re: Re: Multislider Bug? or Osx?

>> I still would like to know why there's this difference. If on Windows Max

>> If cycling sponsors a multislider feature that turns out to not working 

>> on Osx I feel like to ask for a reason.

> Patch below shows that anyhow multislider is doing something quite 

>> (by the way, I bought a Mac just to use Max on it, believing that Max 

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 

----- 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,

> 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 

It seems not to be a good idea to overflow the scheduler with such short 

And it also doesn't seem to be a good idea to abuse a multislider as a 

Think about the concept. some things are necessary and others are just 

what you are used to have, but might not really be necessary...

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

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?

Quote: carlo-laurenzi wrote on Fri, 09 November 2007 12:56
---------------------------------------------------- 
> How come that in windows this drawing problem doesn't happen?
----------------------------------------------------

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?
