Old 07-11-2014, 08:22 AM   #1
gt3k
Human being with feelings
 
Join Date: Jul 2014
Posts: 5
Default TouchOSC accelerometer control

Can anyone help me get the accelerometer data sent by TouchOSC (on Android if that matters) to control parameters in Reaper? I have already followed the basic setup guides and I have the layouts that came with TouchOSC working with Reaper, but I haven't found any information about how to use the accelerometer control.

I have activated the accelerometer option in the TouchOSC settings. I tried using the learn function in Reaper, and it connected to "accxyz", but it seems like that is sending all three axes at once, because the control I connected it to just jumped around wildly. I'm assuming that I need to create a modified Reaper osc file, but that's where I'm stuck. If anyone has managed to get this working I would really appreciate your help!
gt3k is offline   Reply With Quote
Old 08-13-2014, 07:07 PM   #2
Ceremona
Human being with feelings
 
Join Date: Oct 2013
Posts: 3
Default Feature Request: Accelerometer OSC control

I really want this functionality to work in reaper via the OSC control of an android app. I really can't see how I would get it to work to affect automation or VST affects. I see there is some manual tweaking I could do via a .reaperosc file, but I don't want to spend enough time to warrant a PhD trying to figure it out. From reading the forums it sounds fairly buggy anyhow. I would expect this kind of function mapping would be in HUGE demand as it opens the door to so many different motion-based applications.

Gt3k. I don't even know how you got the FX control to trigger at all. You're a step ahead of me

How are you getting the learn function to trigger on an OSC event? Are you mapping it to a midi event? This is what I want to NOT do. Tired of having parameter values being shackled in 127 bit land.
Ceremona is offline   Reply With Quote
Old 08-15-2014, 12:07 PM   #3
gt3k
Human being with feelings
 
Join Date: Jul 2014
Posts: 5
Default

When I used the Learn function in Reaper it connected to "accxyz' (sent from TouchOSC), but this really doesn't work because it's receiving all 3 xyz dimensions in that same parameter, and they're also not in the right range of numbers (-10 to +10 instead of 0 to 1). So, don't even bother with this method.

I ended up creating a PureData program to receive the signal from TouchOSC and split it up into individual parameters for X, Y, and Z. I then ran each signal through some simple adjustments to change the values into the appropriate range. PureData then sends the adjusted accelerometer values back out in a form that Reaper can actually use (no editing of the .reaperosc files or midi mapping necessary). This is working pretty well, but my PureData program still needs a little work.

Hopefully TouchOSC (or some other app) will eventually support this kind of signal flow natively, but until then using PureData as an intermediary seems like the only option. Once I get my PureData program running a little better I'll post it here for others to use. Until then, I suggest that you start getting familiar with PureData yourself so that you can adjust the program that I'll upload or maybe even create your own. It's actually pretty simple, the only reason it's taken me a while is because I don't have much time to commit to it.

http://puredata.info/
gt3k is offline   Reply With Quote
Old 08-30-2014, 10:55 PM   #4
gt3k
Human being with feelings
 
Join Date: Jul 2014
Posts: 5
Default

I've managed to get accelerometer data from my phone working pretty well to control parameters within Reaper. I've done this by running the TouchOSC application on my (Android) phone, and using a custom PureData program to receive the accelerometer data via OSC and manipulate it into a format that works with Reaper.

I've uploaded the PureData program I created so that anyone else who wants to can use it. This is my first time using PureData, so the code is likely to have some problems, but it's working great for me. I've also created a custom TouchOSC layout that works with the PureData program. As it is you have to use this layout in order to make the PureData program work, but it would only take minor modifications to the PureData program to allow for the use of different layouts.

I documented all of the setup and features in a Read Me file, so make sure you read that in order to understand what's going on. If you have any problems post here and I'll do my best to help you through it.

Download the PureData program, the TouchOSC layout, and the documentation here:
https://drive.google.com/folderview?...Wc&usp=sharing

Enjoy!
gt3k is offline   Reply With Quote
Old 09-14-2014, 05:57 AM   #5
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Hey gt3k,

It seems like you already figured out the main gotcha's already for this use case.

Indeed, the problem with 'learning' bindings to messages sending *multiple* values is best handled by first splitting them up into separate messages.

