Posts made by Clint

@support_aodyo Excellent insight and info ... Thanks!!

Pedro Eustache posted his Sylphyo settings on the Respiro forum ... it's from a while ago, but some may find it of interest ...

https://www.imoxplus.com/site/index.php/forum/tips-tricks/34-pedro-eustache-s-sylphyo-settings

From what I understand, the impedance (Ohm rating) of the headphones is very important for volume. There is an inverse relationship: more impedance (higher Ohm rating) = lower volume. However, more impedance also means better quality sound (for reasons of electrical engineering beyond my understanding).

Most "on the road" earbuds and "consumer" headphones seem to be low impedance, because the sound sources (MP3 players, smartphones, etc) don't have enough current to drive high-impedance headphones to sufficient volume.

The Sennheiser HD 201 of @Fanch35 is rated at 24 ohms ... in the "low impedance" category ... and should be quite loud.

The Ultrasone Pro 900 of @David-Lazzi is rated at 40 ohms, so they should be quieter (maybe twice?) and would require a higher volume setting to get the same level in the ear.

The Presonus HD7 and HD9 are rated at 32 and 40 ohms.

My personal preference are the line of Beyerdynamic headphones. They are ultra-comfortable (for me), have replaceable earpads, and come is a variety of configurations and impedance ratings. My preference is for closed-cell (closed-back) headphones, because I often do overdubs and don't want the sound of the track to bleed into my microphone. (However, that issue is now moot with the Syplhyo!)

I use the DT-770s in the 80 ohm and 250 ohm varieties. On the 250 ohm headphones, about 80-100% volume on the Sylphyo is right for me on Flute Phy # 30.

One concern for me: the strength and durability of the 1/8" headphone connector (and its neighbors, the on-off switch and USB port). My headphones have a spiral-wound chord and do put possibly heavy side-loads on the connector. If anything happens to the connectors in that area, I think it would be a big repair!

@support_aodyo The Factor Reset worked!! I can now store settings and they persist through a power cycle.

Thankfully, I wrote down the myriad settings I have adjusted ...

Thank you SO MUCH for your help!!

@support_aodyo Updating the Sylphyo to the v1.4.8b10 firmware seems to have no effect (although I do see a little "BC" symbol with a wave over it in the lower right of the display, with something that looks like a speaker to the right). I have not updated the firmware on the Link.

BTW this v1.4.8b10 does not have my Native flute fingering updates - the 6 additional fingerings from 25Feb21 ...

@support_aodyo It is only changes that I make. My setup as it existed before this issue began happing have not been affected.

The affected setup changes include Quick Changes made to the three parameters (Base pitch, Sound, and primary MIDI channel) as well as any changes made using the full menu.

My Sylphyo currently has firmware v1.4.8b4. I have the installer for v1.4.8b10, but hesitate to run it because whatever issue is causing the loss of settings might cause havoc during a firmware upgrade.

Have you heard of this happing before?

Not sure what could make this happen ... but ...

Any changes I make to settings on my Sylphyo are lost if I power the Sylphyo down and up with the power switch near the foot of the instrument.

Any advice??

Thanks Maxence ... yes, I've got that ... but the "3" in "C3" could mean (as I've found out recently) many different things depending on the octave numbering you use. The Sylphyo (from my examining the MIDI stream it puts out) puts out MIDI hex 3C = decimal 60 for "C3" which is Middle C. That's the same standard that Kontakt, Apple Logic, Cubase, Steinberg, and Yamaha keyboards use.

However, the ISO standard that is used by Korg, Roland, and most of the piano tuning and composing world (and also the Native flute world) use "C4" for Middle C. That's why I was always off by an octave before I understood these issues.

Cakewalk Sonar actually uses C5 for Middle C, which is really confusing!

The manual mentions C3 in a number of places, but never mentions that the Sylphyo uses C3 = Middle C (the Apple and Yamaha standard) rather than the ISO C4=Middle C standard (or Sonar which uses C5!).

This was actually a head-scratcher for a few minutes, until I saw the MIDI stream and realized C3 was producing MIDI note 60.

Hello @jcfitn ! ... interesting idea ...

