*rc3 preroll music*
Herald: All right, so again, let's introduce the next talk, accessible inputs
for readers, coders and hackers, the talk by David Williams-King about custom off-,
well, not off the shelf, but custom accessibility solutions. He will give you
some demonstrations and that includes his own custom made voice input, an added link
system. Here is David Williams-King
David: Thank you for the introduction. Let's go ahead and get started. So, yeah,
I'm talking about accessibility, particularly accessible input for readers,
coders and hackers. So what do I mean by accessibility? I mean people that have
physical or motor impairments. This could be due to repetitive strain injury, carpal
tunnel, all kinds of medical conditions. If you have this type of thing, you
probably can't use a normal computer keyboard, computer mouse or even a phone
touch screen. However, technology does allow users to interact with these devices
just using different forms of input. And it's really valuable to these people
because, you know, being able to interact with the device provides some agency they
can they can do things on their own and it provides a means of communication with the
outside world. So it's an important problem to look at. And it's what I care
about a lot. Let's talk a bit about me for a moment. I'm a systems security person. I
did a phd in cybersecurity at Columbia. If you're interested in low level software
defenses, you can look that up. And I'm currently the CTO at a startup called
Elpha Secure. I started developing medical issues in around 2014. And as a result of
that, in an ongoing fashion, I can only type a few thousand keystrokes per day.
Roughly fifteen thousand is my maximum. That sounds like a lot, but imagine you're
typing at a hundred words per minute. That's five hundred characters per minute,
which means it takes you 30 minutes to hit fifteen thousand characters. So
essentially I, I can work like the equivalent of a fast programmer for, for
half an hour. And then after that I would be unable to use my hands for anything,
including like preparing food for myself or opening, closing doors and so on. So I
have to be very careful about my hand use and actually have a little program that
you can see on the slide there that measures the keystrokes for me so I can
tell it when I'm going over. So what do I do? Well, I do a lot of pair programming,
for sure. I log into the same machine as other people and we work together. I'm
also a very heavy user of speech recognition and I gave a talk at that
about voice coding with speech recognition at the Hope 11 conference. So you can go
check that out if you're interested. So when I talk about accessible input, I mean
different ways that a human can provide input to a computer. So ergonomic
keyboards are a simple one. Speech recognition, eye tracking or gaze tracking
so you can see where you're looking or where you're pointing your head and
maybe use that to replace a mouse, that's head gestures, I suppose. And there's
always this distinction between bespoke, like custom input mechanisms and somewhat
mainstream ones. So I'll give you some examples. You've probably heard of Stephen
Hawking. He's a very famous professor, and he was actually a bit of an extreme case.
He had, he was diagnosed with ALS when he was 21. So his his physical
ability, abilities degraded over the years because he lived for many decades after
that and he went through many communication mechanisms. Initially his
speech changed so that it was only intelligible to his family and close
friends, but he was still able to speak. And then after that he would work with the
human interpreter and raise his eyebrows to pick various letters. And then and keep
in mind, this is like the 60s or 70s, right? So computers were not really where
they are today. Later he would operate a switch with one hand, just like on off on
off, kind of morse code and select from a bank of words. And that was around 15
words per minute. Eventually, he was unable to move his hand, so a team of
engineers from Intel worked with him and they figured out, they were trying to do
like brain scans and all kinds of stuff. But again, this was like in the eighties,
so there was not not too much they could do. So they basically just created some
custom software to detect muscle movements in his cheek. And he used that with
predictive, predictive words, the same way that a phone, smartphone keyboard will
predict which word you want to say next. Stephen Hawking, used something similar to
that, except instead of swiping on a phone, he was moving his cheek muscles, so
that's obviously a sequence of like highly customized input mechanisms for, for
someone very, very specialized for that person. I also want to talk about someone
else named Professor Sang-Mook Lee, whom I've met. That was me when I had more of a
beard than I do now. He he's a professor at Seoul National University in South
Korea. And he sometimes called like the Korean Stephen Hawking, because he's a big
advocate for people with disabilities. Anyway, what he uses is you can
see a little orange device near his mouth there. It's called a sip and puff mouse
so he can blow into it and suck air through it and also move it around. And
that acts as a mouse cursor on the Android device in front of him. It will move the
cursor around and click when he when he blows air and so on. So that combined
with speech recognition, lets him use mainstream Android hardware. He still has
access to, you know, email apps and like Web Browsers and like Maps and everything
that comes on a normal Android device. So he's way more capable than Stephen
Hawking, as who could, Stephen Hawking could communicate, but just to a person at
a very slow rate. Right. Part of it's due to the nature of his injury. But it's also
a testament to how far the technology has improved. So let's talk a little bit about
what makes good accessibility. I think performance is very important, right? You
want high accuracy. You don't want typos, low latency. I don't want to speak and
then five seconds later have words appear. It's too long, especially if I have to
make corrections. Right. And you want high throughput, which we already talked about.
Oh, I forgot to mention Stephen Hawking had like 15 words per minute. A normal
person speaking is 150. So that's a big difference. (*laughs*) The higher
throughput you can get, the better. And for input accessibility, I think and this
is not scientific. This is just what I've learned from using myself and observing
many of these systems. I think it's important to get completeness, consistency
and customization. For completeness I mean, can I do any action? So Stephen or
Professor Sang-Mook Lee, his, his orange mouth input device, the sip and puff is
quite powerful, but it doesn't let him do every action. For example, for some reason
when he gets an incoming call, the the input doesn't work. So he has to call over
a person physically to tap the accept call button or the reject call button, which is
really annoying. Right. If you don't have completeness, you can't be fully
independent. Consistency, very important as well. The same way we develop motor
memory for muscle memory, for a keyboard. You develop memory for any types of
patterns that you do. But if the thing you say or the thing you do keeps changing in
order to do the same action. That's not good. And finally, customization. So the
learning curve for beginners is important for any accessibility device, but
designing for expert use is almost more important because anyone who uses an
accessibility interface becomes an expert at it. The example I like to give is
screen readers like a blind person using a screen reader on a phone. They will crank
up the speed at which the speech is being produced. And I actually met someone who
made his speech 16 times faster than normal human speech. I could not
understand it at all, I sound like *brbrbrbr*, but he could understand it perfectly. And that's just
because he used it so much that he's become an expert at its use. Let's analyze
ergonomic keyboards just for a moment, because it's fun. You know, they are kind
of like a normal keyboard. They'll have a, you'll have a slow pace when you're
starting to learn them. But once you're good at it, you have very good accuracy,
like instantaneous low latency. Right. You press the key, the computer receives it
immediately and very high throughput. It has high as you are on a regular keyboard.
So they're actually fantastic accessibility devices, right. They're
completely compatible with original keyboards. And if all you need is an
ergonomic keyboard, then you're in luck because it's a very good accessibility
device. I'm going to talk about two things, computers, but also Android
devices, so let's start with Android devices. Yes, the built in voice
recognition and Android is really incredible. So even though the microphones
on the devices aren't great, Google has just collected so much data from so many
different sources that they've built like better than human accuracy for for their
voice recognition. The voice accessibility interface is kind of so so we'll talk
about that in a bit. That's the interface where you can control the Android device
entirely by voice. For other input mechanisms. You could use like a sip and
puff device or you could use physical styluses. That's something that I do a
lot, actually, because for me, my fingers get sore. And if I can hold a stylus in my
hand and kind of not use my fingers, then that's very effective. So and the Elecom
styluses from a Japanese company are the lightest I've found and they don't require
a lot of force. So the ones at the top there are they're like 12 grams and the
one on the bottom is 4.7 grams. And you've got almost no force to use them. So very
nice on the left there you can see the Android speech recognition is built into
the keyboard now. Right. You can just press that and start speaking. It
supports different languages, and it's very accurate, it's very nice. And
actually, when I was working at Google for a bit, I talked to the speech recognition
team as like: Why are you doing on server speech recognition? You should do
it on the devices. But of course, Android devices are, they're all very different
and many of them are not very powerful. So they were having trouble getting
satisfactory speech recognition on the device. So for a long time, there's some
server latency, server lag that you do speech recognition and you wait a bit. And
then sometime this year, I just was using speech recognition and it became so much
faster. I was extremely excited and I looked into it and yeah, they just
switched on my device. At least they switched on the On device speech recognition
model. And so now it's incredibly fast and also incredibly accurate. I'm a huge fan
of it. On the right hand side. We can actually see the voice access interface.
So this is meant to allow you to use a phone entirely by voice. Again, while I
was at Google, I tried the the beta version before it was publicly released
and I was like, this is pretty bad, mostly because it did, it lacked completeness.
There would be things on the screen that would not be selected. So here we see show
labels. And then I can I can say like four, five, six, whatever, to tap on that
thing. But as you can see at the bottom, there was like a Twitter Web app link and
there's no number on it. So if I want to click on that, I'm out of luck. And this
is actually a problem in the design of the accessibility interface that it only, it
doesn't expose the full DOM. It exposes only a subset of it. And so an
accessibility mechanism can't ever see those other things. And furthermore, the
way the Google speech recognition works, they have to reestablish a new connection
every 30 seconds. And if you're in the middle of speaking, it will just throw
away whatever you were saying because it just decided it had to reconnect, which is
really unfortunate. They later released that publicly and then sometime this year
they did the update, which is pretty nice. It now has like a mouse grid, which lets,
which solves a lot of the completeness problems. Like you can, you can use a grid
to narrow down somewhere on the screen and then tap there. But the server issues and
the expert use is still not good, like, if I want to turn it, if I want to do
something with the mouse grid, I have to say "mouse grid on. 6. 5. mouse grid off".
And I can't combine those together. So there's a lot of latency and it's not
really that fun to use, but better than nothing? Absolutely! I just want to really
briefly show you as well that this same feature of like being able to select links
on a screen is available on desktops. This is a plug in for Chrome called Vimium. And
it's very powerful because you can then combine this with keyboards or other input
mechanisms. And this one is complete. It uses the entire DOM and anything you can
click on will be highlighted. So very nice. I just want to give a quick example
of me using some of these systems. So I've been trying to learn Japanese and there's
a couple of highly regarded websites for this, but they're not consistent. When I
use the browser show labels like, you know, the thing to press next page or
something like that or like, you know, I give up or whatever it is, it keeps
changing. So the letters that are being used keep changing. And that's because of
the dynamic way that they're generating the HTML. So not really very useful. What
I do instead is I use a program called Anki and that has very simple shortcuts in
its desktop app. One, two, three, four. So it's nice to use and consistent and it's
syncs with an Android app and then I can use my stylus on the Android device. So it
works pretty well. But even so, as you can see from the chart in the bottom there,
there are many days when I can't use this, even though I would like to, because I've
overused my hands or overused my voice. When I'm using voice recognition all day,
every day, I do tend to lose my voice. And as you can see from the graph, sometimes I
lose it for a week or two at a time. So same thing with any accessibility
interface, you know, you've got to use many different techniques and it's always,
it's never perfect is just the best you can do at that moment. Something else I
like to do is read books. I read a lot of books and I love e-book readers, the
dedicated e-ink displays. You can read them in sunlight, they last forever, battery
wise. Unfortunately, it's hard to add other input mechanisms to them. They don't have
microphones or other sensors and you can't really install custom software on them.
But for Android based devices and there are also like e-book reading apps for
Android devices, they have everything you can install custom software and they have
microphones and many other sensors. So I made two apps that allow you to read
e-books with an e-book reader. The first one is Voice Next Page. It's based on one
of my speech recognition engines called Silvius, and it does do server based
recognition. So you have to capture all the audio, use 300 kilobits a second to
send it to the server and recognize things like next page, previous page. However, it
doesn't cut out every 30 seconds. It keeps going. So that's that's one win for it I
guess. And it is published in the Play store. Huge thanks to Sarah Leventhal, who
did a lot of the implementation. Very complicated to make an accessibility app
on Android. But we persevered and it works quite nicely. So I'm going to actually
show you an example of voice next page. This over here is my phone on the left
hand side just captured so that you guys can see it. So here's the Voice Next Page.
And basically the connection is green. I can do, the server is up and running and
so on. I just press start and then I'll switch to an Android reading app and say,
next page, previous page. I won't speak otherwise because it will chapel
everything I'm saying.
Next Page
Previous Page
Center
Foreground
Stop listening
So that's a demo of The Voice Next Page, and it's
extremely helpful. I built it a couple of years ago along with Sarah, and I use it a
lot. So, yeah, you can go ahead and download it if you guys wanna try it out.
And the other one is called Blink Next Page. So the idea for this, I got this
idea from a research paper this year that was studying eyelid gestures. I didn't use
any of their code, but it's a great idea. So the way this works is you detect blinks
by using the Android camera and then you can trigger an action like turning pages
in an e-book reader. This actually doesn't need any networking. It's able to use the
on device face recognition models from Google, and it is still under development.
So it's not on the play store yet, but it is working. And, you know, please contact
me if you want to try it. So just give me one moment to set that demo up here. So
I'm going to use... The main problem with this current implementation is that it
uses two devices. So that was easier to implement. And I use two devices anyway.
But obviously I want a one device version if I'm actually going to use it for
anything. So here's how this works. This device I point at me, at my eyes, the
other device I put wherever it's convenient to read, ups sorry, and if I blink
my eyes, the phone will buzz once it detects that I blink my eyes and it will
turn the page automatically on the other Android device. Now I have to blink both
my eyes for half a second. If I want to go backwards, I can blink just my left eye.
And if I want to go forwards like quickly, I can blink my right eye and hold it. (*background buzzing*)
Anyway, it does have some false positives. That's why like you can go backwards in
case it detects that you've accidentally flipped the page. And lighting is also
very important. Like if I have a light behind me, then this is not going to be
able to identify whether my eyes are open or closed properly. So it has some
limitations, but very simple to use. So I'm a big fan. OK, so that's enough about
Android devices, let's talk very briefly about desktop computers. So if you're
going to use a desktop computer, of course, try using that show labels plugin
in a browser. For native apps you can try Dragon NaturallySpeaking, which is fine if
you're just like using basic things. But if you're trying to do complicated things,
you should definitely use a voice coding system. You could also consider using eye
tracking to replace a mouse. I personally, I don't use that. I find it hurts my eyes,
but I do use a trackball with very little force and a wacom tablet. Some people will
even scroll up and down by humming, for example, but I don't have that setup.
There's a bunch of nice talks out there on voice coding. The top left is Tavis Rudds
talk from many years ago that got many of us interested. Emily Shea gave a talk
there about best practices for voice coding. And then I gave a talk a couple of
years ago at the Hope 11 conference, which you can also check out. It's mostly out of
date by now, but it's still interesting. So there are a lot of voice coding
systems, the sort of grandfather of them all is Dragonfly. It's become a grammar
standard. Caster is if you're willing to memorize lots of unusual words, you can
become much better, much faster than I currently am at voice coding. aenea is how
you originally used Dragon to work on a Linux machine, for example, because Dragon
only runs on Windows. Talon is a closed source program, which is, but it's very
powerful. Has a big user base, especially for Mac OS. There are ports now. And Talon
used to use Dragon, but it's now using a speech system from Facebook. Silvius is
the system that I created, the models are not very accurate, but it's a nice
architecture where there's client- server, so it makes it easy to build things like
the voice next page. So Voice next page was using Silvius. And then the the most
recent one I think on this list is kaldi- active-grammar, which is extremely
powerful and extremely customizable. And it's also open source. It works on all
platforms. So I really highly recommend that. So let's talk a bit more about
kaldi-active-grammar. But first, for voice coding, I've already mentioned, you have
to be careful how you use your voice right. Breathe from your belly. Don't
tighten your muscles and breathe from your chest. Try to speak normally. And I'm not
particularly good at this. Like you'll hear me when I'm speaking commands that my
inflection changes. So I do tend to overuse my voice, but you just have to be
conscious of that. The microphone hardware does matter. I do recommend like a blue
yeti on a microphone arm that you can pull and put close to your face like this. I
will use this one for my speaking demo and. Yeah. And the other thing is your
grammar is fully customizable. So if you keep saying a word and the system doesn't
recognize it, just change it to another word. And it's complete in the sense you
can type any key on the keyboard. And the most important thing for expert use or
customizability is that you can do chaining. So with the voice coding system,
you can say multiple commands at once. If there's, and it's a huge time saving,
you'll see what I mean when I give a quick demo. When I do voice coding, I'm a very
heavy vim and tmux user. You know, there have been I've worked with many people
before, so I have some cheat sheet information there. So if you're
interested, you can go check that out. But yeah, let's just do a quick demo of voice
coding here. "Turn this mic on". "Desk left two". "Control delta", "open new terminal".
"Charlie delta space slash tango mike papa enter". "Command vim". "Hotel hotel point
charlie papa papa, enter". "India , hash word include space langel", "india oscar word
stream rangel, enter, enter", "india noi tango space word mean", "no mike arch india
noi space len ren space lace enter enter race up tab word print fox scratch nope code
standard charlie oscar uniform tango space langel langel space quote. Sentence hello,
voice coding bang, scratch six delta india noi golf, bang, backslash, noi quote
semicolon act sky fox mike romeo noi oscar word return space number zero semicolon
act vim save and quit. Golf plus plus space hotel hotel tab minus oscar space
hotel hotel enter. Point slash hotel hotel enter. Desk right. So that's just a quick
example of voice coding, you can use it to write any programing language, you can use
it to control anything on your desktop. It's very powerful. It has a bit of a
learning curve, but it's very powerful. So the creator of kaldi-active-grammar is
also named David. I'm named David, but just a coincidence. And he says of kaldi-
active-grammar, that I haven't typed with the keyboard in many years and kaldi-
active-grammar is bootstrapped in that I have been developing it entirely using the
previous versions of it. So, David has a medical condition that means he has very
low dexterity, so it's hard for him to use a keyboard. And yet he basically got
kaldi-active-grammar working through the skin of his teeth or something and then
continues to develop it using it. And yeah, I'm a huge fan of the project. I
haven't contributed much, but I did give some of the hardware resources like GPU
and CPU compute resources to allow training to happen. But I would also like
to show you a video of David using kaldi- active-grammar, just, so you can see it as
well. So, the other thing about David is, that he has a speech impediment or a
speech, I don't know, an accent or whatever. So it's difficult to, for a
normal speech recognition system, to understand him. And you might have trouble
understanding him here. But you can see in the lower right, what the speech system
understands what he's saying. Oh, I realized, that I do need to switch
something in OBS, so that you guys can hear it. Sorry. There you go.
*(Other) David using kaldi-active-grammar system* (not understandable)
Here, you get the idea and hopefully, you
guys were able to hear that. If not, you can also find this on the website that I'm
going to show you at the end. One other thing, I want to show you about this is,
David has actually set up this humming to scroll, which I think is pretty cool. Of
course, I've gone and turned off the OBS there. But he's just doing *hmmm* and it's
understanding that and scrolling down. So, something that I'm able to do with my
trackball, but he's using his voice for, so pretty cool. So I'm almost done here.
In summary, good input accessibility means you need completeness, consistency and
customization. You need to be able to do any action that you could do with the
other input mechanisms. And doing the same input should have the same action. And
remember, your users will become experts, so the system needs to be designed for
that. For e-book reading: Yes, I'm trying to allow anyone to read, even if they're
experiencing some severe physical or motor impairment, because I think that gives you
a lot of power to be able to turn the pages and read your favorite books. And
for speech recognition, yeah, Android speech recognition is very good. Silvius
accuracy is not so good, but it's easy to use quickly for experimentation and to
make other types of things like Voice Next Page. And please do check out kaldi-
active-grammar if you have some serious need for voice recognition. Lastly, I put
all of this onto a website, voxhub.io, so you can see Voice Next Page, Blink Next
Page, kaldi-active-grammar and so on, just instructions for how to use it and how to
set it up. So please do check that out. And tons of acknowledgments, lots of
people that have helped me along the way, but I want to especially call out
Professor Sang-Mook Lee, who actually invited me to Korea a couple of times to
give talks - a big inspiration. And of course, David Zurow, who has actually been
able to bootstrap into a fully voice coding environment. So that's all I have
for today. Thank you very much.
Herald: Alright, I suppose I'm back on the air, so let me see. I want to remind
everyone before we go into the Q&A that you can ask your questions for this talk
on IRC, the link is under the video, or you can use Twitter or the Fediverse with
the hashtag #rc3two. Again, I'll hold it up here, "rc3two".
Thanks for your talk, David. That was really interesting. Thanks for talk,
David. I, yeah, I think we have a couple of questions from the Signal Angels.
Before that, I just wanted to say I've recently spent some time playing with a
like the VoiceOver system in iOS and that can now actually tell you what is on a
photo, which is kind of amazing. Oh, by the way, I can't hear you here on on the
Mumble. David: Yeah. Sorry, I wasn't saying
anything. Yeah, no, it's so I focused mostly on input accessability, right?
Which is like how do you get data to the computer. But there's been huge
improvements in the other way around as well, right? The computer doing VoiceOver
things. Herald: So we have about let's see,
five-six minutes left at least for Q&A. We have a question by Toby++, he asks: "Your
next page application looks cool. Do you have statistics of how many people use it
or found it on the App Store?" David: Not very many. The Voice Next Page
was advertised only so far as a little academic poster. So I've gotten a few
people to use it. But I run eight concurrent workers and we've never hit
more than that. (*laughs*) So not super popular, but I do hope that some people will see it
because of this talk and go and check out. Herald: That's cool. Next question. How
error prone are the speech recognition systems at all? E.g., can you do coding
while doing workouts? David: So one thing about speech
recognition is very sensitive to the microphone, so when you're doing it
*Technical malfunction. We'll be back soon.*
David (cont.): Any mistakes, right?
That's the thing about having low latency, you just say something and you watch it
and you make sure that it was what you wanted to say. I don't know exactly how
many words per minute I can say with voice coding, but I can say it much faster than
regular speech. So I'd say at least like 200, maybe 300 words per minute.
So it's actually a very high bandwidth mechanism.
Herald: That's really awesome. A question from peppyjndivos: "Any advice for software
authors to make their stuff more accessible?"
David: There are good web accessibility guidelines. So if you're just making a
website or something, I would definitely follow those. They tend to be focused more
on people that are blind because that is, you know, it's more of an obvious fail.
like they just can't interact at all with your website. But things like, you know,
if Duolingo, for example, had used the same, like, the same accessibility access
tag on their, like, next button, then they would always be the same letter for me and
I wouldn't have to be like Fox-Charlie , Fox-Delta, Fox-something - changes all the
time. So I think consistency is very important. And integrating with any
existing accessibility APIs is also a very important - Web APIs, Android APIs and so
on, because, you know, we can't make every program out there like voice compatible.
We just have to meet in the middle where they interact at the keyboard layer or the
accessibility layer. Herald: Awesome. AmericN has a question,
wonders if these systems use similar approaches like stenography with mnemonics
or if there's any projects working having that in mind.
David: A very good question. So, the first thing everyone uses is the NATO phonetic
alphabet to spell letters, for example, Alpha. Bravo, Charlie. Some people then
will substitute letters for things that are too long, like November. I use noi.
Sometimes the speech system doesn't understand you. Whenever I said Alpha,
Dragon was like, oh, you're saying "offer". So I changed it. It's Arch for
me, Arch, Brav, Char. So, and also most of these grammars are in a common grammar
format. They are written in Python and they're compatible with Dragonfly. So you
can grab a grammar for, I don't know, for Aenea and get it to work with kaldi-
active-grammar with very little effort. I actually have a grammar that works on both
Aenea and kaldi-active-grammar, and that's what I use. So there's a bit of lingua
franca, I guess, you can kind of guess what other people are using. But at the
same time there's a lot of customization, you know, because people change words,
they add their own commands, they change words based on what the speech system
understands. Herald: Alright, LEB asks, is there an online
community you can propose for accessibility technologies?
David: There's an amazing forum for anything related to voice coding. All the
developers of new voice coding software are there. Sorry, I just need to drink. So
it's a really fantastic resource. I do link to it from voxhub.io. I believe it's
at the bottom of the kaldi-active-grammar page. So you can definitely check that
out. For general accessibility, I don't know, I could recommend the accessibility
mailing list at Google, but that's only if you work at Google. Other than that, yeah,
I think it depends on your community, right? I think if you're looking for web
accessibility, you could go for some Mozilla mailing list and so on. If you're
looking for desktop accessibility, then maybe you could go find some stuff about
the Windows Speech API. *unintelligible* Herald: One last question from Joe Neilson.
Could there be legal issues if you make an e-book into audio? I'm not sure what that
refers to. David: Yeah. So if you are like doing, if
you're using a screen reader and you're like, you try to get it to read out the
contents of an e-book, right? So most, most of the time there are fair use
exceptions for copyright law, even in the US, and making a copy yourself for
personal purposes so that you can access it is usually considered fair use. If you
were trying to commercialize it or make money off of that or like, I don't know,
you're a famous streamer and all you do is highlight text and have it read it out,
then maybe, but I would say that definitely falls under fair use.
Herald: Alright. So I guess that's it for the talk. I think we're hitting the timing
mark really well. Thank you so much, David, for that. That was really, really
interesting. I learned a lot and thanks everyone for watching and stay on. I think
there might be some news coming up. Thanks and everyone.
*rc3 postroll music*
Subtitles created by c3subtitles.de in the year 2020. Join, and help us!