Forum wide moderators
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.
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.
You might want to try the following beta version:
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.
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?
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?
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.
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.
Great work!
You're both right, in that generally the Sylphyo fingerings are described by a set of fingering-to-note mappings (fingerings being encoded as a series of closed/open/don't-care choices for each key), but in the case of the EVI and EWI fingerings they're actually generated based on the rules described in the manual, so there's no "unassigned" position (that would have resulted in continuing with the most recent pitch, as Clint correctly guessed).
A few technical details might be useful here. The Sylphyo firmware represents a fingering as a table of 512 entries containing relative pitch values. Each of the 512 entries corresponds to a finger position, with 512 = 2^9, as there are 8 keys plus whether an octave key is pressed or not. The tables are generated from YAML files, such as the ones Clint is working on (huge thanks!) for upcoming fingerings, that list finger positions (and includes a "don't care" state in addition to open and closed for each key) and their corresponding pitch. These files are later processed with a set of Python scripts that allow me to generate the data for the Sylphyo firmware, as well as check whether there's any error, missing position, or double assignment if needed.
Some years ago I've had a brief stint during which I tried making transpositionally-invariant fingerings based on intervals like major and minor thirds, and on this occasion I've enhanced the scripts with tools such as Hamming distance computation in order to be able to suggest optimal finger positions for a given melody, or to find what would be the best "standard" finger positions for these new fingerings. As I was soon hit with more urgent things to do I haven't gone further on this, but maybe I can share a few insights (or maybe small pieces of code?) with you guys if it can help.
This kind of work is obviously very interesting too for people with disabilities, maybe as a starting point. In the past two years we've been working with a former trumpet teacher on a one-handed adaptation of the EVI fingering (currently not available to the general public), and one of the lessons was that generic solutions only go so far.
only limitation to this feature is that the Sylphyo display won't reflect patch changes done from the Link as there is currently not status feedback through the wireless transmission.
You are not doing anything wrong.
The up/down buttons are only providing this next/previous feature when NOT paired with the Sylphyo. When you are using the Sylphyo this is achieved by the Sylphyo keys instead.