Welcome to this very last slot here today. My name is Sascha Hauer. I work for Pangotronics which is a small company in Germany as a kernel developer and Well, yes as a bootloader developer For today Mostly have a simple mission mission and it's only one. I Want to tell you about bootloader specification, which I think we need And Because that's probably not enough for this slot. I'll tell you a bit about barebox infrastructure and device trees Multi-image support and some additional goodies so Why do we need bootloader specification right now? We have the situation on at least on arm that Kernel and the root file system were quite good together, but there's a disconnect between the kernel and the bootloader because Usually with U-boot and barebox is it's the same. We usually do scripting as Scripting to find our kernel and With this it's really difficult to Get a consistent setup between different boards Basically the scripts are there. They do something. They usually find a kernel and start it But this looks completely different across different boards so Let me let us have a look at the different distributions Right now here for example Ubuntu. It doesn't really support arm It supports the I mix 53 quick start board. It's supports It says omap 4 but if you look have a closer look it says omap folk panda board omap 3 No, it's only the Beagle board and a touchy by AC hundred the this list isn't complete there are other boards Which are supported and Sometimes only a single version is supported and the next Ubuntu version Supports another set of boards similar with Davion they support some Selected socks like the Marvel Kirkwood as a very popular one Fedora it has a different set of boards. Hey, it supports the Beagle board and the panda board but It all is the same. There is no General on board support, I mean it's always possible to to somehow install Your distribution on the board Basically, you can get a root file system and You're on your own. It's always possible to start it somehow and if you look around the internet it there are How-to's for most Distribution board combinations you will always find a how-to, but I said there's no general support Instead only support for certain arm-based boards For it. This is not only the fault of the boot loader. There are some other things missing but For sure the boot loader plays and plays a good role. So That's the situation we currently have and yeah, looks like this old Microsoft commercial For those not native German speakers an open operating system doesn't only have advantages, so I Think we have to sort that out So let's create a way to independently Install a kernel on a board There's another problem Generally with your boot or barebox. You can only have a single corner installed and As usual there are ways to get around this but they are not board agnostic Images yeah, you can create images but they usually for a single board and All this Makes kernel updates risky because the Distributions normally Make certain assumptions on the board and which boot loader is on the board and where the boot loader searches for its kernel so yeah, you have to know which board and You have and yes, this all is a risky process when you Be there without a corner So instead of having this which requires an Arrow between each combination of distribution and Board let's do something like that where We simply put a well-defined way how to start our kernel between the boards and the distributions and That's what the boot loader spec says about this it's created by Kai sievers and Harald Hoya Leonard potmuring was also involved. It's on free desktop org the specification And it says currently there's little cooperation between multiple distributions in dual boat or triple Multi-boot setups and we'd like to improve this situation by getting everybody to commit to a single boot configuration Format that is based on drop-in files. That's robust simple works without rewriting configuration files And is free of namespace clashes note. This is for x86 but Why shouldn't we use it for arm as well and That was what I implemented for Bear books and It's really simple like that the specification only specifies a way to Find the boot partition on a certain device and so each boot partition each device each SD card or use B stick or whatever you have Has a single boot partition this is shared across different distributions which are installed on this device and In this boot partition, there is a directory named loader entries and it contains a single text file per entry And in this boot partition, there is a Sub-directory with a machine ID. It contains the kernel the init ID Device tree files or whatever else is needed to start and Next we have a single There was another slide Here's how to find this boot partition on the device on devices with Mbr with a dust partition table. It's simple. It's simply the a petition with a type Zero X ER EA Once you find that, you know, it should be used as boot partition The boot flag is ignored No, it's just like 0x80 is I think EXT2 and C is VFET for Windows On GPT disks, it's simply the petition with this GUID here, which I'm not going to read On UEFI systems Alternatively the ESP partition can be used And this partition is shared across all installations on the device What I have next is a Single entry which describes a one kernel to boot and It looks as simple as that We have a Single config file, which has a title. This is shown to the user. So He knows what to select, what he will booting. We have a version field Basically It could be used to always start the newest entry or something like that. Right now. It's only informational Each board has a machine ID. It's basically the same as Find under The options field is simply passed to the kernel It's better here in this case. It's it only specifies where to find the root file system But you could also specify Yeah, the user the usual stuff where which console to use and The next entry simply specify where you find the kernel the init ID Or and in this case Device tree the important thing about this is These paths are in the very same petition as the entry. So there's no No way it's not in the specification to to find some other petition or even some other device so this Bootloader specification is simply about the single single device a single SD card or a single USB stick and Basically this is about it Yeah, right good question the question was whether it's fat formatted it's Recommended To format to use fat file system. You could also use ext2 or 3 or 4 This is also mentioned in the specification, but yeah in theory you could use whatever you want Whatever your bootloader and the kernel can read Yeah, so you you have to really choose something your bootloader can read and it has certain advantages to use something Your bootloader can even write Because then it could manipulate the petition the entries Pardon, could you speak up? Yeah, he asked whether this is like rap and Indeed there are certain parallels because the grub has a manual list and It specifies the same things but the Main difference is that grub specifies a single file for all and If you have multiple distributions on the same device, it's not clear which distribution should write this single entry Where as this one is the bootloader spec is based on multiple entries So and this is said to be shared between distributions So each distribution just creates a single entry and it won't conflict with the other entries That's a big advantage of this behavior Yeah 6 a 9 8 is just a machine ID. It's a placeholder. It's just a Hash which is used which should be unique for each distribution. It's normally randomly generated during installation of a distribution and The question is It tells him which the the 6 a 9 8 tells which machine it is it's It can be used to identify it but It a set it's randomly generated during installation of the machine. So if you The bootloader simply reads the bootloader entries directory and parses all config files and The 6 a 9 8 is only a way to to come up with a unique directory where the files for the certain Distribution can be installed. You see Down there the linux the init ID and device tree files are also installed in this directory and So each distribution can have Its own directory where things are installed without conflicting with others Yeah, that that's right once you install Yeah, yeah, if you No, no, no Alright But you're right if you install Fedora on the same machine twice you get Different machine IDs each time Yeah, it's I haven't thought it out this name. It's basically Fedora and PTX just based and I think other distributions do it as well have this file named ETC machine ID and Yeah, the semantics is Like like I described There was another question the question was if Machine if a kernel can boot on multiple machines How does this does this match with the single device tree that is here specified because different machines require different device trees and with The entry here will boot on a single machine only that's right A gen if you have a generic Image that shall boot on multiple machines would just skip this device tree entry and Rely on the device tree firmware would provide you once again, please Where does the device tree come from either you with barebox you can Nowadays at least on IMX Tegra It probes itself from the device tree it has a device tree compiled in which it which barebox uses to probe itself and It just you it's used to to pass this to the kernel or you can store Another device tree in the environment could we Do this later because I have some slides in this which also Mention this topic. All right We have a copy of the device tree source files In the barebox source code these are compiled into barebox during compilation That's one possibility These device trees are used to probe barebox itself and the very same device tree is then passed to the kernel That's one possibility the other possibility is that Barebox itself might not use the device tree Because the architecture doesn't support device tree yet In this case you would store and a Device tree in the environment wherever this may come from you have to supply it by you can download it by Networking or Whatever you have to supply it manually Or Different Solution you could download a generic SD card image for your distribution which Maybe Has this An entry like this without a device tree and you manipulate the entry to actually supply it Device tree the device through you want to have for your board But then of course you won't have a generic image anymore There can be multiple of these entries You can Specify different device trees with each entry. All right The bootloader does not know which one to pick. Yeah, let me just continue the Because this is covered later Yeah along Along with this Here's a screenshot from my Africa and make smart smart book Along with this bootloader spec. There's this kernel install script And it can be used to to manipulate entries. It can be used to create entries or To make entries the default So what is here is kernel install minus a for add an entry and we have kernel version 3.12 Rc6 and specify a way to pass to the kernel image to install and this is enough to actually install a new kernel entry and There are similar commands to to remove entries and Or to change entries This tool here is Running on the system on the distribution that should It's in running a native mode But you could also run the same tool on a host for example, so you could So maybe you have messed up your system or Want to create a new system you messed it up you Pull the SD card put it in your laptop or wherever and can use the very same Kernel install script to to fix it again So this is a similar kernel install script is part of system D already and That's the next thing Bootloader spec is already implemented By Gummi boot, which is a UEFI shim boot manager implemented by Kai Severs and Herald Hoya they Actually had the problem that even the UEFI boot mechanisms were not enough for them and that was that was Their motivation to to write the gummy boot and this whole bootloader spec if you Like grub more then there's Already a patch for this So grub can with a patch read this bootloader specification as well and that's about it Yeah, you should implement it for your bootloader because It makes SD cards and stuff like that introspectable and even if your favorite bootloader is not barebox You could use it and then we could Exchange images between different boards Already set most of these And this answers your question a bit What's missing right now in the bootloader spec? There's no way To specify Which entry should be the default? It's not part of the specification So right now it only gives you a way to Give the bootloader the information Which entries are existing? but you would have to implement a bootloader specific way to To actually choose one of them that In barebox you have the possibility to either it reads a default entry. There's the file named default So it picks this entry and Just starts it There's another Entry it's named once and If it finds a file named once it This file should contain a config file or a path to a config file and the bootloader would Erase that file and start that one so that then this once entry is Executed actually only once and then next time the old entry is executed again So it's basically a way to specify To test a new entry What is also missing is There's no Nor on end device support yet because the Specification is coming from the x86 area and they simply don't have these devices. They're not interested in it so maybe We should at some point at this but SSD cards and emmc cards getting more and more and No, no, no, no nant devices are becoming much more seldom This is Not on the top of the priority list. Yeah, Paul so Yeah, so Pavel asks What's the difference? The difference is On non-nant devices you can do UBFS Which most people do or jffs to or whatever you like and Put the same Specification on it. That's no problem. You can do that The problem is only that With SD cards and emmc cards you have the partition table on the device itself and Can look what you have and look for the slash boot partition with UBI FS or MTD in general the Partition information is outside of the device and has to prove be provided from somewhere else So as long as you skip that step and say, yeah, I'm using this petition as my boot device The same will work with UBF UBI FS as well But I'm I currently hesitate to say we do it like that Because I'm really happy to actually implement a specification that is that someone else is written So we don't do our own stuff, but Yeah, there are at least two of us Who do the same stuff? Which is actually good Is there more for bootloader specification mark Mark asks whether I know the fit image which is used in UBOOT and how does it compare on the I know fit image. I haven't tried it, but I know it. It's Correct me if I'm wrong. I think it's basically a device tree snippet which contains Several informational stuff Yeah Of course it does because Yeah, the fit image Provides a way to start a kernel, but how do you find this image? It's not specified No, this is exactly what the bootloader spec describes. It describes a way to introspect an SD card It exactly describes where on an SD card I find a kernel But On with fit image, there's a way to find a fit Once I found the fit image I Know what to do, but it's not specified how to find this image in the first place Yeah So the question is basically well, why don't we reuse the grub configuration that's already there And I think I answered that already the grub specification has One big blob file Which must be managed by a single Distribution So once it's the same on your PC once you have Fedora and Zuse installed on the same machine You still can only have one grub installed and either you use Fedora to to install the grub or you use The the other distribution to install grub because there can be only So you're saying that it's possible to use to boot up Fedora and How's it called on grub? I think it's grub install. Is it that? I only know that for example on Debian I do up get install new kernel and this kernel will be installed and it usually assumes that The the grub configuration is controlled completely by the system. I'm currently running It won't find any other Entries that are there You start by doing nothing They say you need to install Fedora You can just divide it by five countries and put the machine in the Fedora the front Yeah, I'm specified by grub Now you have the specification how to do this. That's the good enough to explain. That's all about it. It's a bit Simplified from the grub copy Because you don't need all those things that are possible in grub like finding other devices because we're defining we have a single boot rotation and yeah, it just simplifies things a bit and makes it more robust And what I can say is the patch for grub 2. It's a hundred lines or something like that so it's not really invasive and And If you only take the things that are actually Needed then what's different? I mean If you strip away all the rest I don't think the configuration we have now The And then compile one Or it won't touch it other possibility And basically we're mostly talking about embedded devices or Devices that are not so embedded anymore because they're arm laptops now and we don't have grub there so Maybe that would be different if grub would exist on arm as well. All right Don't have that much time left so I tell you something about Bearbox infrastructure It's not much and we're more in the commercial corner now As mentioned before We Support device tree on certain different levels on device and bearbox the IMX Devices can basically be completely probed from the device tree. So it's very simple nowadays to make a new board pod just write a device tree and If you're lucky, of course, you're not always lucky but if you're lucky your board already comes up with a new device tree and You can use this very same device tree and pass it to the kernel and this will start as well. I Often I already made the experience sometimes that Once I've done my bearbox port and that's written a device tree the corner already comes up and That's quite amazing and the same works with the taegra To a certain extent because taegra is not so good Supported in bearbox and with the sock FPGA stuff, of course If you use the same device tree for the kernel for the bootloader, then you use for the kernel it this requires some stability and We've discussed very much about this this week some people say the device tree should be Just unstable just change every kernel version and I was really quite against it and Because I as a bootloader Montana want to use the device tree for the kernel and for the bootloader So hopefully we came up with it not with a solution But we agreed on that we do not needlessly Change the device tree bindings Because it causes causes pain But Nevertheless, they will change He that would be one possibility to flesh a new bootloader with a new device tree, but Yeah, nowadays deep-breaking devices is Possible you don't have to have a JTEC to rebrick unbreak devices, but There's another way you can Simply update the device tree This would be Yeah, this is currently something that Also lacks an API between the bootloader and the kernel because normally you want to start a kernel and you have Want to have a unified way to Update your device tree, but this doesn't exist yet. Nevertheless, you can use bootloader spec to update To add this device tree thingy and Add a new device tree. So I basically think that it should be possible to To Let the device tree be so stable that it it's at least enough to bring up a kernel Which is then able to install a newer device tree which enables all features of your hardware Another thing that we gained recently is the multi-image support Which is very handy because you can use the same configuration to build from multiple boards it basically means that we have less variance to compile and I can just compile and Pick up the one of the images below there and Yeah Just choose the image that matches my board. I Have on the desk It's really handy because we have Also have better compile coverage With less effort Currently this is limited to a few architectures, but hopefully They will become more over time What we also gained is a detect mechanism. We used to have different USB Detect mechanisms, so you would have to type USB to detect all USB devices or with MMC. It was a different command and now we can simply call detect unified for all devices and It would also be possible to do a detect minus a which would simply detect all devices So it's really handy to do this and to see how my system is made up similar we have Mount minus a which would detect all devices and then mount all partitions that we find This is again on my if you can make smart book and to see in the last lines Oh, it found the MMC card and then found the fat file system on this card And it would just mount it to a known path It's really nice Yeah so on the miscellan on the misc side we have generally postic style programming API and So you would have to call open close read write just just the regular stuff. Most people know from user space already Okay config is used for easy configuration. So you can just enable disable features and Of course, we have the regular file commands. You already know from the shell Magic where Va is a nice stuff because we sometimes have the need for variables with a special meaning and It's not nice to Use this variable and just hope that This variable is interpreted in this special version of the bootloader So we have the command magic while that's which is only a informational command Which shows you which magic variables are available along with a description of this Variable Yeah, you have mount points devices probably know that by now get opt is Nice stuff to to make positional arguments unnecessary So you there's an easy way to extend commands, but with new options and probably lots of more stuff as well and Yeah, that was it from my side Are there any questions? No question Actually Actually I was asked Who who who was this guy who wrote Linux device drivers Know the the Italian guy Rubini he asked me whether he could ask one of his students to students to make barebox a real operating system so far he hasn't started but Maybe next year, I don't know yeah, that's Yeah, this often comes the comparison to an operating system and It's yeah, why not it it must I mean all this must be small enough to to Fit into the device, but as of now, I don't think it's even bigger than you would is from binary size The question the question is whether I can boot the same image on different boards and Basically the with a multi image support. There's a one image embedded which Could be started on all of these boards, but you have to to pick one of them Which has a single device tree to actually make that bootable so if you in theory if you have a Way to detect on which board you're on There's nothing preventing you to to start on multiple boards. Oh I don't think there's infrastructure missing To do this although it's not explicitly there there. I don't think there's anything missing There's nothing that prevents you from doing so it wouldn't be much code actually And then choose the correct Yeah So I think we're out of time now so Not much much left to say except thank you very much for listening


