Call for beta testing

[MrMep]

I just submitted a new PR https://github.com/amowry/WARBL2/pull/17 in the develop branch of this repository.

If you can compile and test the new modifications, you are more than welcome to do that and report back here or in the PR discussion thread.

Here's an extract from the PR description.

First of all, there's support for half-holing.

EDIT: It is limited to:

• It is supported on all holes (except bell)
• thumb: it raises by one octave (based open or closed thumb hole note, user selectable)
• L1 - R4: raises by one semitone, but base positions only (all upper holes covered, lower holes open), regardless of thumb status.

The user can activated the half-hole detection for each single supported tonehole. In the "Advanced" settings for half-holing it is possibile to tweak the sensitivity of the detection, hopefully to accomodate different playing (and instrument gripping) styles.

The current hardware finger sensing mechanism doesn't allow for precise half-hole sensing, so a lot of changes had to be made to the debouncing machine. Basically, the transient note filter delay is now dynamic: it adjusts based on the player's gestures, and it extends or reduces the delay consequently. For now, gesture detection is limited to note interval, number of fingers changed and status of half-holes. It can be extended to other types of gesture detection. I removed the previous sensing based on senseDistance, because it is redundant at this point. Being dynamic, the "sluggish" feeling should be reduced a lot, while most of the glitches are more effectively removed.

I added my own EWI Fingering ("Mep's EWI") and the relative fingering PDF chart. Based on this, there a new "Mep's Recorder" that takes advantage of half-holing and has a lot of alternate fingerings (all based on real acoustic recorders). Now the recorder fingering is exactly the same as real recorders. After validation, it could replace the current Soprano recorder fingering (and drop the "Mep's" part ;)

Config Tool I did my best to follow Andrew's style and prefs: of course, @amowry feel free to move things around as you see fit.

• I added a "Half Holes..." button to the "Note trigger and..." box. there you can setup your own preferences. They apply regardless of the selected fingering and are saved in the current mode/instrument (when saved)
• I moved things around in the WARBL2 Settings box (but this was unnecessary)
• I added a new intermediate js function when switching fingering: it is similar to updateCustom and for now it manages the preferences for my new two fingerings. I think we can improve on this and go more towards a "Preset" management for the whole instrument (and not just changing the bare minimum as in updateCustom). I had to add this new function because it triggers events (so the new settings are sent to the WARBL), and that in turn calls updateCustom.
• When switching back to another fingering, the whole half-holing is deactivated by deafult.

A few notes about the source code:

• I switched to fw version 99, which could be the code for dev version. This might cause problems when switching back and forth production fw, so be careful and prepared for a loss of settings! (but you wouldn't flash a dev firmware if you weren't prepared to that, would you? :D ) - You'll see portion of code related to a "baseline auto-calibration", but this seems redundant at this point and can be possibly removed before merging.
• Most of the new stuff is in HalfHole.h and HalfHole.ino. These can be merged respectively in Defines.h and Functions.ino once tha code is validated.
• I left a lot of debugging code. the relative triggers are at the start of Functions.ino. Of course, all of that can be removed or reduced before merging in the main branch.

EDIT: @amowry added a flash.uf2 file of this beta version, just drag&drop to install: https://github.com/amowry/WARBL2/blob/develop/warbl2_firmware/build/adafruit.nrf52.warbl2/flash.uf2

EDIT 2: I fixed a few things and added an auto continuous optical calibration for toneholeCovered

[essej]

Interesting, I will definitely give it a try! I personally usually only use the full legato slide mode because I like all my partial finger holes to be continuously expressive, but expanding the role of the thumb hole for register changes on half holing is something I want to try.

[amowry]

Thanks! I merged it tested it very briefly and it seems great so far. I'm trying to focus most of my time on my "other" job at the moment but I'll continue to test this. I'm sure I'll have some questions. Not being a recorder player, I'll certainly defer to you on the fingering charts. Maybe it would be good to keep both recorder versions in case anyone is familiar with the current one? I haven't looked to see what differences there are other than the half holing.

I updated the flash.uf2 file in the "develop" branch, if anyone wants to test this they can just drag/drop that file.

[essej]

I made some comments on the now already merged PR, but I will continue testing to make sure other things didn't break...

[amowry]

Thanks! I went ahead and merged it because it's a development branch, but if you guys have more changes feel free to make more requests or just commit them. And let me know if there are things I do wrong with the workflow, because I'm still learning :).

[MrMep]

I made some comments on the now already merged PR

Thanks, I saw it. It's true, I don't test much in mode 4 and, frankly, I don't even know exactly what to expect. I made some testing after your post, but I'm still struggling to hear what you describe.

WARBL2 is so much flexible and everyone has her/his playing style and preferred settings: everyone's help in testing & debugging these new features is essential, thank you!

The problem you describe might have to do with holeLatched, that is updated only when committing a new note: maybe we should add something from:

https://github.com/amowry/WARBL2/blob/0a4048b85608b5420647ac3814416b3a8b7d8c92/warbl2_firmware/Functions.ino#L1042-L1049

to around here, where a new position with same note is detected:

