If a cursor’s message has at least one of the collision_* variables, then the parameter’s value is sent as part of the message, but only while the cursor is actually colliding with a curve. While no collision is occurring, that variable’s value is omitted from the message.

This means that the collision_* variable(s) would preferably be at the end of the list of variables in the message. Otherwise the position of the non-collision variables will shift depending on whether a collision is occurring, causing, for example the variable in position #5 to be in position #4 when a collision is not occurring, causing miss-assignment in the receiving application.

– Chris

Have a look at the documentation Reference sections on Cursors, under the Mapping heading.

You can set the target range to the desired MIDI range, say 0 to 127. Then the message variables cursor_value_x, etc go over this range rather than 0 to 1.

You can set up the remapping of cursor x and y target ranges in the user interface with the Inspector. Select the desired cursor in the workspace, and in the Inspector change the « Value Mapping » « To » values from their default of 0 1 1 0 to the desired midi ranges for the x axis and the y axis. e.g. For cursor_value_x to run from 40 to 120 and cursor_value_z to run from 0 to 127 set the « to » value to 40 120 127 0.

I hope this explanation is clear enough. Let me know if you need more help.

The upcoming 0.8.22 IanniX release will have a much more powerful means of remapping variables in messages using embedded Javascript expressions in the message. Among other things this will allow using data rescaling functions like are available for example in Processing or MaxMSP. You can also write your own JS expressions to combine variable and remap them in any way you can imagine.

– Chris

@heuermh wrote:

I had thought collision messages were sent out on their own, not as parameters on a cursor message.

Have you been discussing the branch by Chris or the main 0.8.21 version?

There is a collision message sent out on its own, and that is when a cursor has a collision with a trigger object. This is not a cursor OSC message, rather, it is a trigger OSC message. I don’t know about any other « collisions » in 0.8.21.

Cheers,
–Bob

I thought the question was about the collision_* family of cursor messages (see below).

Bob is right, that triggers send messages when collided with by cursors.

In 0.8.21 there are also these variables that can be used in cursor messages:
– collision_curve_id
– collision_xPos
– collision_yPos
– collision_value_x
– collision_value_y

When included in a cursor message, these are sent, when the cursor is colliding with a curve, and suppressed otherwise. (However note that there is a bug that prevents collisions with single-line curves from being detected.)

– Chris