Closed residuum closed 7 years ago
In Pd the proposal would lead to:
[oscparse]
|
[list trim]
|
[route accelerometer]
|
[unpack f f f]
| | |
[9,4\ [-0.1\ [0.3\
adding a button [ALL] for every sensor should be easier. it will be back compatible as well:
/accelerometer/X ,f 9.40 /accelerometer/Y ,f -0.1 /accelerometer/ALL ,fff 9.40 -0.1 0.3
I am thinking about a user that needs only the X from accelerometer and orientation, but will receive 6 values instead of two. however, in both situations the user would receive two small packages. what seems to be OK either way.
Keeping the current format in place in addition to the proposed will add data to multitouch usage. As long as the installation base is as small as it is now, and we have not released 1.0.0, a change in format should be OK.
Furthermore, having only one button per sensor instead of dynamically creating the list of buttons actually simplifies the code.
Please review https://github.com/SensorApps/Sensors2OSC/compare/master...c08d0ab136d7e2a4527c142daabc671ee2fe43b0 for only one button per sensor
I tested and it looks fine. I noticed a transparency on buttons background. is it ok?! I think it should be better to see the button text over everything.
Current situation
A user can select the dimensions for each sensor to be sent via OSC. Measurements are sent as float messages with an own address.
Example
User select X and Y for accelerometer. The app sends
Proposal
A user can only select a sensor for sending data via OSC. Measurements are sent as a list of floats.
Example
User can select accelerometer. The app sends
This means that fewer messages are sent, even when a user selects not all dimensions for a sensor and bandwidth is saved especially for large numbers of clients with large number of sensors.
The drawback is, that anyone using the app for a performances et al. must update the receiver as well.
Please discuss, if this change would be OK.