https://github.com/amowry/WARBL2/blob/0a4048b85608b5420647ac3814416b3a8b7d8c92/warbl2_firmware/Functions.ino#L895-L900

I don't know if an update of holeLatched is enough, or we should reset PB in any case. Or maybe it is something entirely different. Any help is much appreciated!

[MrMep]

Maybe it would be good to keep both recorder versions i

Maybe we could call the new one "Baroque Recorder".

I haven't looked to see what differences there are other than the half holing.

Besides alternate fingering for trills etc., most of the second octave on the recorder requires a half thumb hole, while a few notes in the middle require an open hole. The current Soprano fingering isn't capable of managing that.

I merged it tested it very briefly and it seems great so far.

Thank you!

But, in HalfHole.h there are a few constants that fine tune the transition filter:

https://github.com/amowry/WARBL2/blob/0a4048b85608b5420647ac3814416b3a8b7d8c92/warbl2_firmware/HalfHole.h#L9-L14

I'm already seeing that those might be tweaked a bit, I'm not fully satisfied with the results for now. Especially the last one might be too big (essentially reducing the effectiveness of the filter). When you all have time, please try different values yourselves, thanks!

[essej]

I made some comments on the now already merged PR

Thanks, I saw it. It's true, I don't test much in mode 4 and, frankly, I don't even know exactly what to expect. I made some testing after your post, but I'm still struggling to hear what you describe.

WARBL2 is so much flexible and everyone has her/his playing style and preferred settings: everyone's help in testing & debugging these new features is essential, thank you!

I don't know if an update of holeLatched is enough, or we should reset PB in any case. Or maybe it is something entirely different. Any help is much appreciated!

I'm working it out... it relates to how getSlide() does the slide calculation only if tf.currentDelay == 0 (which was transitionFilter), and in my old debounce/transient it handled the override for when there should be no filter in a different way. So there is tiny moment of time where your debounce/transient filter is trying to activate, but where it wasn't before. I will figure out a way to still have things work as they did with the slide modes and the new debounce/transient filter.

[amowry]

I can imagine that users would almost immediately ask me if it would be possible to use any hole for half-hole fingering. One thought is that we could have something like the diagram in the vibrato/slide panel where you can select the holes that you want to use. As an example, I could see how a tin whistle player might want to be able to play common accidentals (F natural, Bb, etc.) by half holing and so might want to "turn on" half holes for only a few holes.

I think theoretically the slide features could be made to work with the half holing, i.e. lowering a finger would bend the note down to the half-hole note and then farther down to the closed-hole note. That would probably require some work. The other option would be to disable sliding for that hole. Currently, the slide bends the note down to the half-hole note but then doesn't bend it any farther (there's also the issue @essej mentioned, which I also see but I haven't tracked down).

[MrMep]

will figure out a way to still have things work as they did with the slide modes and the new debounce/transient filter.

Thank you @essej !

ask me if it would be possible to use any hole for half-hole fingering.

The code is easily extendable and as you pointed out, we would just need a better GUI in Config tool. The only problem is that I'm using the higher part of holeCovered to trigger a finger change when half-holing, so we would miss a bit for managing all toneholes, as the following table should show:

15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- H-L2 | H-L3 | H-R1 | H-R2 | H-R3 | H-R4 | H-TH | TH | L1 | L2 | L3 | R1 | R2 | R3 | R4 | Bell Either we switch to a 32 bit variable for holeCovered (and the various derivates), or we leave L1 out. > the slide features could be made to work with the half holing As clearly shown by the problem reported by @essej , I haven't delved into Pb, sliding etc. yet, and for sure I don't understand all the nuances yet. Please help :)

[essej]

The slide features seem mutually-exclusive with the non-thumb half-hole logic from this new feature set. I don't know that it makes sense to combine them in any way!

[amowry]

The slide features seem mutually-exclusive with the non-thumb half-hole logic from this new feature set. I don't know that it makes sense to combine them in any way!

It seems fine to me to just disable slide for the half-hole fingers, if that's what you're suggesting.

[amowry]

The only problem is that I'm using the higher part of holeCovered to trigger a finger change when half-holing,

Would it be possible to use separate variable? I don't want to make more work for you, I'm just trying to anticipate how people would want to use this :).

[MrMep]

Would it be possible to use separate variable?

Either way, it's a mess. I tested a 32bit holeCovered, but that would require revising all bitMasks and in general all accesses to the fingering pattern. Having two separate vars requires changing the state machine and all the aux functions, to read triggers from both variables... And in both cases, we should modify the comm protocol with the config tool to manage 4 bytes instead of two for current fingering.

EDIT: maybe we could use a union?

Does it make musical sense to have half-holing on L1? It's difficult to hold the instrument in that position and, I guess, in most if not all fingerings the immediately upper note is diatonic e should be available with ease. Is there any contrary case?

[MrMep]

A few lines that might need revising:

• in handleCustomPitchBend, I guess conditions like (holeCovered & 0b100000000) == 0 won't work with half-holing (there are several)
• in sendNote a similar case: holeCovered == 0b111111111
• in handleButtons, again

I guess, in all the above cases, we need to mask out the higher bits

[MrMep]

