The Aodyo team is proud to introduce this new forum! Welcome!
We created this place to enable discussions around the Sylphyo.

We'd like this forum to be a helpful and friendly place where you can introduce yourself to the community, ask anything about the Sylphyo, showcase your last creations, or discuss potential issues. The Aodyo team regularly takes part in discussions and is committed to providing users with support when needed.

However, if you encounter a malfunction or any other issue with your Aodyo product, you may want to contact us directly (support@aodyo.com), and we'll make sure you'll receive a quick answer.

See you soon,
The Aodyo team

Thanks for your enthusiasm about the Sylphyo! To quickly answer your question: you'll be able to play a good and rich sound that evokes the flute in some aspects, but don't expect a realistic recreation of the acoustic instrument. I'll try to explain why.

It is extremely difficult to realistically re-create the sounds of acoustic wind instruments. It requires a profound understanding of the instruments, as well as very advanced digital signal processing and physics skills, and a ton of experience in the field of synthesis.
Our expertise is mainly in interfaces for musical expression, not in acoustic-sounding simulations. And as your experience with other wind synths shows, it's a job best left to experts, like our friends at SWAM and Samplemodeling, who took more than 10 years to achieve the best "acoustic" sounds available out there, and we encourage you to get their awesome products, and especially the Flutes. It's a blast to play them with the Sylphyo.

So the internal synth card we're developing won't have such realistic sounds, because very few people have the expertise to do them right, and if it's not as good as the SWAM sounds then people will be disappointed, like you were with the AE10.

However, there will be many sounds that respond like acoustic instruments and that'll be as lively. They will harness all the expressive potential of the Sylphyo, and we hope you will enjoy playing them, even though they don't sound like acoustic instruments.

We aim for a collection of vibrant and unique sounds that combine the richness and complexities of the acoustic world with the possibilities of the electronic world.
They will sound like nothing else, and they will sound good, not just because they'll use some new fancy synth techniques, but because they'll be tailored to the Sylphyo and its peculiarities.
It is now a widely accepted point of view in the research community that the relationship between the controller and the synthesizer (the mapping) is what makes the instrument what it is, and we intend to carefully design this relationship in all our sounds.
This is where our approach differs from others: we don't just add a synth to a controller, we turn the Sylphyo into many different wind instruments, and you might expect that both the synth and the controller will co-evolve in the future.

Our supplier says 250m if there's no obstacle between the Sylphyo and the receiver. I haven't gone much farther than 50m/75m myself, but it was fine.

It really depends on the Kontakt library you use. For instance, the Samplemodeling libraries (e.g., The Trumpet) automatically use the intensity of your breath (sent by the Sylphyo as MIDI CC11 messages, by default).

Some others are not programmed to use this information, but you can setup them to use it. The basic idea is to setup a mapping (using the MIDI mapping settings of Kontakt or your plugin host) that assigns MIDI CC11 to parameters like amplitude/volume/… I found a video tutorial that explains how to do it with any Kontakt library, and a forum post with some discussion about it. I hope it's enough to get you started.

Otherwise, if you don't want to do this, you can always set the Sylphyo velocity setting to Dynamic so that your breath controls how "percussive"/loud the beginning of notes are, with sample-based sounds. But if the sampler doesn't use CC11, you won't be able to continuously control the intensity of the sound using your breath, just note beginnings.

Don't hesitate to report your experience to us, this could help us add a Kontakt section in the user manual!

Hi Darryl,

Anything that responds to MIDI should work at least minimally (meaning, you will be able to issue notes, at the very least). The best synths and sound banks are those that can respond to MIDI Control Change 2 (Breath Control) or 11 (Expression), or even aftertouch messages: those will correctly respond to your breath.

If you want the simplest setup possible, our user guide provides some "quick start" advice with free/cheap synths for Mac, PC, and iOS. For instance, you can just plug the Sylphyo into a Mac, launch Garageband and play. But you won't get the best sound and it doesn't really reflect all the Sylphyo's expressive capabilities.

Now, we have our list of favorites, and what you'll like depends on what kind of sounds you'd like to play and how much money you're willing to spend.