Planet Earth is blue. Over 70% of its surface is covered by water. From space it does indeed look blue. Close up, the reality is very different. The pollution, rubbish and waste we create at sea and on land ends up on our shores and in our oceans. We're destroying a precious resource one we depend on so much for food, work and play. Marine pollution has many victims. Millions of people depend on the fishing industry for their income and food. If contamination in the sea reduces fish stocks there's less to sell and less to eat. The pollutants in the oceans absorbed by plankton and fish could eventually make their way to the top of the food chain. That's us. Decades of development and growth may have improved our quality of life but we've been careless with the byproducts of this growth. We need to understand more about the impact of pollution to be able to manage it better and prevent it. This is where the International Atomic Energy Agency the IAA plays a key role. At the agency's laboratories in Monaco nuclear and isotopic techniques are used to conduct research into marine pollution, its causes and impacts. So what are isotopes? All matter on earth is made of elements. An atom of an element is made of protons, neutrons and electrons. The number of neutrons in an atom may vary. Atoms with different numbers of neutrons are isotopes of a specific element. Isotopes can be heavier or lighter. Some isotopes are stable and don't change. Radioactive isotopes or nuclides decay over time and emit ionizing radiation. Most isotopes occur naturally. We can't see them but with the right instruments we can measure them. Radiation from decaying isotopes can be detected using an alpha, beta or gamma spectrometer. By measuring this radiation the scientists can identify which radionuclides are present in a sample and their concentrations. For stable isotopes, mass spectrometry is used. Through their difference in weight, isotopes can be swiftly and precisely detected giving information about types of pollution, its level and source. Scientists from the IAEA and its partner institutes analyse isotopes in samples collected from the sea or coastlines. They're trying to find out whether toxic elements are in places or organisms where they shouldn't be or above the recommended limits. Radioisotopes can be used to trace a biological or chemical process. For example, to see how marine life accumulates the toxic heavy metals commonly found in the sea a radioisotope of mercury can be added. It mixes with the mercury already in the water. Since it can be detected its behaviour becomes visible to the scientists. Nuclear techniques can also be used for dating. Samples are taken from the bottom of the sea. A radioisotope decays over a specific period of time. By measuring its activity in a core sample it can be determined when the different sediment layers were deposited. With this information the scientists can specify when incidents of pollution occurred. Planet Earth may no longer be blue but our oceans and shores will continue to be an essential part of our daily lives for centuries to come. Maintaining their health is key to our future. By using the results gained from the IAEA's research projects worldwide we can learn how to use the oceans with respect rather than abuse them.