I'm almost ready for a new PR: I switched to a union, so in a way we have separated variables for open/closed and half holes, but a unique variable for finger change triggering. It woks and, incidentally, I might have solved the slide bug @essej : you were right: in PB management holeCovered was modified and that triggered a debounce. I just made a temp variable. https://github.com/amowry/WARBL2/blob/2624f63b04f716a636edf6d2225e2437a49a1b4c/warbl2_firmware/Functions.ino#L1217 I have sovled also the problems I undelined in my previous post.

@amowry I'm still working on the Config Tool, but I'm almost done. The access to holeCovered will be changed, but nothing too complicated.

[amowry]

Thanks!! I'm happy to work on this too, it just might be a while.

[MrMep]

Thanks!! I'm happy to work on this too, it just might be a while.

Don't worry, I started this, I want to see to it until it works :)

[MrMep]

PR #20 should do it. I don't have the tool to generate the uf2 image, @amowry would you take care of that, please?

• Enabled half-holing on all toneholes (except bell)
• holeCovered is now a struct containg both holes (holeCovered) and halfHoles
• Declared a union between the new struct for holes and a 32bit variable for fingering change trigger
• Moved half hole enabled from switches to a dedicated variable (much like vibratoHoles)
• Extended the Config tool protocol to support half -holing on all toneholes
• Extended the Config tool protocol to support the receiving of both the old holeCovered and the new for half-holes
• Updated checkFirmwareVersion for the new variables
• Modified debouncing constants

EDIT Plus:

• Auto optical calibration

• Added " " button action

• Added " " Config tool switch

• Added " " checks to checkFirmwareVersion

• removed auto baseline calibration

• added holeBaseStatus() - contains the previous code of getFingers

• re-organized WARBL2 Settings box in the Config Tool

[amowry]

Fantastic, thanks! I just merged the pull request and uploaded the new UF2.

How does the auto optical calibration work? I haven't looked at that yet. And what are the relative button action and relative Config Tool switch?

[MrMep]

What does the auto optical calibration work?

for each tonehole in getSensors, if a note is on and the hole is closed, it stores the current value. After at least 500ms and a sample count of at least 400, it calculates the average and applies it as toneholeCovered (calibration value). This is not saved, it's just runtime (unless you click and confirm "Save fine calibration").

Apart from bugs, and with the current low baseline values, I'd say explicit calibration should not be so often required, if at all.

what are the relative button action and relative Config Tool switch?

In WARBL2 Settings I added an on/off switch for this new auto-calibration: when disabled, it re-reads the saved values. So, with a new "Toggle auto optical calibration" action, if you want you can turn it on/off.

Ideally, if it is confirmed to work and to improve the playing experience, we could even choose to leave it always on, or at least move into a soon-to-be-added "Advanced settings" :)

[essej]

For me, the value of manual calibration is more importantly for my preference of how I like the holes to respond. Just something to consider….

[MrMep]

Just something to consider….

I see what you mean. As long as it's an option, anyone can set it up as they like.

Please try it out and tell me how it goes: it might need some more refinement, but the goal is to adjust to each player's habit automatically. It that doesn't work for you, I would like to go into detail on why. Thank you!

[amowry]

I've only tested it very briefly, but here are a few comments:

• The half-holing seems good to me so far. I like how you've added the half-hole indicators to the blue "lights"! However, maybe the bell sensor doesn't need that because it's not enabled for half holing?

• The slide feature is still turned on for half holes, but I'll make a note to disable that.

• There seems to be something wrong now with the "normal" autocalibration of the bell sensor-- when you click "auto-calibrate all sensors" or "auto-calibrate bell sensor only", the bell sensor turns blue immediately even though it's not covered. It happens even if the new "auto optical calibration" switch is turned off.

• For me, the new auto calibration seems to make it more difficult than I would like to cover the sensors if I inadvertently press too hard on them, and then it takes a bit of time to move back to the previous calibration. Again, I've only tried it very briefly, though. I'll think about this-- as you know I tend to be very conservative about adding new features that could potentially cause confusion (and potential support issues for me :)). If this becomes an option I think we'd need to rename it, to avoid confusion. My current inclination is to hold off on this for now.

• I realize now that the half-hole UI might make more logical sense if they were moved to the top, similar to how the "Configure custom fingering..." controls work. At some point I can work on cleaning up the Config Tool. I've been thinking it could be less overwhelming for users if all the panels are collapsed by default because the UI has gotten so "big" (?).

• I still haven't figured out why you're not seeing any baseline values on the WARBL you have. If I print out the tonehole values at line 160 in functions.ino (before subtracting the stored baseline values) I get mostly values between 2 and 8 in direct sunlight on all the WARBLs I have here. I suspect it's not enough to interfere with half-holing, though, as that seems to work fine for me in sunlight.

• I've noticed that the old (release) version of the Config Tool on iOS immediately disconnects from the WARBL (with the new firmware) if you change any setting. I'm not sure if the new Config Tool version will do this too-- at some point I'll put it online under another name so I can test it on iOS.

• Downgrading from this version of the firmware to 4.1 makes it so the WARBL will no longer connect to the Config Tool (unless I erase the EEPROM first). Do you know what we would need to do to make it possible to downgrade?