For "realistic" wind instrument sounds, we are huge fans of Sample Modeling. Their VSTs allow to play many wind instruments (sax, trumpet, clarinet, flute…), even stringed instruments (check out the new Cello) using the Sylphyo. As it is a combination of sampling and physical modeling, the instruments are very expressive to play, and they're very light on memory. You can hear them in this video, for instance.
We also had successful experiences with SaxLab (there's a demo on their website).
One of our early adopters has also used Embertone Jubal Flute (check out his videos). We're aware of several other Kontakt instruments but we haven't given them a proper look yet.

For more electronic sounds, we like to use a Nord Modular G2 rack, but we haven't explored the virtual instrument space very thoroughly.
We're planning to investigate NI Massive and Logic Pro's new Alchemy synth, as well as the Moog Model 15 app another user has recommended.
One of our musician friends, Florian Becquigny, plays a lot of electronic music using the Sylphyo. If you're more interested in non-realistic sounds, maybe we can ask him to provide some advice on what he likes and uses most.

It'll depend on the synth you use and the mappings you can make. In many monophonic synths, breath control is often mapped to oscillator amplitude and/or filter frequency, so it's unlikely that a sustain pedal will have any effect… Maybe a polyphonic synth can be useful for this, if different voices are allocated to each note, but I don't really know. It could be fun to investigate the issue with a Max/Puredata patch or a nice synth platform like Falcon.

This isn't a Sylphyo-specific issue by the way, so have you tried looking for how EWI/WX players use a sustain pedal?

Videos are coming! Every week we work on new content! But we haven't mastered the Xpression yet, so we won't do a video about it if we can't demonstrate the awesome little features that work great with the Sylphyo! Of course you'll be able to test both if you come see us at Musikmesse.

Thanks for this quite complete report, Christian. Looks like you found a terrific setup! And you came up with a nice solution for the limited range of the Samplemodeling instruments. Reading your post made me look for my cheap Windows Bay Trail tablet and try out some SWAM instruments as well.

Of course, it's a 100€ 8-inch tablet (Dell Venue 8 Pro 3845, with 1G RAM), and Windows 10 is quite unreliable with it (I regret updating from 8.1), so I didn't expect it to be a trusty rig for live performance, but I found that it works surprisingly well for quick jams when loading only one VSTi.

First, I installed ASIO4ALL to be able to output low latency audio. Then, I downloaded the last 32-bit version of the SWAM Flutes and could install them without a hitch.

For the VST host, I didn't install Cantabile yet, but I had a copy of Hermann Seib's SAVIHost floating around (32-bit, VST2, with the embedded keyboard). It's a really bare-bones host with very few functions, but it does its job. So I copied savihost.exe to the same folder as the Alto Flute VSTi, renamed it SWAM Alto Flute 32bit.exe (the same name as the .dll) so that it would automatically open the VSTi at launch, and made a shortcut on my desktop. This way, I can just double-tap on the shortcut, and ten seconds later I can start jamming on the Sylphyo.

At first, I had some issues with some license dialogs on the SWAM interface that didn't manage touch input at all, so I used TouchMousePointer, an on-screen touchpad which is quite helpful when dealing with desktop and legacy software.
It was also helpful for precise pointing, so I could configure the virtual instrument with our recommended parameters without any problem. AFAIK SAVIHost doesn't allow to finely adjust MIDI input like you did, but a future Sylphyo update will allow to customize the ranges of CCs directly from the Sylphyo.

My tablet has only two ports : one micro-USB for charging and external devices, and one 3.5mm jack for audio output. Just enough for a battery-powered Sylphyo jam. So I connected the Sylphyo receiver device on the USB port using a micro USB OTG adapter.

In SAVIHost I went to the Devices > MIDI… menu, and selected Panda-Audio midiBeam as Input Port 1. Then, I went to Devices > Audio…, and I selected No Wave as Input Port, and ASIO: ASIO4ALL v2 as Output Port. After an intense parameter tweaking session, I settled on 44100 as the Sample Rate, and on 64 samples as the Buffer size.

To make it work without glitches, I also had to go to the ASIO4ALL control panel (in SAVIHost, there's a Devices > Asio Control Panel… menu), and change some parameters in Advanced options (the wrench icon):

• set the ASIO Buffer Size to 64 samples
• in the WDM Device List, select Intel SST Audio Wave for IHF, enable Out: 2x 48KHz, 16Bits and disable In: 2x 48KHz, 16 Bits
• in the Latency compensation section, set both In and Out to 0 samples
• and in the Options section, enable Allow Pull Mode, Always Resample, and Force WDM Driver to 16 Bit, and set Buffer Offset to 20 ms

With these settings, I could play without perceivable latency (there's slightly less when the output jack is used compared to the internal speakers).
SAVIHost shows my CPU is around 23% at rest, and around 75% when playing. I sometimes encounter brief buffer underruns (there are small audio glitches), but they should be entirely gone with a ≥128-sample buffer.

Having all the power of Samplemodeling instruments in such a small package is quite exciting! Here is a picture of my cheap mobile setup, and here is how it sounds. Again, for serious live performance I'd rather buy a powerful and reliable tablet like you did, but it's nice to know that even cheap tablets can run a Samplemodeling instrument.
The only issue I found with this setup is that there are much more glitches when the display is put to sleep, so I may have to create a custom "Sylphyo" power profile so that it never sleeps.

As for synth VSTs running on Windows, I rarely reach out for synths outside Live or other DAWs, so I couldn't say.

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.

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.

(English answer at the end)

Quelle technologie de machine virtuelle utilises-tu ?
Pendant la mise à jour, le Sylphyo et le Link changent de "personnalité" (classe USB) plusieurs fois, oscillant entre périphérique MIDI et périphérique USB HID. Cela peut poser des soucis à quelques moteurs de machine virtuelle car c'est comme si le périphérique USB représentant le Sylphyo se déconnectait et se reconnectait.
En général, nous avons toujours réussi à faire fonctionner les mises à jour dans une machine virtuelle, mais il faut dire à la machine virtuelle de connecter immédiatement tous les périphériques USB au lieu d'en laisser certains pour l'OS hôte.
Il y a ensuite des problèmes spécifiques à la version de Windows utilisée. La première fois que tout le cirque des mises à jour se déroule, Windows peut prendre un peu (voire parfois beaucoup) de temps à reconnaître les différentes "personnalités" du Sylphyo pendant la mise à jour.
La première chose que je vous conseillerais est d'essayer plusieurs fois, en faisant des redémarrages entre les tentatives, et si ça ne va toujours pas, de changer de version de Windows ou de moteur de machine virtuelle. Je réalise bien que ce n'est pas l'idéal. Des retours que nous avons eu, le peu d'utilisateurs linuxiens que nous avons s'arrangent en général avec un PC Windows ou Mac à côté pour faire les mises à jour.

Tout cela n'est pas simple, et malheureusement nous n'avons pas assez de ressources pour fournir le support nécessaire pour le fonctionnement de nos outils logiciels sous Linux, car il y a trop peu d'utilisateurs intéressés.
Nous utilisons également Wine pour tester notre version Windows (cross-compilée depuis macOS avec mingw-w64), mais comme vous l'avez remarqué le support MIDI dans Wine n'est pas encore très complet (pour cela, nous utilisons aussi une machine virtuelle).

Pour ce qui est de produire une version Linux native de notre utilitaire de mise à jour, le plus court chemin pour nous serait de proposer un outil en ligne de commande, mais il nous manquerait une couche MIDI fonctionnant sous Linux, ainsi qu'un pipeline de test pour Linux, mais nous sommes encore trop petits pour pouvoir pouvoir assumer ces développements en parallèle de nos priorités actuelles.

J'espère que ce post attirera de nombreux utilisateurs sous Linux, ce qui nous amènerait à remonter la priorité du support Linux dans nos priorités de développement.

Which virtual machine technology are you using?
During the update, the Sylphyo and the Link change their "personality" (USB device class) several times, switching between MIDI and USB HID device. Concretely, the switching is as if an USB device disconnected and reconnected several times during the update, and it can be problematic for some VM engines.
Up until now, we always had success with VMs, but with some we had to tell them to always connect new USB devices to the VM, not to the host OS.
Then, there are the Windows-specific problems, and they can differ depending on the Windows version. Notably, the first time the update dance occurs, Windows might take a little (sometimes a lot of) time to recognize and register the different USB "personalities" of the Sylphyo during the update.
As a first course of action, I'd recommend you to try again several times, rebooting the VM and/or the host in-between attemps. If it still doesn't work, it might be useful to try with a different version of Windows, or a different VM engine. I know it's far from ideal, but from what we've been told, the few Linux users we had generally managed to use a Windows PC or a Mac to run the updates.

That's far from simple, and unfortunately we don't have enough resources to provide the level of support necessary to make our software tools work on Linux, because there simply aren't enough interested users.
We also use Wine to test our Windows version (cross-compiled in macOS using mingw-w64), but as you've noticed, MIDI support isn't that great on Wine (that's why we also use VMs for our tests).

As for making a native Linux version of the update tools, the shortest path for us would be to offer a command-line tool, but we're missing a Linux-compatible MIDI layer, as well as a Linux test pipeline. Unfortunately, we're too resource-constrained to be able to develop this while continuing to pursue our current priorities.

My hope is that this post will allow many Linux users to be heard, and if so, we could increase the priority of Linux support in our roadmap.

Pour l'instant les sons du Sylphyo Bench ne sont pas disponibles comme sons internes dans le Sylphyo et le Link, mais nous pouvons réfléchir à cette possibilité à l'avenir.

The Link is powered by USB (5V and a few hundred mA), so you won't be able to plug it to the Ojai (which issues 9V). However, being USB means you can power it using any available USB port you have: on a computer, on a USB hub, on a USB charger, etc.

Le Link est alimenté par USB (5V et quelques centaines de mA), donc il ne sera pas possible d'alimenter le Link avec le boîtier Ojai (qui sort du 9V). Par contre, vous pouvez le brancher sur n'importe quel port USB : sur un ordinateur, un hub USB, un chargeur USB, etc.