Zachary Seldess

Below is a subpatch taken from a larger patch that I am building to intuitively move around openGL space in Jitter using a mouse and keyboard. I'm running into one annoying problem.

I'm calculating the speeds of movement along the x and y axes and scaling those values to change the time settings on some speedlims. As the angle of rotation reaches one axis the speed values (speedlim thresh) get drastically slower for the other axis. This is expected, of course, but what I can't figure out is why the speedlims temporarily "space-out" when these rotational extremes are reached/passed.

Try slowly moving the top number box from 195 to 205 and watch the bangs beneath the speedlims. This doesn't seem to be an event queue problem, does it? Maybe the numbers at the extremes are too large and are wrapping around on themselves? I'm sure someone here will quickly see what has been eluding me. Thanks in advance!

Below is a subpatch taken from a larger patch that I am building to intuitively move around openGL space in Jitter using a mouse and keyboard. I'm running into one annoying problem. 

I'm calculating the speeds of movement along the x and y axes and scaling those values to change the time settings on some speedlims. As the angle of rotation reaches one axis the speed values (speedlim thresh) get drastically slower for the other axis. This is expected, of course, but what I can't figure out is why the speedlims temporarily "space-out" when these rotational extremes are reached/passed. 

speedlim-temporarily-ignores-threshold-setting

The speedlim does slow down, but it seems to me that's normal behaviour. When i see the 'x speed' and 'y speed' number boxes near the bottom, they get very high values when you're close to 0 or PI on your circle (normal when using sin & cos).

Those values (12732 for input 199, 6366 for input 198) are then put into the speedlim's right inlet, which specifies the delay it uses in ms. 12.7 seconds and 6.4 seconds seems to work correctly. When you go over 200 input, the delays go down relatively fast again.

I think you've made a mistake in your thinking. Please note that speedlim will only take a new delay time into account when the previous one that was started has completely finished . This means your bang will not arrive for those 12 seconds, after which it will start a new delay which is as long as your latest input. Good luck!

Thanks for the input. This makes sense, it had occured to me but for some reason I thought the solution on the right would fix it.

Here's a solution. Thanks for knocking my brain into action.

Thanks for the input. This makes sense, it had occured to me but for some reason I thought the solution on the right would fix it. 

Your new patch seems to do nearly the same as your old patch to me. The output is still slow when you move near 200. Right now, I don't really understand what you are trying to achieve using the speedlims.

From your explanation, it seems like you just want to move an object at a certain angle (and speed). In that case, I wouldn't use speedlim, but I'd do it like in the patch below. I hope it is of any use, otherwise please clarify what you're trying to do...

From your explanation, it seems like you just want to move an object at a certain angle (and speed). In that case, I wouldn't use speedlim, but I'd do it like in the patch below. I hope it is of any use, otherwise please clarify what you're trying to do...
Good luck!

As I stated in my last post, I found a solution. And as my new patch shows, I'm NOT using speedlim.

This is one very small aspect of a much larger project - there's no need to go into the details here. As I said in my first post, I needed to calculate the speed of movement along the x and y axes based on rotation. In this situation, the speed of movement equates to the speed of a repeated bang. I was just going about this the wrong way with speedlim. Thanks for the input.

Here it is again, slightly modified. Again, changing the speed of bangs for each axes (== speed of movement in this scenario) based on the rotation on the x and y axes:

As I stated in my last post, I found a solution. And as my new patch shows, I'm NOT using speedlim. 

speedlim temporarily ignores threshold setting