• The Config Tool will need to hide the new options for older firmware versions-- I can do this but I'm noting it here so I don't forget.

[MrMep]

*However, maybe the bell sensor doesn't need that because it's not enabled for half holing?

It's bug! I'll fix it ;)

• The slide feature is still turned on for half holes, but I'll make a note to disable that.

Sorry, but it isn't clear to me yet what to do: do you want to disable vibratoholes when half holing is enabled? And vv.? Should we keep track of the previous values, to restore them?

• There seems to be something wrong now with the "normal" autocalibration of the bell sensor-- when you click "auto-calibrate all sensors" or "auto-calibrate bell sensor only", the bell sensor turns blue immediately even though it's not covered. It happens even if the new "auto optical calibration" switch is turned off.

It must be the same bug as above, sorry

• For me, the new auto calibration seems to make it more difficult than I would like to cover the sensors if I inadvertently press too hard on them, and then it takes a bit of time to move back to the previous calibration. Again, I've only tried it very briefly, though. I'll think about this-- as you know I tend to be very conservative about adding new features that could potentially cause confusion (and potential support issues for me :)). If this becomes an option I think we'd need to rename it, to avoid confusion. My current inclination is to hold off on this for now.

Ok, we could tweak the timing parameters, to make it less responsive, and/or use another type of average (like the auto-regressive one I was using for baseline calibration). Please, do not give up! (Or, at least, let's keep it as a "hidden" feature, if possible ;) I'm loving it :)

• I've been thinking it could be less overwhelming for users if all the panels are collapsed by default because the UI has gotten so "big" (?).

My thought exactly! That's the road I wanted to take with my app. It is also possible to work on css parameters dynamically, and adjust the various boxes according to where the user is in the navigation.

• I still haven't figured out why you're not seeing any baseline values on the WARBL you have. If I print out the tonehole values at line 160 in functions.ino (before subtracting the stored baseline values) I get mostly values between 2 and 8 in direct sunlight on all the WARBLs I have here. I suspect it's not enough to interfere with half-holing, though, as that seems to work fine for me in sunlight.

Yes, that's were I was printing out my values. And my factory baseline calibration values are all at 0 except 1 for thumbhole. I don't know...

• I've noticed that the old (release) version of the Config Tool on iOS immediately disconnects from the WARBL (with the new firmware) if you change any setting. I'm not sure if the new Config Tool version will do this too-- at some point I'll put it online under another name so I can test it on iOS.

It disconnects also with the old Config Tool on desktop, if you keep the bell closed. It might be related to the same bug, I'll have a look at it on next tuesday, I hope.

[amowry]

Okay, thanks! I can work on the slide thing later-- I think we just need to turn off the ability for half-hole enabled holes to "slide" (vibrato can stay turned one). I don't think the actual slide/vibrato setting needs to change, as holes that aren't being used for half-holing should probably still have the ability to slide.

[MrMep]

PR #22

• Fixed bug with bell hole and auto calibration/half holing/config tool disconnections (hopefully)
• Modified Auto-calibration: added a (quasi)-regressive average and slowed it down
• Change "Auto optical calibration" to "Continuous optical calibration" in Config Tool
• Updated flash.uf2 image file

@amowry there's a conflict, I'm afraid I can't merge it this time, sorry.

[amowry]

I'm not sure how to merge it either-- I tried removing the UF2 from develop and that doesn't seem to help. When I try to merge from the command line I get a "not something we can merge" error. Maybe if you remove the UF2 from the pull request?

[MrMep]

Ok, thanks, it done.

How do you create the uf2 file? I used this:

./uf2conv.py -c -f 0xADA52840 -o flash.uf2 warbl2_firmware.ino.hex

Is it the same you use?

EDIT: by the way I think the problem was that I hadn't merged your changes before my PR. I'll try and remember next time.

[amowry]

This is what I use:

.\uf2conv.py warbl2_firmware.ino.hex -c -f 0xADA52840

I assume that's the same(?). It seems to automatically name the file flash.uf2 if I don't enter a name.

[MrMep]

I assume that's the same(?).

I assume too :) I had a few problems before getting it right: the warbl was starting flashing when drag&dropping the file, but then reset before finishing. I hope the file I pushed works: I tested with mine and looked good.

[ithinu]

Just something to consider….

I see what you mean. As long as it's an option, anyone can set it up as they like.

I have some doubts here. Firstly, the term "calibration" typically refers to hardware calibration. An option named "auto calibration" might make people think that Warbl will monitor its own drift and that they can simply turn this option on and forget about it.

In reality, that option adapts to the player's technique. If the technique is poor, Warbl will hide the problems.

I suggest, especially that there are already parts of the code arbitrarily adapted to certain players (like the transient note filter), that similarly to the three Warbl profiles, there be three player profiles with options such as:

Transient note filter threshold: off, auto, custom warning: introduces additional latency Correction of fingering technique: off, auto

To sum up, Warbl seems to be a device that strives to emulate a real whistle, as seen by its traits like the uneven hole distribution. The new "auto" mechanisms seem contrary to that aim, which is not necessarily bad of course, but I'd suggest that they be named accordingly.