You can party on the plaza with us next year. Apply now. Come party with us on the plaza next year. Apply now. Hey! Apply now and come party on the plaza with us next year. Hi, I'm Brett Peters, Dean of the College of Engineering, and we're looking forward to having you join us here at the party on the plaza next year.


Hey, it's Anfa! And today I want to talk about an equalizer plugin that I'm using all the time. I've been using a few different equalizer plugins on Linux, and as you know me, they gotta be free and open source software as well. And I've settled on LSB Parametric EQ times 16 stereo. And that's what I'm using every day today. Whenever I need to EQ anything, I'm just using LSB EQ. So what is it? I've prepared a few test sounds for us to play with. Alright, let's insert the plugin, LSB Parametric. And as you can see, there is multiple versions of this plugin available. The one that I'm using the most is LSB Parametric Equalizer times 16 stereo. But there's also a mono version. There is a mid-side version, which lets you equalize the mid and the side signal separately. So for example, you can hypers your side signal, which will make your base perfectly mono. And that's an often used trick to ensure the sub-base is powerful and perfectly centered and has no phasing issues between left and right channels. There is also left-right version, which lets you equalize left and right channel independently. There is also a 32 filter version of this plugin. So the one I'm using is 16 filters and there's also 32 filters. And all the same versions are there as well. Let's insert the LSB Equalizer times 16 stereo. And you can see it provides us with a nice inline display of the equalization function. Let's double-click to open the interface. And this is the user interface. I'm going to make it slightly bigger, just not big enough, not as big. So I'm covering part of it. All right. So if I play something, you can see that we have input and output meters on the top, which help us identify what's going on. And first thing I do is enable analysis most of the times. So right here in this tab, we have an option to enable the analysis. And by default, it's disabled and we have two options to enable it. It can be post EQ. That means the graph we see here is already the equalized sound or it can be pre EQ. That means it's the sound before we apply our correction. Usually I use post EQ, but sometimes you may just want to use pre EQ. There's also two settings here, reactivity. Reactivity means basically it's the window time over which the signal is being averaged. So longer reactivity time, this is one second, not one millisecond, I believe. Longer reactivity time gives you a slower moving graph that's more averaged out. So it's easier to see like individual harmonics, otherwise they're kind of shimmery. But well, and shift lets you offset the vertical location of this graph. So if your signal is too quiet and you don't want to boost it with the input gain here or the output gain and you just want to boost it for the analysis, you can use this shift control. By the way, double clicking on the knob resets it to the default position. Maybe I'll talk about knobs in LSP plugins because LSP stands for Linux Studio Plugins and there's a bunch of excellent processors in this series, one of which is DAQ. There is also a graphic EQ, so I'm not using it because I think the parametric EQ is always a better answer to your equalization needs. And the thing about LSP plugins is that they give you a lot of options, usually a lot more than any other open source plugin you would find. For example, a commonly known suite of plugins is the KALF Studio Gear and I used to use them a lot. So I've learned that the DSP code, the digital signal processing is of questionable quality at times, especially in crossover plugins like the multiband compressor and the saturator, for example, also has a problem if you use the dry-wet control. It's creating a notch filter, which it shouldn't. So there's some sound quality issues with KALF plugins. That's why I've decided to try and use them as little as possible and see what else can I find to replace them with. And I found the LSP plugins to be a great replacement. And actually, the user interfaces are maybe less appealing in LSP plugins than in KALF plugins, but the features are better, usually. And I'm very confident in the sound quality of these plugins. OK, so how do you lose the knobs? If you click and drag up and down, you're going to change the value. I believe if you hold something like Control, Shift.  Now, if you click on the color of the ring around the knob, you can set the value immediately. So if I click here, you see that the value jumped. And this is both useful and dangerous, because if you misclick and you click on this dial somewhere, instead of in the center of the knob, you can set your gain to plus 5 decibels or plus 20, when what you really wanted to do is just click here and make it a bit lower. And double-clicking resets the knobs to zero. All right, so we've talked about the analysis, we've talked about the input-output levels. Another thing is balance. Basically, for some reason, this equalizer lets you change the panning balance of your signal. I don't know why, really. And there's also pitch. This is very interesting, and we'll get back to that once we actually set up some filters, because right now, this equalizer is not doing anything to our signal. So let's do something to our signal. Below the graph window, we have the filter section. And here, you can see we have eight filters numbered from zero to seven, as programmers often do. And we have two sets of these, so we can select filters zero to seven or filters eight to 15. And you can see that you have different colors, so it's easier to see what you're actually doing right now. All right, let's enable a high-pass filter, which is something I do probably most often, is to control the lows. So let's click on this filter type. It's off. Select high-pass. And you see that here is our filter. I can click and drag to change the frequency. If this was a peak filter, I can also click and drag vertically to change the gain. Also, the mouse wheel lets me change the cue. And we can also change all of these parameters with the knobs below. So the left top knob in the set is the frequency. Underneath that, we have the cue. And to the right, we have gain, which is irrelevant for a high-pass filter. Let's reset it. And hue, which is the color. I'm not going to touch the hue because the default color coding of the filters is perfectly fine. All right. So this is a very basic high-pass filter. What if we want to make it steeper? This is a very delicate filter curve. There's not a lot of attenuation per octave happening. So we can change the slope from times 1 to times 2, times 3, or times 4. And this is still not as steep as we can go, as you'll see in a moment. It is much steeper. Now let's talk about the filter modes.  Now every filter in LSP equalizer has multiple different implementations that the equalizer can use, and you can select from. There is RLC, which is, I believe, resistor loop condenser. I don't know what loop. It's a coil. Okay, resistor coil condenser, I don't know. And there's also two types, BT and MT. Now what I've learned is that the BT and MT versions differ with how they respond in the high frequencies. I'm going to touch upon that after in a while. But we have RLC, which are the default filters. There is BWC, which is Butterworth to Chebyshev, I believe. If we select that, you can see this filter is much steeper at times 4 slope. At times 1, actually we can see and compare it to RLC. Yeah, it is a bit steeper. You can see that the knee is a little bit smaller on that filter. And they do sound different. Now if we turn it up to times 4, we can pretty much remove a single, just the fundamental from our note and everything else stays in place. But this is still not as sharp as we can go. So also I believe that the BWC filter, it starts like this, what is it? If we go up with Q, it can become much more steep, but it also has a lot of rippling. It's probably not a very useful filter for clean processing, but if you want to make some interesting moving equalizer curves, then I think it's great because it introduces a lot of peaks. All right, so this is BWC, Butterworth and Chebyshev. I think it's like crossfading between Butterworth at Q0 and the Q above 0 is the Chebyshev filter being morphed into this. I don't know. The Q or the steepness goes up really quickly with the rippling being pretty minimal, so you can do some very sharp filtering with this. This sounds almost like a brick wall filter. Okay, let's go further. So BWC and there is LRX. I believe this is Linquid's Relay, Riley, I don't remember the names, and this is pretty much as sharp as you can go. That's pretty amazing. And this is at Q0. If we go up, you see we have these familiar ripples. So we can kind of like select the trader between the flatness of the frequency response and the sharpness of the filter roll off. Let's see how these two differ. Yeah, that's so steep, my goodness. And there's also APO. I have no idea what that stands for, but this filter doesn't respond to the slope option and it's very smooth.   I think the APO filter is probably going to be great if you want to work with acoustic instruments and you want to have the extremely natural high-pass that, like, you can't tell it's there, never. Okay, let's try some different types of filters. We have high-pass, let's see low-pass, and APO works the same way. It is a resonant filter, though. You know what? Let's talk about this pitch right now. I'm going to switch this back to high-pass and we're going to do a funky thing. Let's enable the second filter, or the first one. I wish the numbering would start from one because people who are not programmers get very confused by this, numbering from zero. And it's not very natural for, like, not programmers to count from zero. And also it's difficult for me to talk about in videos, like, the zeroth filter, what, zeroth? Okay, I don't know how to talk about it. Let's change this to low-pass, and now we have two filters. Let's give this some Q, or not as much Q, please. Okay, oh, I clicked. Yeah, you see, I find the knobs a little bit difficult to work with sometimes because I can be a bit sloppy and sloppy and I misclick and I click on the ring when I wanted to click on the center part. This is a clever design, I think, but it requires precision and it's not always the case with me. All right, let's play. So that's two filters. And now with this pitch, look what you can do. We can offset all of the filter frequencies by a given amount of semitones. So basically, like, we can automate, because this can be automated, we can automate moving, shifting the whole filter curve up and down. Now I've tried doing, automating this with some really fast motion and there is some zipper noise, so it's not perfectly transparent. But for slower movements, and if you're not, like, going with super low frequencies, it's automatable, so we can use this for sound design, like, you can put a bunch of peaks and froths and automate this to create, like, vowel movement or something. All right, let's reset the pitch. So we have a high pass, we have a low pass. The filters I use often are also bell filters, of course. So, you know what? Maybe let's switch to a different, let's switch to a different sound, because I'm using the same sort of patch I've been using. So let's go to the pad now and insert this parametric EQ. So something I use a lot is a bell filter, which allows me to find problematic areas and also find interesting areas in my sound. So we could make it a bit more narrow, up the gain and sweep. Yeah, I'd like a bit more high, so I'm gonna use my mouse wheel to reduce the Q factor. Now we can mute this filter so that it's no longer making effect. This way we can preview what's going on. Now for highs, often a better idea is to use a high shelving filter. So I'm gonna mute this bell filter and I'm gonna use a high shelf. Now when I'm moving it around, there is some zipper noise, you can hear some clicks. So this is not like, it's not automatable. Maybe this could be corrected so that the filters don't produce any clicks when you change the cutoff frequency or the order parameters. Yeah, so high shelves. We can also use different implementations of the high shelves. The BWC version is a bit steeper. The LRX version is even steeper. I wonder what happens if we, whoa, if we up the Q. Okay, that filter gets pretty nasty when we up the Qs because it also attenuates what's below the cutoff frequency. I mean that's interesting. It's not something I would usually want. And the APO filter, whoa, at zero Q it's a very interesting curve. Okay, and Q0.5 is like the sigmoid function. It looks familiar, probably closest to RLC, can go a bit steeper. And at Q0.25 it's like a linear slope. So I think this is like the softest, smoothest filter you can use like have the highs be amplified very, very smoothly and naturally because like there's not a single point where it just jumps up and you know, like with the LRX filter, like here, there's a single point when just plop. So the RLX filter works best at Q0 in my opinion because otherwise it's going to, it's getting unwieldy, it's getting weird. I think a nice thing would be to talk about the EQ mode, by the way. There is one more setting that we haven't touched upon which is pretty interesting. Now there's three settings we can choose here. So by default all the filters are working as infinite impulse response filters, IIR. And this basically means minimal phase distortion if like this is the most common type of filters. What that does is it has zero latency, but it introduces minimal phase distortion. That means the waveform is going to change. So these aren't like the IIR filters are not suitable for using them in dry wet scenarios. Like you should not mix this with the original signal or because of the phase shift, there's going to be a bunch of weird things happening, like you're going to get notches and different stuff going on. But there's also finite impulse response and fast Fourier transform versions. Finite in both of these, as you can see right here, we've got latency introduced. So let me switch back to IIR. So infinite impulse response, zero latency. Finite input response, 85 milliseconds of latency. So we know what's the downside, it introduces latency. What's the upside? The FIR version has linear phase. That means the frequency content is changed, but the phase relationships between harmonics remain the same. And this is often used in mastering, where you want to introduce as little change as possible. However, for this sound, like this pad, let's maybe do a bunch more stuff, like enable this thing here, maybe a high pass, let's make it steep, because I like steep high passes. And now if I change the mode, it sounds exactly the same, like except for the introduced latency of 85.33 milliseconds, there is no audible difference between the two. But this is a sound without short transients, or fast transients. Now I'm using the FFT mode, which is fast Fourier transform. And I don't really know what's the difference in like, it's also linear phase. That's what I read, but I'm not sure how it's different from the FIR version. I don't know, maybe it works by instead of like synthesize, like filtering the original silence, like re-synthesizing the signal from individual harmonics. I don't know if you guys know, let me know, like to learn, what is the difference between FIR and FFT modes in this equalizer? Because I guess there is some scenario in which you would prefer to use the FFT over FIR or the other way around, but I don't know of such a thing. So yeah, now I'm going to show you a percussive sound. And percussive sounds are special as they like expose the problems with, they expose the problems that happen when you use linear phase equalizers. Let me enable the POSTQ. So let me use a high pass on that. Now let's change it to the FIR mode, which is linear phase. Okay, I can't actually hear a difference except for the latency. But what about a bell? All right, let's do a bell, maybe an RLC bell. Let's lower the output high shelf. Huh, interesting. I can't really hear the difference, but the problem with linear phase equalization is that it can smear transients. That means often the punch of a kick sound or a snare sound or any drum sound comes from the fact that there is a fast impulse and we could actually measure or visualize that by using an oscilloscope. Let's go with a mono version. We don't really need to see anything more than one thing, thingy. Okay, let's sacrifice the keys or maybe I'm just going to move them here. Let me make this little oscilloscope show us the transient every time. Okay, so we are in the infinite impulse response. So minimum phase, let's switch to linear phase and see. That's a bit different, so it could be just, well actually it is quite different. Look at this. This is minimum phase EQ. This is linear phase EQ now. You can see how different the layout of the peaks is, like that's because in this mode we are retaining the relationships between different harmonics and if I bypass the EQ, of course it's a bit too loud, you can see that the original sound is resembling a little bit of a square wave. So if I use the infinite impulse response or minimum phase EQ, you see that this square shape is being lost because the filters are naturally introducing phase shift and you would think, oh no, that means they are destroying my sound, actually no because our ears are very insensitive to phase relationships and most of the time the minimum phase EQ, that means IIR, sounds perfectly natural and the only problem is phasing when you mix the original signal with the process signal and then the phase changes actually become a problem because they cancel each other out in different frequency regions differently and you have notches and you have a comp filter then, which is usually not what you'd want. Now the infinite impulse response or linear phase EQ retains the original shape of the waveform but that comes at a cost and the cost is called pre-ringing. If we zoom in even further, maybe move this a bit, let me bypass the EQ, you can see that in here our waveform starts pretty much dead on, it just starts. If I enable the EQ, you can see that our waveform starts bending a little bit backwards before it goes up and this is the pre-ringing effect. It's not very, like, it's not very bad in here, like this won't be, isn't an issue but if you have very tight drum transients, this starts to become an issue because in order for the filter to keep phases aligned, it has to pull some of them back and they start resonating before the transient hits so you get something like instead of dush, you get lush, lush, dush, lush. The transient is lost to some degree because of this pre-ringing. And this is also why the EQ has latency. The infinite impulse response means, like, if I'm correct, I'm not a DSP expert by any means or even an electronic man, that means that the function which is, like, convoluted under the signal is infinite in length. So there's no point in delaying the signal to recover anything because you'd have to delay it by forever. Finite impulse response, I believe, means that the convolution function used is of fixed length and for the lowest frequencies that length is 85.0 milliseconds. And because the length is known, or maybe it's half of that, I don't know, we can process all the frequencies separately and then align them together. But to align them, we need to delay some more and some less and to be able to make sure that they are all aligned, that they are all delayed by the same amount by the end, we need to delay the whole signal by the maximum delay we need to apply to be able to align them. I think I'm getting into deep into that. All right, never mind. Let's see what FFT will do. It looks pretty much identical to FIR. All righty, is there anything left to say? I think there isn't. We could maybe try. Yeah, there's one more sound I'd like to show you. And we can also, like, talk about the difference between this BT and empty filter type, because there's two of them and they are different. So let's see what we can do with that. Are you guys there? Can you see me? Let me know if the stream is working for you guys. All right, here's a little FM patch I made in Surge. Now let's maybe use a, oh, there's an all pass filter as well. Damn, haven't tried this one. I think I should. We can save it for the last. All right, so I want to use a high pass. Maybe make it very, very, very gentle. I should be able to see what I'm pressing on my keyboard. I can see. I thought that was working. Sorry about that. Now let's use a low pass filter and let's compare the BT and empty versions. So low pass of BT and empty. You can see that it has, like, BT is a bit, like, steeper. The empty filter lets more high frequencies through. It's like the, the roll-off is, like, limited to a certain slope. Let's play a higher note and see what happens. Maybe I'm going to test it like that. You see the difference is most pronounced on the highest frequencies. So it's like the, the BT filters kind of, the BT filter, like, snaps to make sure we're cutting off everything at the 20 kilohertz mark. While the empty filter just doesn't care and it just keeps the same curve. The same slope. Yeah, so you can see that the BT filter snaps and makes sure that we hit maximum attenuation at the highest frequency. Let's see how that works in high pass. Let's also do the same thing. No, I don't see any difference in the high pass. Check some other low pass. I'm testing BWC now. BT and empty. All right. Yep, BT snaps, curves down to attenuate at 20 kilohertz. And empty doesn't. It's the LRX. Yeah, BT is snapping. Empty isn't. Yeah, so pretty much that's the difference between the empty and the BT implementation. Now, there is an extensive, there's extensive user manual on the LSP website. And if you have any questions about this equalizer, feel free to consult it. I'm going to link it in the video description. There's also a video by LSP themselves, demoing this and talking a little bit about the different implementations and types of filters. So the video was recorded for an older version, so the interface is a little bit different. But I'm sure we're going to figure it out if you watch that. All right, that's all for today. Thank you for watching. Thanks to everyone who joined me live. Thank you for like going through all the trouble we've been through with the problematic YouTube streaming and yeah, internet not working. So yeah, thanks for watching. I hope LSP Parametric EQ is going to be a great tool in your toolbox. I'm using it every day. Like it's a real workhorse in my toolbox. And I think it's a great, a great plugin. Yeah, also huge thanks to everyone who is supporting me on Patreon and Liberapay. Recently, there's been an influx of new people there and I'm really happy to see that. You guys are letting me do this, even though life is sometimes doing its best to get in the way and make it hard. So I really appreciate that. And it also gives me hope that one day I might be doing this full-time and there's so much stuff to talk about, so many awesome open source plugins, programs that I haven't even had a chance to even had a chance to try out and experiment and learn in the in-depth to make a video about them. Yeah, there's a lot I'd love to do, but time is limited. So I'm going to do the most important stuff first. Yeah. Oh, if you're the reviewer would like to help me out and support this I'm going project of mine of educating about free and open source audio production, please go to patreon.com slash ANFA or to liberapay.com slash ANFA where you can support me with a monthly donation. Thanks for watching and I'll see you in the next video. Bye.


