Tarik

When changing the value of a simple live.numbox, it won't consistently send the number it displays. Especially when I change its value rapidly with the mouse, the output values can massively differ from the displayed number.

I tried to work around this by sending the live.numbox an additional bang 20ms after the change. Amazingly, it then AGAIN outputs the wrong number, proving that its internally stored value is a different one than the one it shows.

this is true at least on Mac, across different max and Live versions.

is there any workaround for this remarkably fundamental bug?

Hi all,
When changing the value of a simple live.numbox, it won't consistently send the number it displays. Especially when I change its val

live-numbox-bug-it-doesn't-send-the-value-it-displays

So, see here a little workaround that will at least force the numbox to display its last output value, by feeding the value back into itself. The problem with this workaround however is that it will overwrite automation in Ableton.

It's not a great choice: either not knowing what value my parameter has, or not being able to automate it...

workaround.jpg

So, see here a little workaround that will at least force the numbox to display its last output value, by feeding the value back into itself. The problem with this workaround however is that it will overwrite automation in Ableton.
  It's not a great choice: either not knowing what value my parameter has, or not being able to automate it...

I can replicate the problem! Except the values only differ max +1 or -1.

Hey Tarik,
I can replicate the problem! Except the values only differ max +1 or -1.

And, this problem also occurs when I link a midi slider to a number: I want to set an effect to 0, the midi slider is all the way down, but the parameter is still set to 0.08 for instance. This uses up CPU resources and distorts my audio/visuals. 10 seconds later I see that somethings slightly off and I need to move all my sliders up and down a bit to even see where the problem was.

Thanks Yurki!
  And, this problem also occurs when I link a midi slider to a number: I want to set an effect to 0, the midi slider is all the way down, but the parameter is still set to 0.08 for instance. This uses up CPU resources and distorts my audio/visuals. 10 seconds later I see that somethings slightly off and I need to move all my sliders up and down a bit to even see where the problem was.

Bump! Anybody from cycling want to comment on this? It's a pretty noteworthy and fundamental problem.

Sorry guys, gonna keep spamming this post with bumps until it gets noticed.

hey Tarik, if your post doesn't get noticed and you think it's a bug, best to file a bug report from the "Support" menu above.

Did it! I was convinced that many users must be running up against this and I hoped I was providing a public service by posting it here, though admittedly the lack of general response suggests otherwise. 

Did it! I was convinced that many users must be running up against this and I hoped I was providing a public service by posting it here, though admittedly the lack of general response suggests otherwise. 

Cheers

Answer I got for the bug report (posting for others who run into this): this is a known bug with no workarounds. But lowering the audio buffer size will reduce the problem.

not saying this is pretty or desirable, but a possible workaround is to put an invisible 'vanilla' number box on top of the live.number

Tarik, thanks for filing the support request and report that here.

FWIW there was another thread with traffic on it recently for this problem, but not the most helpful title, so I can see why you missed it!

https://cycling74.com/forums/problem-with-live

Tarik, thanks for filing the support request and report that here. 

https://cycling74.com/forums/problem-with-live·dial-live·numbox-and-live·slider

for some reason live.numbox objects don't output anything when they are in old amxd files

but they do work fine when they're used inside Max or in a new patcher

I am experiencing the same bug: 
for some reason live.numbox objects don't output anything when they are in old amxd files
but they do work fine when they're used inside Max or in a new patcher


oops sorry, I just realize that when a M4L device is edited while in a deactivated state, its live.numbox objects don't send anything (because they're also deactivated, that makes sense!)

Hey all. I hope that someone has sorted this out, please let us know!

But with live.dial and live.numberbox if you use parameters less than 127 and more than 191 it truncates the list so you get odd or even numbers, ie 0%-100% will give you 0% then 2% and then 4%. An easy way to control this, using the percentage example, is to use Enum and add 27 100%'s to the list. Then clip between 0 and 100. This will give you all the numbers in your list and a smooth movement. Oddly you can have 191 numbers in the Enum before it starts truncating.... why not 200? 1000?

Live.dial fix.maxpat

Hey all. I hope that someone has sorted this out, please let us know!
But with live.dial and live.numberbox if you use parameters less than 127 and more than 191 it truncates the list so you get odd or even numbers, ie 0%-100% will give you 0% then 2% and then 4%. An easy way to control this, using the percentage example, is to use Enum and add 27 100%'s to the list. Then clip between 0 and 100. This will give you all the numbers in your list and a smooth movement. Oddly you can have 191 numbers in the Enum before it starts truncating.... why not 200? 1000?

Hi Bradley, you may want to set the parameter’s ”steps” attribute (to 101 for 0-100%) rather than use an enum.

I didn't find that the steps fix the situation

live.numbox bug: it doesn't send the value it displays