[MrMep]

Warbl seems to be a device that strives to emulate a real whistle, [...]. The new "auto" mechanisms seem contrary to that aim,

I certainly agree that the options offered by the Config Tool should go in the direction you suggest, and that, as Andrew already said, we should find a more suitable name. But actually I have a view symmetric to yours.

1. Transient note filter: no acoustic instrument (apart maybe those with very high ranges) has a response time as short as any wind controller (including the WARBL) usually have. The whole idea of the dynamic transient filter is to make it act more like a real instrument (where there's an air column that has to start and stop vibrating) and less like a computer keyboard. Of course it can mask imperfections in finger technique, but most or many of those imperfections would persist on real instruments too, but there they would be inaudible because of physics. There's also another, different, problem: the WARBL is not fully capable of detecting half-holing, so there's a lot of room for false positives and negatives. Part of the new transient filter is there to correct the errors of the instrument, not of the player.

2. Auto (or continuous) optical calibration: no acoustic wind instrument reacts, to my knowledge, to how much pressure you put on the holes/keys, or to dirty fingers, or to variations in ambient light. The WARBL does, and it kind of ruins the illusion that you are playing a real instrument. The ability to do automatically what now you have to explicitly do manually through the Config tool (re-calibrate), in my view would be a great improvement. We are not exactly there yet, but it would make the WARBL more similar to a whistle, not the contrary.

A sort of "user profiling", I concur, might identify which self-adjustment curve is more suitable for each individual. EDIT: For example, if the pressure one applies with her/his fingers (the "grip" and/or "pinching" effect) is NOT consistent, then one would want a more relaxed reaction, otherwise a quicker response could be better for her/him.

If one's technique is poor, there's no filter that could possibile improve that effectively, and that is not the aim of the improvements we are discussing here. (At least, it's not my aim).

[ithinu]

I certainly agree that the options offered by the Config Tool should go in the direction you suggest, and that, as Andrew already said, we should find a more suitable name. But actually I have a view symmetric to yours.

1. Transient note filter: no acoustic instrument (apart maybe those with very high ranges) has a response time as short as any wind controller (including the WARBL) usually have.

Digital instruments have two response times: from pressing a button to producing a note event (let's call it reaction R), and from pressing a key, via an audio synthesizer and possible pedals, then a possible speaker's DSP finally to a sound from the speaker (= latency L).

R is often virtually instant and that's what allows a realistic modelling of a physical instrument by attack A/decay D times set in the synthesizer. Increasing R would require smaller A, up to A being unrealistic. As for transient notes, think of one which produces a very quiet response in a real whistle and in Warbl, thanks to a synthesizer's A/D. With the filter in question, there would only be silence.

Then there is L, which is often excessive and increasing R would only make L worse.

2. Auto (or continuous) optical calibration: no acoustic wind instrument reacts, to my knowledge, to how much pressure you put on the holes/keys, or to dirty fingers, or to variations in ambient light. The WARBL does, and it kind of ruins the illusion that you are playing a real instrument. The ability to do automatically what now you have to explicitly do manually through the Config tool (re-calibrate), in my view would be a great improvement. We are not exactly there yet, but it would make the WARBL more similar to a whistle, not the contrary.

If Warbl reacts differently to pressure, it looks like its response curve is much different to that of an acoustic instrument. There may be two reasons behind that:

• an unrealistic translation of the sensor's value;
• not chamfered toneholes.

I tried to adapt the former, but what you speak about was still there and I suppose that the sharp hole edges are quite a problem behind the unnecessary pressure sensitivity and the light sensitivity. I will chamfer them soon and test it if helped.

If one's technique is poor, there's no filter that could possibile improve that effectively

Yes there is. My technique is poor and I have already increased a threshold of one hole, seeing later that i should rather be more precise. Yet the "calibration" worked as expected even though it was not a good solution.

I would not resort to adaptive solutions being the basic ones until simpler methods have been proven ineffective, because a physical instrument is not inherently adaptive. It may be not obvious to test if such adaptations make the instrument feel unsteady or not.

[amowry]

This issues I mentioned with the bell sensor and the Config Tool disconnecting do seem to be fixed. Thanks! I'll keep playing with the autocalibration-- I haven't had much time yet but it also seems better.

[ithinu]

I modified the light sensor response curve and I no longer need to apply pressure. What I initially took for light sensitivity is also gone, at least if not in daylight. But I do not play an actual whistle, I hardly started to try Warbl. If you feel that it is now more realistic, maybe it is.

By the very definition of raw mode, I will avoid both 'auto' mechanisms anyway. Thanks, Andrew, for the open firmware.

[MrMep]

R is often virtually instant and that's what allows a realistic modelling of a physical instrument by attack A/decay D times set in the synthesizer.

Except that most of WARBL users use some kind of sound-font-type of app where mostly ADSR curves are fixed in the samples. They usually have very low attack and release, because they try to be as responsive as possibile, and that opens the door to any kind of glitch coming from the controller. I'm sorry I must be verbose. If one uses a more sophisticated sound generator, she/he can have raw data coming from the controller and let the app do the "physical" gesture modelling or whatever is required. But there's a catch: a user can live with her/his own fingering flaws, but not with glitches coming from an "imperfection" of the controller. If you turn full debug on with the new transient filter, you'll see that the WARBL is reading every single movement your fingers make. I suppose I have a decent finger technique, but I'm not a machine: in difficult passages, there are slight delays in finger response time (in the order of ms), for each finger involved: without a transient filter, a noteOn message is fired away... On the contrary, no acoustic instrument reacts to that and, in my view, nor should WARBL (except by user choice). The previous filter was a delay on/off type of filter, I tried to make it "smarter". For now it detects intervals, finger changes and half holing, but like I said before it's extensible, and you gave me a couple of ideas:

• detection of mixed movements (fingers going up and down simultaneously)
• range of the notes involved, high/middle/low. The higher, the more responsive it would be.

As for transient notes, think of one which produces a very quiet response in a real whistle and in Warbl, thanks to a synthesizer's A/D. With the filter in question, there would only be silence.

Not if you can tweak the filter mechanism. @amowry I think we could expose all the parameters involved in in the Config Tool, prepare a few "presets", let's say: Transient filter profiles

• None
• Bland
• Medium
• Aggressive
• Custom...

And then with "Custom..." let the player decide exactly what to do, with something similar to:

where you could tweak the "multiplier" for each single component. There is some work involved, but I'm willing to do it, if you agree it would help.

I will chamfer them soon and test it if helped.

I hadn't thought about that, please let us know if it makes any difference!

My technique is poor and I have already increased a threshold of one hole, seeing later that i should rather be more precise. Yet the "calibration" worked as expected even though it was not a good solution.

That's what I was talking about: in my view, WARBL was worsening your technique. If you are lighter or heavier on certain fingers, the instrument should detect that and act accordingly. It's what the existing "Auto calibration" is supposed to do, except that I never get it right when doing it (I suspect because during calibration I don't hold the instrument the same way I do while playing) and I always have to manually tweak each tonehole afterwards. With the new "Continuous" calibration, after a few minutes of playing the WARBL finally reacts as I want it to, then I click "Save fine calibration" and it's done. I've done this a few times already:

1. "old" Auto calibration
2. "Continuous" calibration on. At the beginning the instrument reacts not so well.
3. After a few minutes it's good, then I save it.

a physical instrument is not inherently adaptive

Let's try this way: if you have a poorly built acoustic instrument, there's nothing much you can do (except maybe physically modifying it). For certain aspects, WARBL is like a poorly built acoustic instrument (like any other wind controller), but luckly we can try and correct certain aspects with software. You are focusing on the adaptation-to-user aspect, but in reality we are trying not to hassle the user with limitations from the instrument. In my view, a more definitive solution would be to have contact rings around each hole, so to know for certain when a finger is down or not. but that's for WARBL 3, maybe ;)

@ithinu many thanks for taking the time to test this and report back, I mean it.

This issues I mentioned with the bell sensor and the Config Tool disconnecting do seem to be fixed

Great! Thanks to you!

EDIT: I realize now that I wasn't clear at all why I inserted the "Continuous" calibration into this branch. I am very sorry about that, I wasn't try to hijack this branch for other purposes. Of course, the half-holing mechanism heavily relies on calibration data: an imperfect calibration does have impact on how well half holes are detected. I first tried to auto-calibrate the baseline values, but that didn't turn out to be working. The only other calibration parameter available is toneholeCovered, and that's what the continuous calibration works on. It looks to me that half-holing detection, with "continuous" calibration on (in the latest version), is far more stable then without. Do you have the same impression?

[ithinu]

Transient filter profiles If one uses a more sophisticated sound generator, she/he can have raw data coming from the controller and let the app do the "physical" gesture

That sounds convincing.

For now it detects intervals, finger changes and half holing, but like I said before it's extensible, and you gave me a couple of ideas:

• detection of mixed movements (fingers going up and down simultaneously)

There may be a moment when it is easier to construct functions of frequency and overblow threshold based on physical considerations, rather than adding special cases. The arguments would then be simply the eight hole shadowing levels, eliminating the need for special code for situations like two holes changing simultaneously - every situation would require the same two equations. The fingering charts (which would need to include various cross fingerings and shadowings) would only be used to fit the two functions in question. I do not know the subject, though, and thus I cannot say how difficult it would be to find functions like that. Maybe some literature, combined with the intuition of an experienced player, could help.

[amowry]

Just a few things to add here:

I've chamfered the holes on several WARBLs and if I understand correctly what you're trying to achieve, I think chamfering has the opposite effect: It makes the toneholes respond more to changes in pressure because it makes it easier to push your fingers closer to the sensors. That's the reason I keep the toneholes fairly small and don't normally chamfer them-- they provide more of a "positive" stop for your fingers that way, with less response to pressure.

My preference would be to not have additional controls for the transient filter if possible. My reasoning is that I'm receiving feature requests almost daily now, so I'm feeling that I'll need to be very conservative about allocating new space in the Config Tool. While I realize that the transient filter is necessary for half-holing and I think it's great to have, most (80%) of WARBL users are tin whistle or bagpipe players, and they don't tend to use the transient filter because they see it as a feature that the WARBL is pretty unforgiving in terms of fingering. Acoustic bagpipes are the same way and bagpipers spend a lot of time "fixing" their fingering to avoid crossing noises, so they want to the WARBL to be as realistic as possible in that sense. Even with no filter at all the WARBL is too slow for some bagpipers, so they won't use any feature that removes transients or adds any latency. Obviously that's just one subset of users and again I definitely understand the utility of the transient filter, but that's why I'm feeling that it should be mostly under the hood if possible.

[ithinu]

I've chamfered the holes on several WARBLs and if I understand correctly what you're trying to achieve, I think chamfering has the opposite effect: It makes the toneholes respond more to changes in pressure because it makes it easier to push your fingers closer to the sensors.

Thanks for the insight. From what I tested, Warbl finally seems to be very resistant to external light (I have not tried with flickering sources, though), so chamfering would not help here anyway.

That's the reason I keep the toneholes fairly small and don't normally chamfer them-- they provide more of a "positive" stop for your fingers that way, with less response to pressure.

Maybe this is the reason why almost no one uses chamfering in flutes or whistles - more bounce translates to more speed?

won't use any feature that removes transients or adds any latency

It does not seem surprising. Today even a wired speaker may add latency because it is digital inside.

[MrMep]

I'm receiving feature requests almost daily now

Feel free to share them (here or by email) if you find them interesting: maybe I can be of help in implementing them.

I'll need to be very conservative about allocating new space in the Config Tool

Why don't we take the bull by the horns? Let's redesign the space with the minimum effort possible. Most of the code is already organized in boxes, we would just need a mean of navigation, like a tab list or similar, and a general mechanism that hide/shows/resizes the boxes. Four main advantages come to my mind:

1. More rational/less confounding user experience
2. Responsiveness on mobile screens
3. Plenty of room to add new features

4. According to what is currently shown, we could reduce the quantity of messages sent by WARBL to Config Tool.

   If you want, we can have another branch just dedicated to the config tool and I'll make a proposal there. As you already know, an app is my next priority and I was going to do this in any case.

Obviously that's just one subset of users

I understand. Two things though:

1. Have you tried shortening the sleep cycles? How's the impact on responsiveness? And on battery life? Could that be a price one's willing to pay for having an even faster response by the WARBL ? (BLE timing constraints apart)

2. I hope these new features may attract (new) recorder players. Apart from akai/roland (that are quite different from a recorder), currently there are only three main options for them: e.corder, sylpho and re.corder. The first one is very expensive, sylpho doesn't have half holing, the last one is more like a toy (in my opinion) when it comes to responsiveness. Being a (former) recorder player myself, and having tried for years many of the current and past wind controllers, WARBL is by far the best I have ever used, in terms of playability.

[amowry]

Why don't we take the bull by the horns? Let's redesign the space with the minimum effort possible. Most of the code is already organized in boxes, we would just need a mean of navigation, like a tab list or similar, and a general mechanism that hide/shows/resizes the boxes.

This is definitely something I've been thinking about for years, but unfortunately I don't have any time to work on it and at the moment I'm trying to figure out what should be included in the 4.2 release because I'd like to get the bug fixes in that out fairly soon. At this point it will probably be several months before I'm able to completely test the half-holing, new fingering charts, update all the documentation, etc., so I'm hesitant to make any more changes now. My inclination at the moment is to include just the half-holing and transient filter (preferably with no additional controls) in 4.2. Then after that's released in a matter of months I might be able to think more about the Config Tool without feeling too overwhelmed :).

1. Have you tried shortening the sleep cycles? How's the impact on responsiveness? And on battery life? Could that be a price one's willing to pay for having an even faster response by the WARBL ? (BLE timing constraints apart)

I have experimented and the impact on battery life is significant but (I believe) the impact on responsiveness is negligible because we're really only talking about a millisecond or two at most that could gained (because reading the sensors takes almost a millisecond). Compared to audio latency and BLE connection interval I think it's pretty minimal.

[MrMep]

I might be able to think more about the Config Tool without feeling too overwhelmed :)

I'm sorry I'm being pushy, really. I think I can go on working on the Config tool and the other features I talked to you about, in my fork and in different branches, so that we could have separate PRs when the time comes. Maybe I'll ask you to have a look at what I'm doing, from time to time ;)

Again, anything I could do to help you, just say the word. Do we have something else to change in this branch before merging it?

[amowry]

No worries at all-- you're not being pushy, and I really appreciate your help! A lot of it is just that I'm inexperienced at all this so I worry about making a lot of changes quickly, and I want to make sure I understand all the changes so I can support/debug them later.

I guess I should probably test this branch a bit but more before merging them and I'm away next week, so I'll likely do it after that.

[amowry]

I wonder if the thumb half-holing should have the option to play three octaves consecutively if used in conjunction with the existing "thumb register" setting? I can see how many people might like that as it would be similar to a thumb roller or slider on other wind controllers. Depending on the "invert thumb/bell" setting, gradually removing or lowering the thumb could jump one octave and then two octaves.

Currently it seems possible to use the half hole to jump two octaves but then when the hole is fully covered it jumps back down. I think we discussed this last year and you told me the logic for doing that with recorder, but I wonder if having the behavior described above as an option would be more generalizable for fingering charts that don't otherwise use the thumb?

I'm not sure how that would work in combination with the "invert thumb octave" switch in the half-hole options.

I recall now there are only a few charts (like whistle) that don't use the thumb and therefore allow the "thumb register" setting to be used, but I believe it is used fairly regularly. I should maybe think about whether it should be enabled for custom charts, over-riding the hard-coded thumb functionality.

[MrMep]

I wonder if the thumb half-holing should have the option to play three octaves consecutively

It should already be like that: if not, it's a bug! I've been having 3 1/2 octaves for weeks now, but I tested it mainly with my fingerings.

In my understanding, normally, you would have:

1. first octave, thumb closed
2. second octave, thumb open

In the default settings, half thumb hole should raise 2. by one octave.

In my EWI fingering, the first two octaves are inverted:

• 1st thumb open
• 2nd thumb closed
• 3rd half hole
• 4th "overtones" (kind of)

In fact I need to set the "I Invert thumb octave" option" on to achieve this. My reasoning was not based on recorder, but on trying to avoid open->half passages as much as possibile. At first it was a little weird, and it's acoustically unreasonable, but if you put in the hours required to get acquainted with this configuration, in my opinion it's much more natural for the fingers. (We're changing the laws of physics here! :D )

I'm not sure how that would work in combination with

It is as simple as possibile:

• Invert thumb octave off: half thumb hole raises by 1 octave the note that would correspond to the same position with thumb hole open
• Invert thumb octave on: half thumb hole raises raises by 1 octave the note that would correspond to the same position with thumb hole closed

What note corresponds to a position with thumb hole open/closed remains based on pre-existing settings:

• fingering chart
• register control options
• Invert thumb/bell switch

In simple terms: whatever is your highest octave, half thumb hole should raise it by one octave.

If there are setting combinations that do not achieve this, regardless on the "Invert thumb octave" switch, we need to sort them out.

[MrMep]

gradually removing or lowering the thumb could jump one octave and then two octaves.

for now, this is possibile only if the fingering chart is like this:

• thumb hole closed: 1st octave
• thumb hole open: 3rd octave

and the "Invert thumb octave" to off. To achieve what you say, we should have another switch that overrides what is in the chart. If you think it would be used, we can add it in. It would be another way to break acoustics, I like it ;)

[essej]

gradually removing or lowering the thumb could jump one octave and then two octaves.

for now, this is possibile only if the fingering chart is like this:

• thumb hole closed: 1st octave
• thumb hole open: 3rd octave

and the "Invert thumb octave" to off. To achieve what you say, we should have another switch that overrides what is in the chart. If you think it would be used, we can add it in. It would be another way to break acoustics, I like it ;)