If I understand your intent, I think that is achievable without modifying the Sylphyo. I use Cantabile to route the Sylphyo MIDI stream to many different places (software and hardware). It is designed to split the MIDI stream to may routes that go to many targets, and also apply complex filtering (curves, minimum, maximum and many more possibilities). There is a free version of Cantabile which has quite a lot of features ...

Alternately, the Sylphyo can transmit CC messages from the breath sensor on up to 3 MIDI CC channels simultaneously.

I just posted a "Cradle" on Thingiverse: https://www.thingiverse.com/thing:4801206 ... be sure to add felt pads (or some other protection) on the contact points with the Sylphyo:

@badblocks I would love to hear details on how other materials work with this part!

I am thinking that flexibility is a key issue. PLA is rather strong but not very tolerant of deflection - it tends to snap suddenly and with sharp edges. Something with a bit more give would be ideal ... maybe ABS? (I don't print in ABS because I don't have a good ventilation setup) ...

@David-Lazzi I realize that 3D printers are not yet mainstream enough for easy access for everyone. I wish we were able to produce and ship these plugs, but we are not really set up for that. One daunting issue is that many players are on the Continent and shipping to Europe for us is complex (forms and then more forms).

I have sent several samples of each of the three largest sized plugs to @Maxence822. I also believe that Aodyo is working on their own design. I am hoping that Aodyo will adopt a strategy for providing whatever turns out the be the best plugs to the community ...

@David-Lazzi I was doing pretty well with tape, but the back pressure varied every time I played (annoying), it sometimes gave way a bit and the back pressure would change, and it was mildly "unprofessional".

3D printing is easy for me, and if you have easy access to printing the parts I posted on Thingiverse, it might be worthwhile. However, I suspect the rolled-up tubing works just as well.

@badblocks I have just uploaded three more STL model files with more restrictive air channels ... https://www.thingiverse.com/thing:4768549 ... Please tell me how they work out.

The largest of my plugs should (based on the cross sectional area of the air channel) increase back pressure by a factor of 2.3, the smallest of my plugs (that I just uploaded) should increase back pressure by a factor of 6.7.

CAVEAT: I have not printed these ... but I expect they should work ...

@David-Lazzi Sadly, I am flutter-tongue-challenged**, so I can't test that.

