Thanks for your feedback! On the MIDI front, what kind of info do you think is missing? We might add some additional (fixed) ways to edit the patch using NRPNs and other CCs (esp. for controlling the matrix) on a specific channel, so any clarification on how you'd use that is welcome.
Group Details Private
Moderators for the community
RE: Discovering Anyma... 1st impressions
RE: Feature Request: Turning PC out off.
@peter-ostry Yes, we will add the option to block the Sylphyo/Link from sending Program Change messages in a future update. We cannot commit on a time frame for this feature, but we'll get in touch as soon as a beta version with your feature is available.
RE: rock plus roll on CC76?
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.
RE: Bug depuis dernière mise à jour
Pouvez-vous nous en dire plus sur le comportement erratique de votre Sylphyo ? Notamment, quels sont les réglages de réactivité des touches avec lesquels le comportement est erratique, et est-ce qu'un changement de ces réglages résout le problème ? Merci.
RE: Link jitter/latency
The Link uses the same frequency band as WiFi, Bluetooth, and other consumer electronics devices. It might be that your WiFi router and your Sylphyo/Link are trying to compete for the same channel, in which case the loudest wins (certainly your router). To improve things, you might want to try to pair your Sylphyo and Link again, so that they will settle on another channel. Unfortunately, the Sylphyo and Link cannot "see" the busy channels in the frequency band, so they settle on a channel if they manage to communicate successfully during the pairing process. You might need to try a few times before finding a channel far enough from your WiFi router.
RE: Octave issues
You might want to try the following beta version:
- for Windows: https://downloads.aodyo.com/sylphyo/beta/sylphyo-windows-1.4.8b10.exe
- for Mac: https://downloads.aodyo.com/sylphyo/beta/sylphyo-osx-1.4.8b10.zip
I added a "More sensitive" option in the Keys section of the settings menu. Once enabled, the octave keys should respond a bit differently, in such a way that it's pretty impossible to reproduce the issue observed in this thread with my Sylphyo.
You'll also find a parameter called "R.time octaves" that allows you to increase the reaction time when passing from an octave to another, which should help masking the undesired passing notes, for instance when switching from the high C to the low D of the next octave with the Sax fingering.
Let me know how it works for you.
RE: Octave issues
It could arise if you use a light touch and move slowly on the octave keys, but it depends on the player and some Sylphyo are more forgiving than others. Generally it's recommended to push your thumb a bit more and move a bit faster, which effectively could require a bit of training. With the Sylphyo I have on hand, the issue (spurious note stuck) is apparent with an exaggeratedly slow thumb movement when I set the 5+2 mode, or better, a fingering where the thumb can change the note, like Recorder. Maxence can't reproduce the issue on his Sylphyo. @ijfritz If you don't mind, may I send you an email to discuss your issues in more detail and figure out something to mitigate it?
RE: Sylphyo Font Folio
I LOVE this project, huge thanks to you Clint!
I like that the font could display "don't care", "half-hole" and "trill" alternatives. However, I share your concern about how easy it would be to sight-read the fingerings with the "don't care" symbols on it. Maybe something like a dot inside the circle would make it easier?
Also, I'm not an font expert, but I'm wondering whether it would be possible to offer any possible combination of fingerings, limited to open and closed states, which would amount to 512 different characters. This could help facilitate discussions over future fingerings and changes over existing ones by providing a way to quickly create fingering charts. This would also be beneficial for fingerings that offer many alternatives for a single note, such as the EWI.
In the same vein, would it be possible to compose a fingering using a succession of Unicode code points? I'm thinking about fonts like FF Chartwell that cleverly interpret characters so as to layout a drawing. Again, not a font expert, but I imagine it isn't that simple, and maybe limited to formats like OpenType?
RE: Support for high-resolution MIDI?
Chiming in a bit late…
Breath control resolution is somewhat of a tricky subject. It's very easy to assume that a 7-bit MIDI signal isn't enough, but often I've found the problem lies in the perceptual mismatch between the breath signal produced by the performer and the perceived sound intensity of a sound produced by a synth.
Because we're very sensitive to that "jitter" between "no sound" and "a very faint sound", the synth should ideally increase volume/intensity veeeery gradually in the very low range (when the CC is 0, 1, 2, etc.), even if the curve can be steeper after that.
Having more extreme curves on the Sylphyo side would be a good idea (even regardless of this particular issue), but I don't think it would really help mask the perceived discontinuity in the very low range in most cases: if the sound is too loud at CC value 1 compared to CC value 0 (silence), then it's not good.
A 14-bit signal would help a little in this case, but I'm not sure it would be practical anyway because you would need a tremendous amount of accuracy to produce a smooth signal using the breath. And it could also bring in the timing issues Laurent talked about.
The synth will be smoothing your breath signal regardless of its resolution, and it'll do it at least over 32 bits, so it'll create the intermediate values your 7-bit or 14-bit signal lacks. The real question is how the synth smooths the signal: is it a good tradeoff between no perceived discontinuities and reactivity?
To me, the solution indeed lies in the volume curve, as Clint proposed. We're very sensitive to the difference between CC values 0 and 1, but I've yet to come across people complaining that there isn't enough steps between CC values 80 and 81. Bending the synth's volume/brightness curves to our perceptual expectations is more likely to bring about the desired results, in my opinion.
Have you found a good solution for this?
If not, you could try using some kind of program (like Max from Cycling 74) to produce the MIDI data needed to play the synth at a desired breath CC level, and check whether you hear a large discontinuity between 0 and 1.
If you do, then there should be some curve bending work to do on the synth side. If not, then we could try adding some new, more extreme curves on the Sylphyo side and see if it solves the issue.
RE: Flying with Sylphyo
I've also had my share of "what's that thing" and improvised 30-second demos for airport security officers :), but I never had any issue, be it with our without a case. As it contains a battery, you need to take it in cabin.
I also fly with some of our weirdest electronics prototypes without their enclosure and with wires everywhere, but it hasn't raised any concern so far.