I very quickly peeked at your Pd patch (in a text editor... so I didn't *really* look at it :P), and have some suggestions for improvement. First off, you may want to [scale] the values rather than simply [limit] them. For one thing, simply limiting the range would make you miss all the negative values (but this may also be exactly what you want... it all depends).

Another thing you may want to look into for improving your patch, is using [sendtyped] instead of [send] with [udpsend], in order to prevent issues with floating point vs. integer numbers (i.e. missing values of e.g. exactly 0 or 1, since those will be sent as integer numbers if you don't specify their type). Fwiw: I made this mistake myself when first playing with Pd and REAPER using OSC, and fort a while it had me stumbled why I wasn't able to reach these exact values.

A standard trick to enhance the usefulness of accelerometer data is to apply a (very!) simple pair of low/high-pass filters, in order to separate the raw data into orientation (x,y,z) and movement (x,y,z). I didn't see how you have used the [mavg] objects, but I figure it works as a simple LPF, so you could use simple subtraction to generate HPF'ed values: the original values minus the averaged values (= device orientation) equals the device's movement values.

Oh, and I think people will need to install Pd-extended rather than vanilla Pd, since you're using the mrpeach externals? That would be useful to mention in the instructions.
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 09-14-2014, 11:21 AM   #6
gt3k
Human being with feelings
 
Join Date: Jul 2014
Posts: 5
Default

Thanks so much for your thorough feedback. I'll address each of your comments separately:

scaling: you are correct and this is the method I'm already using. The accelerometer values originally range from -10 to +10, and the patch scales these into a range of 0 to 1. This is covered in more detail in the "Read Me" document that is available at the google drive link below. I am also using a limit function after this scaling just to make sure nothing smaller than 0 or greater than 1 ever gets sent out.

sendtype: Thanks! I didn't even realize I wasn't actually receiving values of 0 and 1 in Reaper. I changed all of the [send] objects to [sendtype f] objects and that fixed it. I uploaded this corrected version of the patch to the same google drive link below.

low/high pass filters: I'm not sure I'm following what you're describing here. What I think you're saying is to use filters to convert the raw values into change values. So, if the raw values increase from 0.5 to 0.6, the filtered values would be 0.1. Is that right? If so, I'm not seeing what the benefit of this would be. Could you describe an example where it would be preferable to use these filtered movement values rather than the original raw orientation values?

Pd-extended: You're right, and that is something I failed to mention in this thread as well as the Read Me document. I updated the Read Me document to include this.

The PureData patch, TouchOSC layout, and associated documentation can all be found here:

https://drive.google.com/folderview?...Wc&usp=sharing
gt3k is offline   Reply With Quote
Old 09-15-2014, 05:11 AM   #7
Banned
Human being with feelings
 
Banned's Avatar
 
Join Date: Mar 2008
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Default

Quote:
Originally Posted by gt3k View Post
scaling: you are correct and this is the method I'm already using. [...]
Ah, gotcha. (There's only so much one can see in a text editor... )
Quote:
Originally Posted by gt3k View Post
low/high pass filters: I'm not sure I'm following what you're describing here. What I think you're saying is to use filters to convert the raw values into change values. So, if the raw values increase from 0.5 to 0.6, the filtered values would be 0.1. Is that right? If so, I'm not seeing what the benefit of this would be. Could you describe an example where it would be preferable to use these filtered movement values rather than the original raw orientation values?
Well, I guess you are already applying some averaging, right? That is basically applying a low pass filter, which converts acceleration data into orientation data. What I'm suggesting is that the 'remainder' of the signal is also useful in its own right: the sudden changes (= high frequency) that have thus been filtered out represent the device movement rather than its orientation. So the point of doing this is simply getting more data: instead of having only the raw acceleration values, you may want to get data for both (1) orientation and (2) movement.

I find numeric examples to be quite confusing in this context, when - after rescaling as described - the center value of 0.5 represents zero G. But for a conceptual example, you could be shaking the device left to right without changing its orientation. Does that make sense?

When I'm back in the studio, I'll grab some Pd patch to illustrate more clearly; there's also some maths involved (iirc, using [tanh] or something similar) to convert the separate x, y, z values into pitch, roll, and yaw, which is often much more intuitive to use (and can also be converted into degrees or radians, which may be useful as well).
__________________
˙lɐd 'ʎɐʍ ƃuoɹʍ ǝɥʇ ǝɔıʌǝp ʇɐɥʇ ƃuıploɥ ǝɹ,noʎ
Banned is offline   Reply With Quote
Old 09-15-2014, 08:30 AM   #8
gt3k
Human being with feelings
 
Join Date: Jul 2014
Posts: 5
Default

Quote:
Originally Posted by Banned View Post
I guess you are already applying some averaging, right?
Other than the scaling, the only filtering I'm doing is a [mavg] object that computes a running average of the previous 10 samples, just to smooth the signal a little.

Quote:
Originally Posted by Banned View Post
for a conceptual example, you could be shaking the device left to right without changing its orientation. Does that make sense?
Ok I follow you. Basically you're computing translational movement values from the original orientation values. That would be great to have as it would allow for three additional axes of control.

Quote:
Originally Posted by Banned View Post
When I'm back in the studio, I'll grab some Pd patch to illustrate more clearly; there's also some maths involved (iirc, using [tanh] or something similar) to convert the separate x, y, z values into pitch, roll, and yaw, which is often much more intuitive to use (and can also be converted into degrees or radians, which may be useful as well).
That would be great! This level of signal processing is new to me, so any guidance you could provide would be greatly appreciated. Also, just to be clear, the orientation data that I'm already using includes pitch and roll values, but what I would consider to be yaw on a phone (laying it down face up and rotating it around) isn't reported (I'm guessing this would have to come from the compass?). The third orientation value just reports whether the screen is face up or face down.
gt3k is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:25 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.