Global Moderators

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.

Ciao,

Grazie per il messaggio.

Si, e possibile suonare con il carica batteria collegato.

Saluti.

Hi there,

The main trouble about using high resolution MIDI is that it needs 2 MIDI messages to be transmitted thus requiring twice the bandwidth of a standard MIDI message. As there are many other MIDI messages to be transmitted (note on/note off, and all the various MIDI CC messages transmitted by the Sylphyo) using high resolution MIDI messages would double the resolution but would also lead to bigger time between MIDI breath messages and thus stepping effects would come back ...
Issue is there on the MIDI side but would also have similar impact on the wireless transmission which have to face similar bandwidth constraints.

C'est une idée intéressante et ça serait en effet bien pratique. En gros, il faudrait que si le pouce arrive sur une zone ignorée, on puisse contrôler le bord haut quand le pouce se déplace dessus, sans avoir à lever le pouce, c'est ça ?
En tous cas, c'est noté et ça pourrait faire l'objet d'une amélioration dans une de nos futures mises à jour.

En attendant, peut-être qu'une façon de contourner le problème pourrait être de mettre une "Taille du pouce" plus grande pour donner plus d'espace aux zones "haut" et "bas" du slider ?

First of all, thanks for your support.

External control of Sylphyo settings is a very nice idea, and there would be no hardware limitation preventing this, however we would have to take some time to develop this feature as it would rely on the Link sending back real-time information to the Sylphyo (to transmit the data from the MIDI pedal/controller), and this specific use case would require many changes and testing, so we really cannot offer an ETA for this.
More generally, having the Link being able to influence the Sylphyo is something we have on our roadmap, so we're interested in supporting your use case eventually, it's just that we cannot tell when it's going to be ready.

As for controlling the drone of Braveheart, assuming you just rely on the Link's audio output and not that of the Sylphyo, you can connect any MIDI controller that sends MIDI CC 1 (or whatever is configured in your Sylphyo for the slider) and use the controller instead of the slider, and it should work on the Link.

Cette fonctionnalité paraît simple, mais le diable est dans les détails… Pour que cette proposition puisse avancer, il nous faudrait un peu plus de contexte sur la façon dont cette fonctionnalité pourrait être utilisée, et la façon dont elle s'intégrerait avec le reste des réglages du Sylphyo.

• Est-ce que ça doit être vraiment un doigté ? Dans ce cas, que se passe-t-il avec le synthé interne ? Comment peut-il interpréter les touches ?
• Quelle est la finalité ? Avoir accès aux informations de touches pour qu'un programme ou un script (ou un patch Puredata ou Max) puisse utiliser ces informations et transformer tout cela en MIDI plus "raffiné" ? Dans ce cas, ne vaudrait-il pas mieux envoyer des CC ou des SysEx particuliers, vu que ça demande à peu près le même effort pour les traiter et que ça peut être envoyé en parallèle des autres informations que le Sylphyo envoie déjà, sans obliger le musicien à activer ou désactiver ce mode en fonction des besoins ?
• Ou alors, est-ce que les notes MIDI iront directement dans un synthé ou instrument virtuel sans traitement ? Dans ce cas, j'imagine que chaque utilisateur aura son idée du "mapping" idéal des touches vers les notes.
• Est-ce qu'il est également utile d'avoir des informations sur la proximité du doigt avec chaque touche ? Parce que c'est possible, mais ça implique aussi beaucoup plus de données MIDI qui circulent.

Pour pouvoir répondre à toutes ces questions, il nous serait donc très utile d'avoir le plus d'informations possible sur les contextes d'utilisation imaginés et vos besoins.