rock plus roll on CC76?
-
Hello --
I am new at using Sylphyo, and am having difficulty understanding part of its behavior. I have not come across any discussion or demos of this behavior, and would be most appreciative if some kind soul would give me a pointer to where I should look.
It's somewhat difficult to describe what gesture I am using, so I made a crude but short video of the gesture and a MIDI monitor display of the signal. It is here on dropbox:
https://www.dropbox.com/s/e7j7u6k7mjzic31/CC76.mp4?dl=0
Many thanks to anyone who would take the trouble to look at this.
Ian
-
@ijfritz I think what you are doing is the "roll" motion.
-
Thank you for the reply.
The usual designation for "roll" is rotation around the long axis of the instrument. If you hold the instrument vertically and apply that same rotation along the long axis of the instrument you get no output signal from the accelerometer. That's how they work. The manual even points out that you have to have some elevation to use "roll".
This "new" gesture is different. It is a rotation around a different axis, namely the radial axis pointing outward from the body of the instrument. You can call it a roll motion if you like but it is not the same gesture as what is usually denoted as "roll". I might suggest something like "twist" for this motion. It produces the strongest output at zero "elevation" and zero output at horizontal orientation, the opposite of "roll".
Pedro has pointed out that this "new" motion is a complementary motion to "roll" and he believes it should be output as a separate MIDI signal, rather than being combined with "roll" in CC76. We have both written to Aodyo; so far they have just asked to see a video, which is what this post links to.
There are many explanations of how accelerometers work online. If you are so inclined you might look one up. My favorite is the Texas Instrument Application Note on the subject.
Ian
-
@ijfritz OK, I see now ... I was not looking at the second half of your video ...
So - maybe you are you actuating the "Compass" accelerometer? You are changing the lateral orientation of the Sylphyo ...
-
I think what you mean is called "yaw" in aviation ("gieren" in German). A rotation around the vertical airplane axis from the view of the pilot.
I like this behavior of the Sylphyo and I believe that it was implemented on purpose as it is.
Due to the magnetic field sensor, a "roll" gesture started in a horizontal Sylphyo position gets less effective, the more you angle the instrument downwards. Near the final vertical position no more rolling is measurable. This can be musically useful, but it also means, that starting in a steep downwards position, which can make sense in a visual performance, would not have any roll possibility unless you move the Sylphyo up. I assume that Aodyo implemented the "yaw" movement as a "second roll". While the Sylphyo is held steeply downwards, you can yaw/(roll) it with a pendulum motion. Futher up you can move on to the normal roll gesture.
I see this implementation as simplification for new users and for players who prefer just a few technical possibilities over loads of features.
But personally I think that yaw should be an independent parameter. We can always set yaw and roll to the same controller number and this could even be the default setting (like it is now). It is a good idea to set defaults for easiest playing, but when we start to tweak, all motions should be usable in any way we want.
Delicate: In a more horizontal position, "yaw" collides with the "compass" parameter. Tricky stuff ...
I think that the movement of the Sylphyo is not perfectly worked out yet, but since it also depends on features still in beta state, I would prefer to discuss this in a separate thread.
-
@peter-ostry
Many thanks for your reply. Yes, it is “yaw”. I don’t know any German, so I cannot comment on that particular linguistic appellation.I appreciate your insight as to Aodyo’s intentions. But my original question remains: where exactly do they explain the yaw feature? Since this motion greatly increases the expressiveness of the instrument, why would they deliberately fail to mention it? Or have I just not looked in the right place? That is my question.
Pedro says that when he pointed out the yaw question to Aodyo (Jonathan, specifically) they had no response except to ask to see a video. He may make a demonstration in addition to mine when he has more time. Pedro was totally surprised when I explained the yaw feature to him. Why would a person who helped in the instrument’s design be unaware of this quite important and useful response?
My own direct inquiry to Aodyo has not received a reply yet.
I have no opinion as to whether the two responses should be combined or not. In my Reaktor program I have followed Pedro’s suggestion to process the R and L “roll” variables separately, as you can see in the two clips. I have been enjoying being able to control various synth parameters this way. But it would be quite an effort to set up and program another pair of these.
One final point: I also have a TEController MIDI device which I use as an accelerometer on my personal, custom wind controller. I was very surprised to see that its outputs seem to be exactly the same as Sylphyo’s! I can switch controllers and see no difference. And this includes the “roll/yaw” combination on a single MIDI CC.
Thanks for the discussion.
Ian
-
Regarding your question: As far as I know, the "yaw" parameter is not described in the manual, nor in a tutorial.
—
I am also rather new to the Sylphyo and just learned from you about this additional parameter which is not available (yet?) as separate data. If someone else programmed the sensor part of the Sylphyo system, Aodyo support may also not know about "yaw", that only works around the vertical position and seems to be masked as "roll".
I am pretty sure that we could get "yaw" as a separate parameter, similar to "roll". And if we set yaw and roll to the same CC, the additional data would not bother anyone who does not want to use them separately.
But as I mentioned, yaw collides with the beta compass mode. This "compass" is problematic at the moment. It works well in the usual playing position, but when you tilt the Sylphyo down, "roll" gets reduced as expected and "compass" goes haywire. It jumps erratically. If you start blowing in the vertically down position, the "roll" gesture works as "compass", which seems logical. But when you tilt the Sylphyo upwards, "compass" goes haywire again. There should be a smooth transition and hopefully Aodyo is working on it.
It could also be, that the programmers are well aware about the compass problem and want to solve this first, before they think about a separate yaw paramter, which introduces a very similar problem. Wouldn't a horizontal yaw be, what they call compass? They could replace "compass" by the universal "yaw". But then, what about rolling in the vertical position? We would need compass again. Or smooth transitions from one parameter to the other. Well, that is Aodyo's business and as long as they don't ask us we just discuss for personal amusement :-)
However, I am happy with the Sylphyo as it is and appreciate when the Aodyo people take their time to improve the system in a reliable way.
-
Apologies in advance if I've misunderstood something or say something inaccurate, this is straight off the top of my head.
The angles the Sylphyo outputs come almost straight from its inertial measurement unit (IMU), with some postprocessing related to smoothing the response and correcting discontinuities where possible. That's probably why Ian gets the same kind of outputs with his own accelerometer.
Now, I guess the crux of the matter is the way we usually describe the orientation of the IMU, which is by giving three angles, one for each of the three axes (Euler angles), as if we applied successively a rotation around each axis from a given starting position.
It's a very useful way of describing a rotation, because it's very easy to map an angle to a particular physical movement, but it's unable to guarantee that the three angles stay independent at all times due to a problem called gimbal lock, which leads to some angles evolving in the same way despite applying a rotation to a single axis in particular situations, and other interdependencies like the one you've labelled "yaw" (which, by the way, would be really nice to exploit, even if it's really more of a side effect than an intentional feature!).
Depending on the order of the axes you choose, the lock happens in different conditions, and it's been a long time since we've done the movement system of the Sylphyo, but I think at the time I tried all the possible orders and went with the one that was the most conducive to being easily used in a Sylphyo performance.By the way, due to this problem, the Sylphyo first offered only two angles (elevation and roll), and we later added the third (compass) due to popular demand, but as a "beta" feature, because the gimbal lock becomes really obvious when manipulating all three angles. Another reason for the "beta" status of the compass angle is that it's tied to our IMU's magnetometer, which has the bad habit of taking a long time to calibrate, and once done the compass angle might seem to "jump" in place. It's a common problem with IMU's, and it's also why your phone sometimes has trouble reporting your orientation correctly when you're using a GPS app.
Now, there's a way to escape the gimbal lock, which is representing rotations with quaternions, and fortunately our IMU is able to output quaternions. With this and a handful of formulas, it's possible to reconstruct a correct set of rotation angles, and it's clearly one of the next big things we would like to do in the movement area.
I tried doing so before we released Syphyo firmware version 1, but I was unsuccessful and we didn't have time for another try.
I will, at some point, but as people did get used to the angles as we have them, maybe we'll have to support both ways of representing things and let the users choose.
As for separating yaw and roll altogether, well that might need even more work :), but maybe switching to a quaternion representation first will help. Anyway, we'll see when we're at that point.There's also a ton of other things we could derive from the IMU data, but this requires a good amount of research and development to get done right. In the past I've experimented with some movements like "elbow shakes" (using either hand to swing the bell to the left or to the right), but it didn't really prove very easy to perform :). Any good idea is up for discussion :).
@ijfritz, if you have any technical question you'd like answered, please contact me directly next time. Pedro did speak to me about this, but didn't really give any detail. As we're still deep into the Anyma Phi release, I don't often sweep through the customer support mail myself, and I don't visit the forum very often either, so I just saw your link to the video here. Pedro will call me at the end of the week to talk about your discovery.
R&D Engineer at Aodyo / Ingénieur R&D chez Aodyo
-
Thank you for your response.
My question was not a technical one at all. It was simply a question to other users as to whether anyone was employing this gestural response I stumbled upon, and if there was any documentation for it.
Knowing very little about IMU operation, I was careful to state that I have no opinion as to separating responses, etc. I do enjoy having CW and CCW rotations split, but that was simple to do in my Reaktor ensemble, and certainly nothing to make a special request about.
Ian
-
I knew that there are some difficulties with measuring angles in space but I did not know the details. Thank you very much for the explanation and the link to Gimbalpedia. Hopefully you get the quaternion method working, I read the description three times and still don't understand this Pi trick ;-)
Regarding the current version:
Like you, I think the compass behavior at steeper elevation angles cannot easily get re-calculated to a smooth transition between roll and compass. It depends where you start to blow. And this is different from aircrafts and space ships, which need absolute information about their position while the Sylphyo is most times played in a relative mode. Maybe this will change with quaternions, but that is another story.
I observed all MIDI data from the Sylphyo in Max, tried many settings and decided to block compass data if the elevation parameter is at zero. This does not save every situation, but most. I am comfortable with this restriction. Of course I lose the roll=compass gesture with the vertical Sylphyo but well, not everything must get translated to sound. If I play without a computer, I either avoid steep angles or don't use compass.
Regarding this "vertical yaw" with a steeply held Sylphyo that ijfritz found and that you see as a side effect: I like that. And now I understand that is not an additional parameter. It just comes as roll and actually this is good. I missed roll in steep positions, don't know why I never tried to swing the instrument left/right. Nice bug, please don't fix it, rather call it a feature.
-
Hello --
I believe I have resolved my question about the "roll" vs "pendulum swing" responses. Actually they are the same thing, namely a rotation about a fixed (earth-frame) axis. Makes sense once you get it.
Thanks for the great discussion!
Ian
-
It turned out to be not too difficult to find the mathematical explanation of the "vertical yaw" response. In fact it is sitting in plain sight in the standard expressions describing 3-dimensional spatial rotations. Indeed, the response is the sum of two terms, which could be send over separate MIDI channels.
Ian
