Problem with live.dial, live.numbox, and live.slider
OK so i've been working on a patch with live 10.0.1 and max 8 and I noticed that when I change the values of the live user interface knobs quickly the final value output by the objects is not always the one that's displayed. At first I thought I was overloading max or something as my patch was pretty cpu heavy but then I made a test with only the m4l.bal2~ object and the different ui objects and the same thing happened.
Is it just my computer or something? Am I doing something wrong? This didn't seem to happen before.
I got exactly the same issue you are describing, checked same patch on Live 9, no problem. Any news on this one?
here is an example of the problem
any news on this problem?
Hello? anyone on that side?
but see, it has "node" now, which lets you post your bugs directly on facebook and twitter (and the prism and tempora project of the GCHQ)
not sure what you mean Roman, but I don't know anything about "node", facebook and twitter.
i'm just trying to use live 10, and it's unusable for me because of this bug
Seems to be incorrect behavior, but are you totally sure it's new to Live 10?
1) Firstly, for the sake of making a more "fair" test patch: live.numbox/slider/dials that are automated as floats but display as 'Int' have a display number that is always rounded to nearest integer. So if the value in your live.dial is 25.7 the dial will display '26' and your max integer will display 25. In the original patch it would be better to include a max float box too, to keep things honest. I don't believe there's any change here from Live 9 to 10.
2) Just helping isolate this a little more.. if you record a clip with automation from the live.dial in Stephen's initial patch and you induce the bug while recording automation (e.g. live.dial shows 0 but the max integer box shows 3), when you play back the clip, you'll see that the 3 got recorded into the clip rather than the 0. During clip playback, the live.dial shows 3 (as the 3 is what got recorded into Live) too. The fact that the mouse movement to 0 never got recorded seemed interesting to me...
3) Turns out the problem is quite easy to reproduce with a buffer size of 2048, and quite difficult to reproduce (I only succeed once) with a buffer size of 32. It seems progressively easier to reproduce at higher buffer sizes.
3b) And after isolating the impact of buffer size on this issue... I can reproduce similar behavior in Live 9 at buffer size of 2048.
This doesn't technically mean that it didn't get worse in Live 10, but if it did it may be much harder to quantify how much worse. So, Stephen, do you see the same thing I do when changing buffer size?
hello Tyler,
thank you for your reply, this thing is driving me nuts.
1) the int vs float issue is not part of the problem, because i'm doing the test using the mouse on a live.slider that is set to int both on Type and Unit Style parameters.
2) it is interesting, might lead to a solution?
3) the audio buffer size seems to make the difference. I've not been able to reproduce with buffer size 64, but with 256 I can (in Live 10).
3b) I can confirm that the issue arises with buffer set to 2048 in Live 9
the Live 9 vs Live 10 issue is real, because the exact same patch in both versions behave differently. But that is with buffer length higher that 64. Unfortunately, I cannot keep the buffer length at 64 all the time, unless i'm doing fairly simple synthesis and compositions.
Stephen can you confirm the buffer length condition?
Tyler and Rui,
Yes I can confirm the buffer length condition! Sorry I've been away from my computer for a few days.
With Live 10 it doesn't happen until i get to 512 buffer size and above.
With live 9 it seems to only happen on 2048.
This all makes a lot of sense. I recently switched from mac to pc and downgraded my interface so I've been running Ableton and Max at higher buffer sizes than before.
I'm surprised no one else has reported this issue, certainly people just aren't noticing right?
Are you using PCs? I could've sworn I've run M4L (Live 9) on a mac at 2048 and have never had this problem. My Mac is toast or I would test it.
Hey guys, from another thread: "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."
https://cycling74.com/forums/live-numbox-bug-it-doesn't-send-the-value-it-displays/replies/1#reply-5aede0ee0cac2704f3405db0
this issue is bringing back the Mac / PC polarization, because it seems to be something that affect only PC's. I need to get my hands on a Mac again to test it, unfortunately my current Mac is 10 years old and I suspect it won't run well TouchDesigner and Ableton Live with Max at the same time.
Rui, I'm running on a Mac and still encounter the issue.
not saying it's pretty, but this could be a workaround if you're desperate.
It uses an invisible 'vanilla' number on top of a live.number
The same occurs with live.dial for the Pitch used in OscA an OscB of Oscillot by Ableton. Meaning: if used with Live 9/M4L 7 everything is working fine. If used with Live 10/M4L 8 the knobs are displaying wrong values when changed from Semi to Free. The knob seems to be frozen. I might has to do something with integer an float and the parameter shows up different in the inspector window. Reported this to Ableton support.
Any news on this? I'm using Live 10 and can't run lower than a 1024 buffer size and this is getting pretty annoying.
The problem really lies in the interaction with Live, because I'm not encountering that problem when creating a new live.dial or live.slider. Only when the file has been saved and therefore the new objects integrated with Live will they start outputting wrong values.
Tried to deferlow the automation output ?
@TYLER MAZAIKA wrote:
live.numbox/slider/dials that are automated as floats but display as 'Int' have a display number that is always rounded to nearest integer. So if the value in your live.dial is 25.7 the dial will display '26' and your max integer will display 25.
Do you happen to know if that is documented anywhere? Or is that just what people have observed?
For peace of mind, I would like to get some precise information on this, as my patch depends on how this works.
In my observations, it does, indeed, seem to be the case, although even when display is set as "float" it still displays a rounded float number, when the actual number is an unrounded float.
--------------------------
Thank you for the reply. That is a nice demonstration of how floats are dealt with, but what I am still missing is whether live.numbox/slider/dials that are automated as floats output with consistency.
See this patch. To reproduce the issue, add the device to an audio effect rack, and map the dial to the audio effect rack's first macro.
On my machine at a buffer size of 2048 and a sample rate of 48000, when I set the audio effect rack's dial to 2047, the number displayed in the Max patch's number box is 2046.999878.
What I want to find out is whether the numbers Max gets in these cases always round to the value shown in the mapped macro. From what I can tell, that seems to be the case, but some more clarity and certainty would be nice. If that is the case, then I can simply round the value in Max, and I will know that the rounded value will match the value shown in the mapped macro.
seems its only a problem is when the macro is set by mouse.
but its perfect when you set the Steps to the Steps of the Dial
but its perfect when you set the Steps to the Steps of the Dial