goingdeaf

If I were to create a number box and attach it to the [print] object, open the Max window, lock the patch, click on it, and drag upwards very quickly (ending up on 400 for example), why is it that there is not a constant, smooth stream of numbers. Looking at the list in my Max window, it seems as though certain numbers weren't printed/we skipped.

Is this just an issue with the speed at which I'm scrolling upwards/downwards?

Is there a way to fix this without holding down the shift key?

In an ideal situation, I'd like to be able to scroll in a similar manner, with all of the numbers being printed, regardless of how quickly I scroll.

I'm using this method to generate new objects via [script] and [thispatcher] dynamically and any inconsistencies create a mess on my patch!

I've looked into the [js] approach (from the js tutorials) and it seems as though the problem does not exist there. Maybe I'm wrong though.

angry-with-numbers

The problem stems from the fact that the fastest rate at which max objects report data is 1 millisecond, so essentially if you are scrolling faster than 1 ms per number, it will skip quite a few intermediate numbers. The reason why the js method apparently doesn't skip any numbers is because for every number it receives, it deletes all previous objects, and makes the specified number of new objects very quickly. There isn't a way to get max to report values faster than 1 ms, but there are ways to work around this. Does this patch do what you're looking for?

This patch takes advantage of the fact that uzi sends out seperate messages faster than the standard max rate.

my limited understanding of how Max executes leads me to think that this is something to with the rate at which Max buffers control-rate data.....is it 20ms? (for example, the default rate for [snapshot~]). There was a recent thread about [select] not 'catching' arguments values, and although I didn't comment/reply, I guessed this was a similar issue? No? MSP has a different limitation dictated by IO buffer size, control data (CPU cycles maybe) is slower?

Hi goingdeaf
my limited understanding of how Max executes leads me to think that this is something to with the rate at which Max buffers control-rate data.....is it 20ms? (for example, the default rate for [snapshot~]). There was a recent thread about [select] not 'catching' arguments values, and although I didn't comment/reply, I guessed this was a similar issue? No? MSP has a different limitation dictated by IO buffer size, control data (CPU cycles maybe) is slower?

@ John Cassidy: Thank you so much! It would have taken me a lot longer to figure this one out by myself. It's a great workaround. I appreciate it!

@ n00b_meister: I hope you're all well in Co. Down. About the recent thread, I don't recall it. Was it one I commented on, or started?

"The problem stems from the fact that the fastest rate at which max objects report data is 1 millisecond"

"my limited understanding of how Max executes leads me to think that this is something to with the rate at which Max buffers control-rate data"

hey guys, have you thought about the fact that the mouse only reports its current position every 50 ms? ;)

John Cassidy wrote:
"The problem stems from the fact that the fastest rate at which max objects report data is 1 millisecond"

n00b_meister wrote:
"my limited understanding of how Max executes leads me to think that this is something to with the rate at which Max buffers control-rate data"

110 writes:
hey guys, have you thought about the fact that the mouse only reports its current position every 50 ms? ;)

I have an abstraction, which I call EveryNumber, which will not leave gaps:

Along these lines, I've always wondered if C74 has discussed (internally) raising the control-rate. I'd love having control rate stuff work at audio rate, as an option. I'm relatively sure it's impossible to do that and keep the same work flow, but come on, 1000 times per second vs 48000 times per second is only a speed increase of 48 times! That's not THAT much. :P

Along these lines, I've always wondered if C74 has discussed (internally) raising the control-rate.  I'd love having control rate stuff work at audio rate, as an option. I'm relatively sure it's impossible to do that and keep the same work flow, but come on, 1000 times per second vs 48000 times per second is only a speed increase of 48 times!  That's not THAT much. :P


Angry with numbers.