On my instruments (mostly Native American flutes) my approach to growling is to hum. However, unlike the way sax players growl, I typically hum the same notes as I am playing. (It's easy - essentially a "sing what you play" exercise.)

On real-world Native flutes, prominent humming produces an "effect" that you might use only occasionally. However, very quiet / slight humming can be used more generally to control the timbre of my sound.

On real-world flutes, I suspect that the humming vibration cross-breeds with the resonant air column vibration in the flute's sound chamber to produce a complex vibe-child. For reed instruments, maybe the mechanism is different ... maybe it alters the way the reed responds??

On wind controllers with pressure sensors, I imagine that the sensor is rapidly responding to pressure changes and sending those changes at whatever rate the singles are configured (and certainly capped by the 31.25 kHz MIDI bitrate).***

It seems to me that the sound you get is based on how your sound generator responds to that stream of breath changes.

My setup parameters are:

• MIDI Mapping => Breath => Breath Rate = Medium (250Hz)
• Breath => Curve = Log
• Breath => Filtering => On
• (not sure what other parameters are relevant)

... and I have not (yet) tried any other settings

My experience with those setting on sampled-based virtual instruments (I'm mostly using Kontakt instruments I've recorded and constructed using Unisono - Portamento) humming does not work well. I get a stuttering effect that is not particularly useful (to me).

On physical modelling engines such as Respiro, the results seem to be much more useful. Of course, Respiro is not modelling real-world instruments but instruments that really are virtual, so there is no set standard. But to me, some of those instruments do produce effects with humming that do seem cool!

** I have a "tied tongue" - a connection on the bottom of my tongue to the floor of my mouth that prevents me from flutter tonguing. It is a tradition at our workshops that our student will flutter tongue at every opportunity as a joke.

*** Does the 31.25 kHz MIDI Baud rate also apply to MIDI over USB?? I can't find a source that addresses this ...

@badblocks Thanks for the feedback!

Wow ... so you prefer the most restrictive one? The one with the most back-pressure?

I just want to confirm ... and, if so, I can easily produce even more restrictive plugs ...

I have tried rather persistently to make this happen, and I have not been able to. My firmware is v1.4.8b4, so that may be a difference.

I experimented using 5+2 mode both with a fingering that defines pitches for the thumb pad open (the new "Native American Flute+" fingering) as well a one which has "don't care" for the thumb pad (Recorder). Both resulted in the same ... I could not get any notes to stick.

I was working with only the top pad on the front side of the six main pads closed. That is the failure mode, correct?

I've been working on developing a 3D-printed "Cradle" to hold the Sylphyo level (like on a table - without rolling) or (optionally) at a shallow inclined angle. Should be ready in a week or so, and I'll post the model on Thingiverse for general use ...

One possibility may be to develop a Sound Library (Kontakt, SFZ, Decent Sampler, etc) for the instrument and map an existing fingering onto your preferred fingering. This would mean the library could not be used for general use, but would work for your situation. It's not too hard to move sound samples around so that they are triggered by different MIDI note values.

This would not work for half-holed positions however ...

My life-time supply of Bell Port Plugs:

I have just posted Version 2 of my design on Thingiverse: https://www.thingiverse.com/thing:4768549

It includes numerous improvements in fit and reliability. It also accommodates different Inside Diameter (ID) values. Three ID sizes are provided - 4.0mm, 3.6mm, and 3.2mm - resulting in progressively less airflow requirements when playing the Sylphyo.

It also includes extensive information on print settings and post-processing (filing with needle files) to get a reliable fit. I do believe that any 3D printed part will need to be carefully sanded or filed to comfortably fit into the bell port of the Sylphyo.

Feedback welcome!

I've printed in different colors to flag the Internal Diameter sizes: 4.0mm (black - about half the airflow), 3.6mm (brown - less airflow needed), and 3.2mm (red - substantially less airflow needed)

@zzrichie said in Blocking the Bell Port:

Quand allez-vous livrer avec le Sylphyo des embouts pour régler le débit d’air ?
When will you deliver tips to regulate the airflow with the Sylphyo?

I am working now on an updated "Bell Port Plug" design. It will be available as a 3D Model (OpenSCAD and STL format files) in 3 different sizes for 3 different amounts of airflow and back-pressure. I will also include a detailed description of how I have been printing and finishing these plugs (post-processing with a file is very important!)

My updated version should be available in a few days ...

I believe Aodyo may also be working on their own part (which will likely make my version obsolete ... ah well!)

@Blonk said in Pinky Spill-Over:

pinky pads might be found a bit too aside the row

Agreed!

I do find my fingers dragging a bit and occasionally activating those pads unintentionally.
With 6-hole wooden flutes, we are always advising students to get their pinkys onto the body of the flute for added stability, and this is now the opposite ...

Here's the best capture I could get from the video:

This YouTube video: https://youtu.be/a_hBfIENVX8?t=99 ... at 1:39 shows (very briefly) a pair of floor stands / holders for two Sylphyo instruments (Pedro's, I'm guessing).

Would anyone have any info on these or any other style of stand / holder for the Sylphyo?

My regular flute stands don't work because of the closed bell, and I have not good place to put the instrument down in a confined space that would be safe ...

Has anyone noticed that the sensitive area - the area that the Sylphyo recognizes a touch - is larger for the two pinky pads than the other fingers?

Specifically, on mine, the sensitive area for the pinky pads seem to extend up above the two pinky pads, wrapping up towards the top centerline of the instrument.

Not an issue (at all!) but just a observation and ... I'm curious ...

Have others seen this behavior??

@badblocks Great to hear!

I should really produce models with several sizes of air channels for different back pressures. The one you printed has a 4.0 mm internal channel (vs. the 6.0 mm on the Sylphyo's open bell port with no plug). That reduced the airflow by about half (I tested this with a pressure meter). I will probably do versions with 3.6 and 3.2mm internal channels ...

I've just posted an updated version - v1.008 - of the Sylphyo font package. It has some of the updates discussed above. Feedback welcome!

https://www.Flutopedia.com/sylphyo_fonts.htm

Here are the images I tried to post in the message above ...

The 10 versions, with #1 being the @meteredsection design, and the #10 (in Red PLA) being the released version.

The #2 and #3 designs used a tapered cylinder covered with heat-shrink tubing. These designs did not work so well ... the heat to shrink the tubing also melted the PLA. And, because of the taper, the tubing slipped off even after it was melted. The #5 design failed because the tabs were too slender.

The # 9 design was a test of whether a longer internal channel changed the wind noise and/or back pressure. It hardly did at all ...

Here is a rendering of the design file as posted on https://www.thingiverse.com/thing:4768549 :

And here is the plug installed in the bell port:

I've built on the design of @meteredsection and developed another 3D-printable model, available under CC-BY at https://www.thingiverse.com/thing:4768549. I also released the OpenSCAD source code, so folks can modify the design (especially the inside diameter of the airway) to suit their breath pressure preferences.

It took me a series of 10 designs till it worked reliably and I was happy with the resulting breath pressure / airflow:

(I keep getting "Something Went Wrong While Parsing Server Response" when I try to upload images ... no idea how to get around it ... oh well, check out the Thingiverse link above)

My final design reduces the breath pressure and airflow requirements by about half.

Some things I observed along the way:

• Grabbing the plug with your fingers to remove it can be a challenge. I made the plug extra long and included a flared foot end with four sharp nubs is designed to make it easy to remove.

• Wind noise is an issue! Without a bell port plug, the open bell port of a stock Sylphyo produces very little wind noise. I found that beveling the internal windway channel with numerous tapered bevels noticeably reduced wind noise, but it is still can be an issue, depending on your playing situation.

• I wrestled with a characteristic of my early designs where, as I added breath pressure, the resistance I felt did not increase smoothly. It was weird, but there were "jumps" in the amount of resistance I felt and also corresponding changes in the wind noise. Very disconcerting while playing. I also had this issue with the @meteredsection design that I printed. I am guessing it had to do with an interaction between the tabs and the top of the air channel. When I added bevels on the internal channel, the problem went away.

• Sanding the inside of the airway does make a bit of a difference. I did light sanding with a cylindrical needle file. It seems to reduce wind noise a bit and slightly reduces breath requirements.

• The fit of the plug as I designed it may differ depending on what materials you use and your print settings. I printed the part in PLA at 210 degrees nozzle temperature with a 0.10mm layer height.

I did do a small study of the amount of breath pressure needed with various designs. I measured the MIDI CC#02 Breath Pressure commands issues by the Sylphyo configured with Breath Settings: Minimum: 20, Range 600, Curve: Log, and Filters: Enabled. I measured through a Link into the Sylphyo Bench application running on a Win10x64 system. I measured pressure in milli-PSI using an intra-oral breath pressure meter that I used for a study in 2013. The meter is described in the Measurement section (pages 2-3) of Goss, 2013, "Intraoral Pressure in Ethnic Wind Instruments" available at https://www.flutopedia.com/breath_pressure.htm and at https://arxiv.org/ftp/arxiv/papers/1308/1308.5214.pdf.

I measured "Half Pressure" and "Max Pressure" pressure readings from the intraoral pressure meter when the Sylphyo Bench application's meter for CC#02 was showing half and full scale. All readings are in milli-PSI. The "I.D." measurements are the Internal Diameter of the air channel in that plug's design.

• With no plug installed (bell port open) the I.D. is about 6.0mm and I got pressures of 54/96 (Half/Max pressures). For me, this is way too much pressure / airflow and I run out of breath quickly. My phrases. While playing. Became. Quite. Short. I am comparing this with Native American flutes that I typically play.

• The @meteredsection design with an I.D. of 2.5mm (measured from my print) got pressures of 18/45. It takes very little air to reach the Half and Max MIDI CC#02 of the Sylphyo.

• The happy medium (for me) is the final design I released. It has an ID of 4.0mm and registered pressures of 22/52 - slightly more than the @meteredsection design.

Thanks for the feedback @join !!

Love the "Dot for Don't Care" idea. I'll run a test case shortly ... One thing that Aodyo does in the Sylphyo User Manual is to choose the most appropriate symbols - open or closed - for the Don't Care locations based on what a player would usually use. Maybe there are two Don't Care symbols one for "This looks Closed but really it's Don't Care" and "This looks Open but really it's Don't Care" ... maybe a small white dot on a big black circle and then a small black dot inside a white circle for those two symbols. I may be overcomplicating this, and it would be complex to explain to users ... most of whom just want to get on with things ...

A 512-character block with all 2^9 combinations of open and closed is straightforward ... excellent idea! I can probably do this programmatically. I would map it out literally like the bit patterns starting from all holes closed at (say) code point U+EB00 and ending with all open at U+ECFF.

FF Chartwell uses Discretionary Ligatures, a feature I've tended to avoid for font features that are central to what users need. I'm generally concerned with complexity and implementation of the features in apps (including older versions that many people tend to use).

However, I have done something similar without any OpenType layout features at all. I could create a block of Composite Characters. Each Composite character has a piece of a finger diagram - the outline, the open hole symbol in each of the 9 locations, the closed hole symbol in 9 locations, and etc for don't care, trill, half-hole - a total of around 50 characters. All the Composite characters would all be set to "Zero Advance Width" ... the cursor would not move after typing each of these characters, so you simply build up your image by typing 9-10 characters over each other. You then hit the space bar to advance to the next character. Laborious, but at least you can get any finger diagram you want. In practice, this scheme works "Pretty Well" - most applications seem to render them correctly. I have had cases where PDF viewers have micro-errors in positioning, so a composite character comes out a bit "fat".

This Composite Character scheme could be added to the fonts in a small 64 character block without too much hassle. It would take a fair bit in the User Guide to document it ...

Another alternative would be to use Stylistic Sets. This could allow us to map the QWERTY keyboard onto the finger diagram glyphs. OpenType allows 20 Stylistic Sets to be specified. Each stylistic set could be used for a different instrument (Flute, Sax, etc.). A stylistic set could also be used for those Composite glyphs described above. So a finger diagram could be accessible at a code point (e.g. U+ED01) and also by choosing Stylistic Set (eg. SS01) and typing a "1".

The Sylphyo fonts actually are OpenType fonts - technically "OpenType with TrueType Outlines", but the term TrueType is more familiar, so I tend to use that colloquially.

Thanks again for the feedback!!

Thank you @reidid789 and @Support_AODYO for your kind words. The folio is derived from my Kurinto project, so was not that much of an effort.

I might suggest installing just one of the typefaces - maybe Sylphyo Text or Sylphyo Sans. This initial v1.007 is certainly not the final version, and that will save some re-installation effort.

Any feedback is welcome!

• Is the Quick Start clear?

• Is it clear how to actually get finger diagrams to show up in your document?

• How do the finger diagrams look to you? (Especially my use of the "X" "Don't Care" symbols).

It looks like the version that I implemented in the font folio is the "Saxophone", not the "Alt" or "Alt2" or the "Old".

What I really need to do is to expand the existing Sax block with the (very) few additional finger diagrams so that the superset of the 4 Sax fingerings is covered.

I also need to augment the Character Map document to show each of the four Sax alternatives separately, since those sections of the Character Map document imply a mapping not only from patterns to code points (e.g. ED01) but also from pitches to code points.

Good catch @frank !!

Both the Sax and Flute have different "Flavors" of fingerings on the Sylphyo, but I only have one definition file for the Sax and one for the Flute. I had assumed that the different flavors of sax/flute use the same finger patterns, but produce different notes. I have not looked into it that deeply ... maybe my assumption is wrong ...

Thanks for pointing this out ... I had forgotten that I made that assumption early on (i.e. 4 days ago).

I’ve developed a package of TrueType fonts that contains finger diagrams for the Sylphyo. The package is freely available under an open-source license (SIL’s “Open Font License”).

The package of fonts and (rather extensive) documentation can be downloaded from my Flutopedia web site: https://Flutopedia.com/sylphyo_fonts.htm

The primary documentation is:

• The User’s Guide – https://flutopedia.com/pdf/Sylphyo_UserGuide.pdf

• The Character Map – https://flutopedia.com/pdf/SylphyoCharacterMap.pdf

… both of which are in the release package.

And … be aware that you do not need to install all the nine typefaces. Each of the typefaces has all the finger diagrams – you might consider just installing the Sylphyo Text or Sylphyo Sans group of fonts.

This version contains finger diagrams for the Flute, Sax, and Native American flute (a fingering that will likely be in an upcoming firmware release). I hope to be able to extend the fonts to the other fingerings that the Sylphyo offers.

Feedback would be most welcome. In particular, I am curious about how folks like my use of the “Don’t Care” symbol (And “x” through an open hole) for finger locations that can be open or closed. The Sylphyo manual tends to show an open or closed fingering for these locations, but I (as a player) like to know when the fingering is optional. However, it might not be as easy to sight-read with these “Don’t Care” symbols.

One option that I like is to use an inexpensive (and very useful) USB Power Meter.

It indicates how much current is flowing and at what voltage (should be around 5 volts). Here is the power meter hooked up to the Sylphyo:

... the Sylphyo USB charger is on the left, followed by the Power Meter, then the cable that connects to the Sylphyo. The Sylphyo is powered on, and is drawing 170 mA @ 5.08 V.

Here is a close-up of the Power Meter:

When the Sylphyo is fully charged, the current will drop to about 40 mA.

I ordered this from Amazon: https://www.amazon.com/gp/product/B07FMQZVW2

Thanks Maxence ...
The "mildly irked" comment came from the situation: "I'm playing tonight ... I need to be fully charged ... but is it charging??"

I've been mildly irked that the Sylphyo did not have a charging indicator - a light to indicate when it is plugged in and charging. Then I realized that, when turned on, it displays a little charging status icon in the upper right of the display (the battery icon), which changed to something looking like a lightning bolt when plugged in.

@Support_AODYO Excellent!

I can confirm that it is a power issue with my system. When I turned off the phantom power supplied by the RME interface and plugged in the Link, the RME did not fail ... for a while. (When I played for a bit and the RME had to drive headphones, then the RME failed - presumably because of the power demand of driving the headphone).

Looking at the specs (which I should have done initially), the RME draws 3.7 watts "typical" and 5.4 watts "max". At 5V USB power, that's 740 mA typical and 1,080 mA max ... higher than USB 2.0 max rating of 500 mA (https://en.wikipedia.org/wiki/USB).

It seems that later versions of USB provide more power: USB 3.0 @ 900 mA; USB 3.2 Gen2 @ 1,500 mA and USB-C at 3,000 mA. Good info for avoiding this problem in the future.

Can you tell me, What is the power consumption of the Link? (I could not find this info in any documents)

@Support_AODYO / Maxence ... Thanks for addressing this!

My current configuration is to connect the Link to my Windows machine with a [USB Mini-B to USB-A] cable going from the rightmost "USB Power Supply" connector on the Link to a USB-A port on my computer. I use this to get MIDI from the Sylphyo wirelessly into Catabile and the Kontakt, various soft-synths, etc.

Is that configuration correct? (i.e. using the "USB Power Supply" port)?

Can I alternately use the "USB Host" port on the Link to connect to my computer? (That doesn't seem correct, because it would involve a [USB A to USB-A] connection, which I am guessing is never correct.)

I was thinking that if I could use the "USB Host" port for a computer connection, I could then plug the charger that came with the Link into the USB Power Supply port to power the Link, thus reducing the power load on the computer (probably a good thing). This setup would also allow me to test if the "Interaction" problem I had (halting the RME drivers) was due to excessive power demand.

Strange thing happened when I plugged in my Link this morning: it disabled my RME Interface.

The RME still had lights, but all the RME devices that appear on my Win10x64 system shut down, as if the RME had been unplugged. When I unplugged the Link, the RME devices immediately re-appeared. (This was really annoying, because I was trying to play the Sylphyo on a Zoom session, and the whole exercise fell apart)

Both the Link and RME were plugged in to USB 2.0 "mid board" ports wired to an Intel X299 chipset.

When the link the Link was moved to a USB 3.1 Gen2 "mid board" port wired to the same Intel X299 chipset, both the Link and RME worked fine.

So ... could it be a power issue? (Both the Link and RME interfaces are USB-powered). I'm not sure if the 2.0 and 3.0 ports on the X299 chipset share the same power supply.

Other ideas??

If more testing would help, I have these USB ports available that I could plug either the RM or the Link into:

• 2x USB 2.0 "back panel" ports on the X299
• 3x USB 3.1 Gen2 "back panel" ports on the X299
• 2x Intel Thunderbolt 3 (USB Type-C) ports
• 1x USB 3.1 Gen2 Type-C port on an ASMedia USB 3.1 Gen2 controller

There are two other ports on the ASMedia USB 3.1 Gen2 controller that I do not believe are actually wired to connectors on this workstation: one Type A and one Type C USB 3.1 Gen2.

Note on #3 above ... it should really read:

3. Tape. I remove the tape I use to partially cover the "Bell port" - the small exit hole at the bottom of the Sylphyo. This tape increases back pressure and reduces the amount of air needed for playing.

I've been working with the Sylphyo for a month now, and have developed a cleaning process. I wanted to share it with the community and get any input / feedback on how best to maintain the Sylphyo.

There is an official video here: https://www.youtube.com/watch?v=yeQnAdzUxvU. See also threads on this forum at https://community.aodyo.com/topic/41/cleaning-inside and https://community.aodyo.com/topic/245/cleaning-tips.

Things that failed for me:

• Wrapping a paper cloth around a straw. Both are soft enough, but the cleaning is incomplete and lots of moisture remains.

• Cutting a micro-fiber cloth into a long strip for use with the straw method. The edge of the cloth sheds fuzz and particles - bad idea inside the instrument!

My current procedure that seems the best:

1. Power. I turn the Sylphyo off and disconnect the charging chord.

2. Mouthpiece. After playing, I remove the mouthpiece and forcibly blow air "backwards" (upstream - from the round end to the small square "top" end) to expel as much moisture as possible. I do it upstream because it accelerates more air through the top end. I don't yet have a good way to pass a cloth through the mouthpiece. Wondering if I could just run the plastic mouthpiece (and O-ring) under water.

3. Tape. I remove the tape over the "Bell port" - the small exit hole at the bottom of the Sylphyo.

4. Tapping. I invert the Sylphyo with the blue ring down and gently tap, tap, tap the instrument onto an absorbent microfiber cloth doubled up on my thigh for maybe 20 seconds. If I have played a while (more than 15 minutes), a significant amount of moisture taps out.

5. Cleaning. I run two silk cleaning cloths at the same time completely through the Sylphyo, inserting in the blue ring end and pulling them out through the bell port. They are the two blue cloths in this photo:

... These blue cloths are made by Hodge ...

... and are available on Amazon here: https://www.amazon.com/gp/product/B001M5CZR8

The blue silk cloths are 4" wide at their widest point. Each has a weight on a string at one end and an unweighted "retrieval" string at the other end - in case the cloth gets stuck and has to be pulled out backwards. I have found that two cloths used together do a better job of cleaning than a single cloth. I have also found that pulling the cloths slowly (maybe 10 seconds) does a much better job than pulling them quickly.

To use the two blue cloths together, I insert the weighted strings into the "neck" of the Sylphyo (at the blue collar) with a slight offset:

... which allows both weights and strings to pass through the bell port at the distal (bottom) end of the instrument.

I have also tried the clarinet cloth by Hodge (the burgundy cloth in the photo above) but it is (A) too wide for the bell port of the Sylphyo and (B) has no retrieval string.

6. Inspection. I have had good luck checking the interior by sighting down the barrel of the instrument from the blue collar to the bell port. If I point the bell port at a light bulb, it lights up the interior walls of the airway and I can look for any remaining moisture. Here's the best photo I could muster:

7. Air Dry. I leave the Sylphyo open, without the mouthpiece, to air-dry when I am not playing it.

That's it! Any feedback, ideas, or advice is appreciated.

@join said in EVI and EWI Alternate Fingerings:

Hamming distance computation

I am thinking that Hamming Distance is a good starting point, but may have to be modified by issues of kinesiology such as "it's harder two swap two fingers (i.e. pick one up and put the other down) that are next to each other vs. on different hands". The condition where two fingers always move together (I think it's called Focal Hand Dystonia) may be an extreme example of this issue.

I wrote a quick YAML (Yet Another Markup Language?) parser in perl to check for errors and coverage, but wound up manipulating my experimental mappings in Excel and (gasp) pencil and paper.

One decision I am thinking for a designer of a finger mapping is:

"Should the finger mapping cover all the possible fingerings, or leave some NOP (no-operation) fingerings that would be ignored (i.e. play the most recent pitch)".

I chose to leave some NOP fingerings because

• (a) I suspected that additional fingerings might take up storage (does not see to be the case, based on the description of @join), and

• (b) the 15 NOP fingerings in my YAML spec (out of 64 non-pinky fingerings) do seem to me to be "mistakes" and are probably best left at the most recent pitch.

@join said in Support for high-resolution MIDI?:

Have you found a good solution for this?

Yes! For my current use - Sylphyo => Link/MIDI => Cantabile => Kontakt 6 - the facilities for drawing response curves has been the complete solution for handling this issue. This was suggested and discussed in detail in this thread on the Native Instruments forum:

https://www.native-instruments.com/forum/threads/high-resolution-breath-controller.442309/

... and I have found that the flexible envelopes (drawn, rather than the table option) are a straightforward and complete solution. I have recently been using envelopes for other purposes - controlling parameters on modular synths using elevation and roll (have not tried compass yet) and that is a fantastic alternative to expression pedals.

For other scenarios that do not have the flexibility provided by Kontakt, I am not sure the solution. MIDI filters do not seem to be the answer, since they are translating MIDI to MIDI, not extending the bit depth of the MIDI stream itself.

There might also be an issues for sound libraries that are encrypted (locked) by the vendor, rendering the curve inaccessible - but I'm not sure about that.

... and Thank You @join for the amazing amount of detailed information!

Right ... those rule-based descriptions in the manual are great, but I am thinking that the Sylphyo engine does not actually work on rules (based on work I did programming two new finger mappings).

It seems to have a set of patterns that allow closed, open, and "don't care" finger positions. And if no pattern matches (i.e. the 2^8 (256) possible non-thumb fingerings are not completely covered), then I am thinking the Sylphyo ignores the fingering.

Very interesting that you generated the PDF programmatically - I have been working on a TTF font - it is currently an (old-style) Windows symbol font, but I am planning on converting it to a bona-fide Unicode font using the Private Use Areas.

@williamjturkel I believe that there are no rules involved with finger mappings - at least they are not specified that way when developing a new finger mapping. There are finger patterns - like you show in your PDFs - with the addition of a "don't care" option for any given finger position.

I think anything that is not covered by (i.e. does not have a specified fingering) in the finger mapping results in a "do nothing" - i.e. continue playing the last pitch.

Interesting ...

I am wondering, however, if some of the fingerings you have listed are "producing" a particular pitch because it was a hold-over from the most recent pitch you happened to be playing. My experience is that fingerings that are unassigned in a particular finger mapping simply continue to play that most-recent pitch.

Also, what I have begun mapping are the "don't care" finger positions. I have found it useful to combine fingerings using a "don't care" graphic notation (maybe a grey circle, rather than black or white ... although this does not work well if you are building a TTF/OTF font).

The "don't care" system is used by the Sylphyo itself, or at least by the developers in programming the Sylphyo for a new finger mapping.

Folks who use Reaper might be interested in a set of track icons I developed for the Sylphyo.

I've made icons for the Sylphyo alone as well as versions that indicate the Link (upper right), and MIDI vs. Audio signal (lower left). Here's what they look like in a recent project of mine in Reaper:

As of Reaper v6.19, for Windows 10x64, the unzipped images should typically be placed in
/Users/<user>/AppData/Roaming/REAPER/Data/track_icons/Sylphyo

This package is released under the CC0 "No Rights Reserved" Public Domain Declaration (https://creativecommons.org/share-your-work/public-domain/cc0/)

I do not have sufficient privileges on this forum to post a ZIP file, so here's a link to the package on my server (another, more "privileged", user might want to fetch and re-post the ZIP file on this forum):

https://ClintGoss.com/zip/SylphyoReaperTrackIcons_ClintGoss_v1.00.zip