Transformation doesn't happen in one place or on one team, especially in large companies, but you don't want people making the same mistakes again and again. In our next session, Carl Cardenas will show us how State Farm built a program to encourage knowledge sharing across the company and ease the transition into best practices. Let's see how they did it. Why should your organization embrace the Q&A model? For us at State Farm, it actually has a lot to do with common themes and challenges we were seeing on a daily basis. If you take the first statement here on the screen, we all want a knowledgeable workforce that is able to consume new technologies. All of us want to provide great customer service, whether it be internal customers or external customers. We all want a motivated workforce that is able to learn new technologies and share those lessons learned willingly. We always hear about people wanting more opportunities and the ability to develop. And then my favorite is, do you work on backlog items or do you try to tackle new issues? And it doesn't end there. Most of us are in a small team dealing with a much larger consumer base, specifically if you're like in a platform enablement team. There's always a strong demand for technical questions. There's a lot of upscaling and technical education needed for a lot of workforces such as DevOps and cloud-native principles. So overall, there's just a big need for shared knowledge and lessons learned across the scale. Well, like everyone else, State Farm is also encountering these challenges. But we're taking a different approach. We're leveraging the community model. So today, I want to talk about the community model and share with you how it's helping us tackling these issues and how it could help you. So my name is Carl Cardenas. I'm an architecture manager for State Farm. I'm responsible for public cloud architecture, but also our developer, evangelist activities for our public cloud platforms. Look a little bit information about State Farm. We're one of the largest insurance companies in the US. We've been the number one auto insurance since 1942. And we have over 84 million policies in effect in the US. Now, I bring these numbers up not to boast or to showcase, but really to drive two points. One is that the competition is fierce. And they would love for me to not be able to make the first statement. The second one is scale. Scale is something that we're always dealing with here at State Farm. And it's a very common challenge, not only in terms of technical infrastructure, but also when it comes to workforce and scaling knowledge across the board. So traditionally, State Farm, we always maintain our own private data centers. Up until three years ago, we started exploring public cloud. And that got us involved with DevOps and cloud-native principles. So we have a platform enablement team. That's the team that I'm on. So we lay down the core infrastructure for our platform consumers, which are developers, engineers. They are the ones that leverage our public cloud platforms to create solutions for our customers. So today, when I use the term customers, I'm mainly talking about our internal customers, such as our developers and engineers. That's really who I'm talking about. So in our platform enablement team, we have a few functions. But one of the ones that I'm going to talk about today is our community experience team, which is where our developer evangelists are on. So you heard me mention the community model, but what does that really mean? So I want to take a moment just to read our definition of it. The promotion of and reliance on knowledge sharing for both failures and successes, so that teams may learn from the past in order to succeed at scale in technical endeavors. So what does that really mean? Well, it's just a fancy way of saying that we believe that for an organization of our size, in order to be successful in public cloud, we believe we have to work with one another. Share the good, share the bad. And we want our developers and engineers and leaders to rely on the community, but also to contribute back. So I find it easy when explaining the community model to really break it down into four high level domains. Customer service, education, growth, and opportunity. And as I explain each one of these, you're gonna realize that they all kind of overlap and work together, which is great because they help reinforce one another. So let's talk about the first one, customer service. Most teams are often set up in what I call the one to many model, meaning that your team either enables a capability and people come to you for solutions or questions. We see that quite a bit in infrastructure platform enablement teams, such as the one that my team is responsible for. There are challenges with this, oftentimes bottlenecks because this is not a scalable model. So if a lot of people are coming to you for questions, chances are you can't get to all the questions at the right time. Maybe you don't even know the answer to them. We see that a lot in public cloud because there's so many services provided by cloud providers. So very early on in our journey, we realized that we couldn't really sustain this model. So what we did is that we transitioned to a many to many model. And that's one of the benefits you get with the community model. And the way we did that is that we're leveraging a synchronous communication channel, such as Rocket Chat. It's an open-source solution. But by creating that channel, we now have the ability for people to come and ask us questions and we can answer them. But other people at the same time can see the answers and they can see how we're helping them. And what's amazing is that throughout time, we have other people now answering questions. A lot of questions that we don't necessarily have the answers to. But it just improves the customer service experience overall because they get faster problem resolution. And it helps scale up knowledge as well. Something else that we're also doing is that we believe in feedback from our consumers. So we have something called Cloud Paints. And it's nothing more than a GitLab issue. But our platform consumers can enable, can open up a GitLab issue and address a pain point. So what we'll do as a team is that we'll review that pain point and discuss it. How should we tackle it? Do we backlog it? Do we prioritize it? This is something we can work on right now. And then we'll comment back and engage with discussion with our community. But it's just a good way for us to stay transparent and for our platform consumers to let us know what is painful but also help set direction for a platform. And that really helps them feel like they have a voice in the game or in the platform. And that always enhances customer service experience. Let's talk about education and growth. I group these two together because they really go hand in hand. So on the screen, I have three cogs, technical and non-technical. We need technical and non-technical skills to be successful IT professionals. And growing our technical and non-technical skills help grow our confidence. And when we're confident, we're able to solve challenges. We're able to learn new technologies. And just overall, our chance of success just increases tremendously. So we host several community events to help develop these three cogs. I'm going to start with my favorite one, the public cloud study group. This is a volunteer-based group that started about three years ago where people met up to study for a cloud provider exam. And what they would do is that they would meet twice a month. And between them, someone would pick a topic that related to the exam, maybe such as serverless or containers given from that cloud provider. And it would present it to the group. And that forced them to learn the topic but also help share the knowledge across. And what's amazing is this study group, which started about with five handful individuals, has scaled out to over 1,000 members today and has really allowed us to scale out cloud knowledge across our workforce without us mandating that anyone needs to get a certification. So the public cloud study group helps people develop technical skills, non-technical skills, such as presentations, and it just helped people be more confident in learning public cloud skills. Something else that we do have is the public cloud guild. So this is a technical forum where we actually focus presenting technical solutions. And the material is usually 200 level and above, if you want to compare it to college courses in terms of difficulty, but it's just a great avenue for our engineers and developers to present on how they solve problems and what they did to overcome them and share lessons learned or failures across the board so that people can learn from it. So that helps build their technical skills, presentation skills. We see a lot of relationship building come out of it, but also leadership by taking the courage to present to others. Another thing that we do is called public cloud community challenges. This is a monthly challenge that usually come to flavor of technical or non-technical, and we use these to get our people excited about learning new things, but also to highlight some of their achievements when they learn something and do something cool. So that also helps develop their technical skills, depending on if it's a technical challenge, but also non-technical when we make them search for scavenger hunts, for say, or public cloud quizzes and so forth. But we see technical writing, we see relationship building, and we see other good traits get developed with our monthly challenges. We also have something called community champions, and that's for people that we see in time and time again go above and beyond for our community members, helping one another out. And it's not just for like a month or two, it's something that we've seen for an extended period of time. So when we see these individuals that are really going above and beyond for our community, we give them a title of community champion, and that's just a good way for us to recognize their leadership skills, the confidence that they have in themselves, but also the good traits of helping others. So those are just some of the few ways that we're focusing on education and growth. But that takes us into opportunities. It really all starts with the local challenges you experience when you get started on public cloud environments. It's so much different than what organizations have done in the past. So it really starts out with the local challenges. You first got to develop the technical skills and the non-technical skills to solve those challenges. And usually when you saw them, you tend to get confidence. So what we do with the community events is that it's essentially a platform for people to showcase how they solve those challenges, and also for them to get some attention and for others to see the great work that they do. Eventually, we see that as people solve more challenges and share out with community that they become community leaders, such as the community champions that I mentioned earlier. And what's actually really amazing is that the community champions that we have, we see them go do bigger and better things. We see them go into formal leadership. We see them go into technical leadership. And that's really not surprising because a lot of the positive traits that we want in our leaders, they were already displaying in the community when they were all volunteer based. So it's no surprise for us to see our community champions grow and do bigger and better things. But it's just a good way that the community model can help get people the positive attention, help them in further your career. So that's the community model at a high level. But I want to talk about how we got to where we are today. We're just getting started on that third year using the community. So I kind of want to walk you through our journey. So in our first year, it really started with the synchronous communication channel using Rocket Chat. And again, at first, it was really just our team who's less than four analysts just answering question. But throughout time, a lot of other people started helping out to the point now today that oftentimes it's not my team answering the question. It's other people in the community answering them. And that's great because, like I mentioned earlier, that helps improve the customer service. But the reality is that when you are supporting a public cloud platform or several of them, there are just so many services to know about. And our small team don't necessarily have that expertise, but other in the community do. So it's been really beneficial for us and to them to have each other help each other out. Something else we created the first year was a cookbook. So this is like a technical cookbook, wiki, where we share out knowledge. And the first one we created was a cookbook related to infrastructure's code. It's leveraging a GitLab page with a static site framework. And anyone can contribute to it. Originally, it was just us sharing tips on how to do infrastructure's code, how to get started. And today we see people contribute to it. And it's nice to see the community contribute back to the content as they get more confidence and grow their skills. We also started aggregating a lot of the community resources that other have developed. So here you have a picture of a GitLab group that we have aggregated a lot of our community resources. And you see stuff like Docker images, Lambda layers, community tools, you name it. So it's just a good place for us to help give back to community but also for others to find content that others have created. We also kicked off this program called Builder of the Month. And that's just a way of recognizing someone that just went above and beyond that month. So what we'll do is that we'll send a thank you note to that person's leadership. We'll put them on blast and all of our internal channels so everyone can know who the builder of the month is.  But the point is to reinforce the positive behavior and highlight those people that are doing the right things and helping the community out. And then of course the study group. The study group has been an amazing story for us here at State Farm. Without it, we wouldn't we wouldn't have been able to scale out cloud knowledge as fast as we have. And that's very powerful because our leadership never may demand that you have to get certifications. People been doing this on their own and they've been motivating one another. And that's the power of community. You're able to motivate at scale. So here you have some of the stickers that we created for the study group. People love stickers. So let's jump into our second year. Our second year is where things really started to change. That's when we stood up a community experience team. This team is reports to me. And this is where we have dedicated developer evangelists. I have two of them on the team. And their main focus is to strengthen the community. Come up with events think of ways to help them out. Create feedback. Gather feedback. Create content to help them out. Would it be technical solutions or non-technical? And because of them we have a lot more community events but our community has also gotten stronger. So on this slide I am just going to talk about some of the few events that came out of the second year once we stood up that team but there are far more. So community champions what I mentioned earlier that's something that we kicked off because of the community experience team. We were able to identify those long term contributors and champions of everyone in the community. We also kicked up something called public cloud summits. So State Farm we have four main geographical locations. We are located in Dallas Atlanta Phoenix and Bloomington Illinois. So what we'll do at these summits is that we'll focus on one of the geographical locations and it's sort of like a mini internal conference. So we'll spend two days there and we'll create various presentations of various tracks and our platform consumers will also present shared tips and tricks but it serves two purposes. One, it lets us build a greater report with our platform consumers but it also enables relationship building between the product team. State Farm we are very large organizations the chances are everyone knowing one another is sometimes very slim but with these community events not only are people learning but they also get the opportunity to interact with other product teams and build relationships. So it's just a good way for us to strengthen the community. Community challenges these are monthly challenges that I mentioned. We use these to help our community. So what I have here on the screen is an open source project that one of our engineers created and it's all one of the common pain points we heard from our community that keeping up with all of the announcements that our cloud providers are announcing on a regular basis can be overwhelming so what this solution does is that it aggregates the past announcements in the past 24-hour and injects it into our rocket chat channel but it integrates with other popular synchronous channels and email and whatnot. So if you get anything out of this presentation go check out that project it's pretty neat and I have no that it will help many of you out there with the same pain point. Something else that came out of our community challenges was a life cycle decision calculator for storage buckets and that's just a handy tool for help people understand what is the cost related to a bucket based on object sizes number of objects and the implication of different life cycle policies. Again it's just another neat tool that the community has created for one another because of the community challenges. I'll talk a little bit more about the community challenges but it's just a really neat way for us to get the community excited and help itself back. Cloud Pains I mentioned that earlier that's our way of collecting feedback from our platform consumers and it goes a long way in improving the customer service experience and the public cloud guild again we have a healthy backlog when it comes to the guild and that's really exciting because we see some of the greatest content come out of there such as how do you do local testing when you're interacting with cloud services how do you do mocking what's the best way to set serverless all these different things are coming out of the guild and here you can see the GitLab label for that we use for people to sign up or open up a cloud pane. So I want to take a moment and talk about the public cloud CLI and I think this example will help reinforce the power of the community. So we got a cloud pane my team the platform enablement team we got a cloud pane from our community saying that hey getting all these tools installed for public cloud environments is a challenge I have to install the CLI I have to install this and it's a challenge whether I'm on windows or a Mac can you guys help make it easier? So we took that challenge and we started discussing it as a team and we faced the typical question well do we work on this right now or do we backlog it and then we asked ourselves what if we why don't we have the community try to solve it? So that's what we did we opened up a community challenge and we asked the community hey can you guys come up with a solution? And the community responded and we had a few submissions and the winning submission was what we called the public cloud CLI and this is a Golang CLI that is able to pull down the most commonly used public cloud provider tools that we need here at State Farm and just a single command it installs it on your work station it pulls down the latest version all you gotta do is issue one command it's simplified and remove that pain point and the community loved it but that's not where the story ends the community keeps investing in it and time again we see the community adding new bells and whistles to it that open source project I mentioned earlier that our engineer created to pull down the latest public cloud news that I gotta add it to that CLI up until the point to today we're in public cloud CLI version 1.20.0 what I'm trying to get out of this story is that we didn't have the bandwidth or the time to address the pain point but our community did we simply gave the community an opportunity to solve their own pain point and they did and that's the power of having a community they can truly help you out so just remember you don't always have to do it on your own if you take care of the community the community will take care of you so in our journey of creating a community we learned a few things here and there if I start with the first one having a community team is probably the best decision you can make having someone dedicated to take care of your community and give the care and attention and create multiple events will help strengthen your community something to keep in mind though as your community grows and you create more events your developer evangelists or slash advocates will have a need to have someone help them with creating events and coordinating such as a community manager and the reason is because that start taking up a lot of time and takes away from their time on focusing on creating content or job aids or gathering feedback so just keep that in mind the community challenges we have amazing success and I think the case study with the public cloud CLI showcase the power of the community challenges something that we noticed though is that we see less participation when we host technical challenges versus non-technical so right now we are revisiting community challenges because we want to try to increase participation across the board so we're getting ready to release version two of community challenges study group has been an amazing success story and we've been able to scale out public cloud knowledge across the board very rapidly because people have been motivated and wanting to do it on their own but something to keep in mind though if you create something like a study group and it scales out to the point of past 500 you're going to need someone to help keep it up sustain it coordinate events and schedule presentations so same as the community experience team you will see that need as you scale out the public cloud guild this is that technical forum where people can present highly technical topics and show everyone how they solve pain points or design an architecture this has been awesome my only wish and recommendation for you is to get something like this started way sooner leadership this one's important we wouldn't be able to do everything that we're doing today if it really wasn't for support of our leadership and we've been fortunate here at State Farm that our highest level of organizational leadership has supported us and that takes leadership courage to try something different because what we're doing is not always that common but I want to borrow another term from a term that my colleague usually says and that's leadership stamina and that's actually being able to stick through a decision that you don't necessarily know if it's going to pan out like the community we're going through a third year but when we started we didn't know if this is going to work so something to keep in mind though although you have leadership support it's difficult to calculate the ROI of a community success stories like the public cloud CLI they really help explain and articulate the power of a community but if you have leadership that's always looking for metrics just understand that you're going to have some education on your hand to provide them because it's difficult to gather metrics for communities so let's talk about some takeaways my intention today is to not make it look like creating a community is easy that is the last thing I want you to think it's actually a lot of hard work it's taken us three years to even get to the point where we are today and I still don't think we're done yet we're always investing in it and I like to compare it compare our community to a young tree growing it's fragile but it has the potential to blossom into a powerful tree so your community needs a lot of care and attention in the beginning it's going to be tough a lot of times you're going to be the only one doing it and you might even doubt yourself and ask is this really worth it but I promise you stick it through keep the long-term perspective in mind because it is a long-term game and you will see that some of the results are amazing so explaining explain the community model I mentioned earlier that it's easy to highlight it into four major domains customer service education growth and opportunity and the three concepts they all overlap and support one another it's difficult to just emphasize on one so if we go back to our problem statements at the beginning we're all looking for knowledgeable workforce to use skills skills across and knowledge across across the board how do you do that well we're doing that with the study group and we're doing that with the public cloud guild and we're doing that with community challenges just to mention a few customer service how do you improve customer service for your internal customers potentially our externals well we went from a one-to-many model to a many-to-many model we started using cloud pains to gather feedback and understand what are their pain points and we also use community challenges to solve a lot of those pain points what about motivated workforce we're all looking for motivated workforce that wants to learn and share knowledge across the board well we give people a platform that's what the community events are for they're there to help people share their message and recognize and encourage that behavior but it also helps those individuals build a personal brand and helps them potentially get to the next layer or level in their career so give people a platform to share out their good stuff and people will take advantage of it our employees are always looking for opportunities to grow and develop well that's what every community event is intended for to give them that opportunity to develop whether it's technical or non-technical but also help further their own self-confidence because a lot of times getting started on these public cloud environments can be intimidating so having a community to help you and support you goes a long way my favorite do you work on backlog or do you work on new features why not both that's what we try to do with the community challenges you saw what we did with the public cloud CLI and that's been super powerful so the theme of today is you belong here and that's what we're trying to do with the community model we're trying to get our community to feel that they have ownership in the platform and that we truly value the feedback because we do we have essentially just internalize the open source model and just add some bells and whistles what's awesome about the community model is that it doesn't conflict with DevOps practices or the product model if anything it supports it and emphasizes it because the teams that are successful in public cloud environments are the ones that embrace this DevOps and those cloud native principles and it just helps set a good example across the across the workforce we've seen great results with the community model and we believe that it can help a lot of organizations as much as it helped us so I'll leave you with this question seeing how fast technology is evolving all the new things you need to learn and how fierce the competition is can you afford to not leverage the community model and all of its benefits? Thank you