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 ...
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 ...
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!
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:
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:
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:
Power. I turn the Sylphyo off and disconnect the charging chord.
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.
Tape. I remove the tape over the "Bell port" - the small exit hole at the bottom of the Sylphyo.
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.
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.
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
I've got my Sylphyo turned on and paired with my Link.
Pressing the Up and Down (^ and v) buttons seem to do nothing. I was thinking that they should change the Link to output the next / previous sound setting on the Line Out and phones channels.
The Up/Down buttons themselves seem to work physically, since holding them both puts the Link into pairing mode.
What am I doing wrong??
When I first set up the Link, I was scratching my head a bit looking for the ASIO driver. Did not realize the USB connection was MIDI-only (it is MIDI-only, yes?)
Are there any plans to promote the Link to an audio interface? I am currently running the Line Out to an RME Interface on it's own USB port.
If it is not possible to run the Link on its own ASIO connection, I could re-wire the MIDI out of the Link into the the RME Interface and save a USB connection. My laptop only has three USB connections, and I'm guessing that using a USB hub would be a no-go for audio work.
Does the Sylphyo accept MIDI patch change commands from external sources?
I would love to use an external controller to change patches abd base keys without having to with the (admittedly easy) patch change and key change interfaces on the instrument itself.
Could you tell me whether the Line In and two Line Out connections on the Link are Balanced (TRS) or Unbalanced (TS)?
Any advice on taking the Sylphyo on commercial airliners? Does anyone have experience taking a Sylphyo through an airport security check?
I routinely fly with a flock of Native American flutes - wood flutes in a cylindrical case. I always board early (by standing in line) and store them in the overhead. U.S. law requires airlines to accommodate musical instruments if they fit in an overhead compartment (of any cabin class) at the time you board the aircraft.
So I guess the big issue is the security check. My flute cases are PVC or aluminum and the flutes are wood. Here is the current aluminum case I have now ...
... and here are the cases I have available ...
These XRay well and the security folks do not seem too bothered (although I sometimes have to take them out and play them).
Should I add my Sylphyo to my carry-on case? The sight of a stick full of wires and electronics on the XRay screen might cause issues ...
@Laurent_AODYO said in Support for high-resolution MIDI?:
requiring twice the bandwidth of a standard MIDI message
Watching the messages fly by, I suspected as much ...
I believe (hope) that the "server side" solution for Kontakt that I described above, as provided in the Native Instruments forum, is the complete solution. It does require the sampler to have such a custom envelope facility, and I have no idea if other samplers offer that.
Another "client side" ("Sylphyo-side") solution might be to offer another choice for Breath => Curve ... maybe a "Hyper-Logarithmic" or "Log-Log" or "Log-Squared" (Log^2) curve? That would probably approximate what I am doing in Kontakt ...
Here's (what appears to be) a solution for Kontakt. It was provided in the Native Instruments forum in post #6 of this thread:
https://www.native-instruments.com/forum/threads/high-resolution-breath-controller.442309/
In addition, I did find that in Kontakt 6.4.2, I am able to use the Volume modulation in the Amplifier section by using a Flexible Envelope. (I don't know if Flexible Envelope is available in all/earlier versions of Kontakt).
Using a Flexible Envelope - either using Bezier curves or the Table option - I can then define any curve I like. With a very gentle rising slope from the left (CC2 = 0) end of the range ... I have reduced the stuttering to almost inaudible.
As Stephen23 pointed out ... "You'll find 7-bit control entirely adequate".
(However, I just found out that Kontakt 6 does not handle 14-bit BC MIDI commands ... Sigh.)
No Luck. Setting MIDI Mapping => Note-off delay to 1ms is substantially worse. Values of 20ms and 75ms are no improvement. I reset it to 10ms.
I also experimented with setting Breath => Filtering to Off, which made this stuttering issue much worse. Setting Breath => Curve to anything other than Log made the stuttering issue worse. Log-Lin was worse and Linear was much worse.
I have also been experimenting with various MIDI filters in Cantabile to try to minimize stuttering, with no success ...
I am thinking that any solution short of 14-bit BC commands will inherently be prone to stuttering at low volumes.
What are the prospects for 14-bit Breath Controller output from the Sylphyo?
I looked into this recently. GigPerformer and Cantabile seem to be the front-runners on Win10 systems.
I've been using Cantabile (for no particular reason - could not find an authoritative comparison of the two), and so far I have been very happy with it. Did a recording session (a pianist playing a MIDI keyboard rendered using a dozen massive virtual pianos in Kontakt) as well as one live gig on the Sylphyo (one piece only - just a test run) in the first two weeks. Cantabile performed with no glitches!
@Support_AODYO Thanks for the info.
I tried setting Breath => Minimum to 5, 1, and 117. This seems to change the minimum breath pressure where a "Note On" occurs from very low to pretty hig, but the first Breath Controller value transmitted is still 1 (looking in MIDIView). And, if I "hang out" right at that minimum breath are, I still get a "stuttering" that I'm pretty sure occurs when Breath Controller values of 1, 0, 1, 0 are transmitted (I have seen strings of at least 10 of these [1,0] sequences before a Note Off is transmitted).
The solution might lie in the volume curve of the virtual instrument I am playing. I am not sure right now what I volume curve my virtual instruments are using (or how to change it ... I'm pretty new to virtual instruments), but I can imagine that there is a curve someplace that tells Kontakt how to shape the volume output based on Breath Controller inputs. Rather than a straight line, if it were an "S" curve or Bezier or some such, then the volume output with Breath Controller = 1 would be greatly reduced and the "stuttering" might be inaudible ...
I am a bit confused. Do (some or all) Sylphyo devices have a LED someplace? I cannot find it on mine.
The LED on Link receiver does work as you describe ... Does the setting on the Sylphyo somehow control the LED on the Link??
An outstanding design @meteredsection ! I work in OpenSCAD (a solid geometry design language), but an STL file would be very helpful as a reference.
Would you consider releasing it (maybe Thingiverse) or sharing it here? Alternately by direct email (I am at clint@goss.com) would be great ...
Thanks for this design!!
Could you describe the LED setting?
It is on my Sylphyo v1.4.7, at the top level between Receiver device and Diagnostic.
@meteredsection would you be open to sharing your design? Maybe a photo? Possibly an STL file??
I will be away from my 3D printer for a while, but would be interested in a range of options for controlling flow and back pressure.
Was thinking of maybe a series of different plugs with different port diameters, possibly in different colors to keep them from getting mixed up. Alternately, a single, adjustable device, maybe with a screw-type arrangement that could be turned to change the port size.
Would be interested in how your plug sits in the hole. Hard plastic (PLA, I am assuming) my not be easy to wedge into the existing Bell Port hole.
I am hoping this explains what I am hearing at low breath pressures. I've only been working with the Sylphyo for 3 days, but my playing style does use low breath pressures, and so this issue stood out.
I recorded a short demo emphasizing low breath pressure. The demo is on the Sylphyo via Link through the Patchman English Horn sample set, using Kontakt and recorded in Cantabile. Here is the waveform:
Here are links to WAV and MP3 (Lame -v2) versions of the recording:
https://ClintGoss.com/mp3/LowBreathPressureDemo.wav
https://ClintGoss.com/mp3/LowBreathPressureDemo.mp3
... The critical areas are in the areas (in seconds) of 1-2, 13-15, and 20-22.
Is the "jittering" in those areas due to 7-bit MIDI?
@Support_AODYO said in Mold growing inside Sylpho:
... I also don't think fungus likes plastic very much, as wood is a much more natural habitat for them.
This article: https://ultra-fresh.com/can-mold-grow-on-plastic/ (possibly self-serving, but it does look reasonably balanced) talks about the ability of mold to break down the additives to many plastic, and also the ability to thrive in a moist environment with deposits on the plastic surface.
However ... the mold issue that I described above happened once in 17 years to a single flute (of 300+) that I overplayed for several days in a row and did not allow to sufficiently dry.
I am suggesting Tea Tree oil only as a possible remedy - not on a regular basis.
I am thinking that removing the mouthpiece and suspending a medical swab with one or two drops of oil in Sylphyo main chamber would be a good first attempt at a remedy for mold.
Here is my diagram of how I recommend this for Native American flutes (a two-chamber flute) ...
Another idea would be to put 1-2 drops on the inside of the mouthpiece, insert the mouthpiece, and lay the Sylphyo down overnight horizontally (so the oil does not drip down into the instrument). The idea is that the fumes of tea tree oil are what affects mold. The mouthpiece is ?probably? impervious to tea tree oil), and in any case could easily be cleaned or replaced.
Again, these are my (untried) ideas for a remedy ...
Yes, La Poste did provide a tracking number with USPS. However, that number was not useful, since the USPS tracking site provided no information on the package (always reporting "status not available").
The holiday season certainly affected delivery, so I am thinking that 22 days total delivery time was "not bad" in this situation.
However, optionally offering other shipping options (DHL?) might be useful for those who want a Sylphyo quickly (and who doesn't?)
Another downside of USPS is the wear and tear on the package. My Sylphyo box looked like this on arrival:
and I was horrified that there might be damage. Thankfully, the internal box and instrument were completely un-damaged.