I would try using this… as I am one of those who use the whistle fingering with register thumb hole, and having adjacent octaves on open-half-closed thumb would be nice.

[amowry]

A solution might be:

• If the "thumb register" mode is selected it would automatically override all thumb functionality in the chart. This part is unrelated to half holing but would make that switch more useful because it currently only works with a few charts. Or possibly this override should only apply to custom charts, not the preexisting ones.

• If "thumb register" and thumb half holing are both turned on then the thumb register would raise two octaves instead of one, allowing a three octave range. This way we wouldn't need to add another switch, which I fear might get confusing.

[amowry]

It turned out that it was a bit tricky to turn off the legato slide feature for individual holes, so I pushed a change that disables slide completely if any hole other than the thumb is being used for half holing (the thumb isn't used for slide so there's no conflict there). It doesn't change the pitchbend mode setting in Config Tool, it just doesn't allow slide to occur.

The problem the @essej mentioned with legato slide and the new transient filter is still there, and there's also a problem with the "normal" slide when the transient filter is turned on. The issue gets worse with higher transient filter values. I think there's a timing disconnect between when the pitchbend values reset and when the MIDI note resets. In other words, it seems like the pitchbend is still using unfiltered hole-covered data rather than the transient-filtered data (?).

Edit: To elaborate on this, using the "normal" slide (kPitchBendSlideVibrato), when you gradually lower a finger the pitchbend should drop from 8192 towards 0 and then jump back to 8192 right when the new note is triggered. Currently, an erroneous value of 7680 is triggered before the new note, creating a sudden increase in pitch and a "blip" sound:

226 198 170 142 114 86 58 30 2 7680 << this shouldn't be here 8192

Another edit: I just looked back at the original comment from @essej about this, and it looks like it's the same issue with both versions of slide, i.e. a single erroneous pitchbend value right before the new note is triggered and pitchbend is reset.

[amowry]

Another issue I found with the transient filter involves silent notes (a 0 in a custom chart). If you go from a silent note to another note, the transient filter seems to take noticeably longer to respond. To test this use a custom chart with a "0" position and try moving from that position to an audible note. The delay seems like it's around twice the transient filter setting.

You can also test this with the changes I pushed today by using any fingering chart and covering all holes including the bell sensor. That will trigger a "0" note (silence). Lifting any finger will result in an unusually long delay before playing the appropriate note.