 So, hello, everyone. In this very small workshop, I'll be talking about how to get your resisting LV2 plugin into the mod. This little thing here. After the workshop, you can come here and then test it out if you want. So, let's get started. I can't make this full screen, then LibreOffice crashes, so sorry. But this is just the basic talking points. One thing I need to mention is that the Cloud publishing, but at least the public side is not working yet. We're working on a developer console that you'll be able to log in, then upload your plugins and stuff like that. But what we can do today is prepare for the Cloud building process and deploy to the mod right now. If you have your plugin ready to deploy to a mod, then when the Cloud building starts working, then you just upload the plugin and it should be fine. I need to talk first about some precautions that you need to make when doing plugins. This is something that I had to do myself, patch a few of the plugins out there. The first one is about the build flags. The quickest thing I can do to show you just show directly the patches I made, which I have here. I'm going to give you an example of the RTX from Harry. Let's see. I hope you can see it. Can you see it? The thing that it's not okay is that there's SSE, and FFMath SSE, which doesn't work when you cross compile because SSE is an Intel thing. It's not available for Mod, which is ARM architecture. What you can do is just make a build flag somewhere on your system that allows to not have those type of optimizations. Then we just pass that flag, you don't have to patch anything. The next thing is being possible to build your plugin without an interface, a desktop interface. This is because the Mod doesn't actually run any desktop interfaces and no X11 in there. The libs are not there. If you have a plugin that's for some reason requires the interface to be built, then it's going to be tricky to get it working on Mod. One example of this is the triceratops, which I had to make a patch to get rid of the UI. The TTL is okay, I guess, we don't use that, but the main thing is in the build system. In this case, it's WAF, so what we did for Mod is just get rid of the code that builds the UI and requires the UI to be built. If possible, try to get your plugin to build without the UI and not failing. Then, you see, this is a Mod-specific thing, but it's good if you have a single bundle per plugin, so that's, for example, I can show you here. In this Mod, I have all the plugins installed for demonstration, but am I connected to internet? Just take a little while to hold. The thing is that when you install a plugin via the Mod store, for example, the Blob ones, because there are several plugins inside the same bundle, when we install this one, it also comes with 10 other plugins, which might be something the user does not want. And there's also the case about presets. If you have presets for your plugin, maybe try to get it somehow inside the main plugin bundle, if it's possible. I know maybe some script, post-builds that does that. Hello, come in, come in. Yes. And also, I just noticed this. Sometimes, try to test your plugin a little bit. In this case, it is something I found. The triceratops, the category for that plugin is actually amplifier, which is obviously incorrect. It should be an instrument plugin. But okay. So, let's begin. The first thing that, before publishing the plugins to Mod that we do is the basic TTL validation and error checking on the metadata, the TTL files. The tools for this are already published, and I can start it here. Let me show you. We'll clone this repository later on. Oh, still loading. This computer is a bit slow. Just a minute. We have a small tool that does this for us. It's in the Mod SDK that we call it. Let me select some random, this one. This one doesn't have any errors. One off the block. Yes, okay. On the Mod SDK, on the first tab when we open it, I'll explain these details a bit more later, but the important thing, this is checks that Cloud will make. Hello? You have errors and warnings. If your plugin metadata has an error, the plugin will not be accepted in the Mod Cloud, basically. So you have to make sure that is figured. One moment. Almost there. Okay, so let's just revise this quickly to those that came now. Before you publish the Mod, this little thing here, you have to have some precautions. The first about build flags that some codes have specific build flags to optimize for SSE or something like that, that if possible, make it so your build system has a flag that disables those. Make it possible to build without an interface, a desktop interface, and if possible, make it so you have one bundle per plugin that will make your life easier and for us as well. And I was talking now about TTL validation. We do this with our own Mod SDK, and I was saying there's two type of things to take into account, the errors and warnings. If you have any error, the Cloud build system will not accept your plugin. Warnings, you should fix them, but, well, initially it will work. The errors you'll see, for example, in this case, the plugin comment is missing. This is not an error regarding LV2, but it's something that we require for Mod. And there's a reason for this. If you go to the Mod interface and click on a plugin, the comment will be here, and this one doesn't have any comment, so it says no description available. Because we want experience to be as best as possible, we require a comment for your plugin to be there. Let's see if this one has... Yes, this one has a comment to delete a little more, a little better. And yes, if you get... Sorry, maybe this is a naive question, or I should have attended your other talk. There's an online system for maintaining the plugins, and how are you installing it onto the ARM? And what sort of ARM is it? Do you have a one-minute summary? Yes, I can do a small summary. The Mod runs on ARM V7 architecture. It's a A20 CPU. So you have to cross-compile if you want to build things for Mod. What we have is a plugin store where there's all the plugins that we have are in there. And let me show you. If we enable stable only, the story is going to change soon because it's still working progress. And my computer is a bit slow. But after we did all the verification and check for the errors, et cetera, you see that right now it's 422 plugins in there. And if this... I think the internet here is very slow. But the stable plugins are actually just 120, I think, maybe less than that. So yeah, we have a plugin store. You click... Right now I have everything installed, but I think I can demonstrate it. I can remove the plugin and if the internet was not so slow, it would be faster. And my computer is also very slow to laptop. And it's compiled on the web or it's compiled on your computer? Right now, well, we can compile it on the web. We have that service running, but for now, just internally, we want to have a... a plugin console, a web interface online for the developers to log in and then submit the plugins, et cetera. So that part is not done yet, but we already have the backend, everything in place. And the plugins you see here are all compiled in the cloud, not on the local machines. So the service is working. And well... Thanks. Yes. Then you click the plugin and then click to install it. I wish my internet was better to show this, but... Yeah, I think you get the point. Just one note from my RC, Felipe. So Robin Garius says that the upcoming lib.live will also refuse to load plugins that don't validate. Yes, that's right. But if the plugin doesn't validate, it doesn't even get into the mod cloud. Right now, some of the plugins that are there don't pass the error checking because we're just testing. But after we've finished with the initial testing, we'll do a full cleanup and only the stable plugins will be there. But it makes sense to just make sure that your plugin validates properly as kind of the punchline here. Not so just doing it for the mod, but your Arter, your JAL, any other LV2 host is going to refuse to load plugins that don't validate. I wish that was true, but from my experience on the LV2 plugins, there's... There are a lot of errors at the moment, but validation has been a little more tricky. So if the tools become easier to validate, then surely we can also say, look, we're just not loading things if they don't validate. Well, I'll teach you how to validate the plugins right now. Exactly. Yeah, I was showing the SDK here, yes. It throws a little errors. The second error there, it's not actually an error because we don't properly support CV yet. Let's see if I can get something else. Yes, a plugin comment is one. You have to have the comment about your plugin. You have absolutely to have the version as well because we handle updates and stuff like that. And you can see the warnings. For example, the email is missing, the mail to prefix, the email is not properly written, stuff like that. And we give a warning when you don't have a mod GUI which are those little custom things. Let's see if this loads. Yeah, this is a mod GUI like an LV2 interface, but made in HTML. When your raw plugin without a mod GUI will load like this, like this, like a TunaCan, it's just a default interface. But yeah. Now, I want to show you how you can actually validate your plugins. This is on the LV2 webpage actually, but not many people actually do it. Let's see, let's see, where is it? Yes, the validation page. Yes, I want to ask you now, how many people have validated your plugins or LV2 plugins? So I guess we'll make an example right now for this. Let's get some random plugin I have here. Actually, let's make it something on .LV2. Yes, I have a bunch of plugins here. I'll do the example for the game plugin that we did this morning. Let's just check. I have a small script that I made which is kind of cheating, which I will show you right now. The thing that you need is the sort validate, which is part of the sort application, sort code, and the thing is explained on LV2 website as well. The first argument that you pass to it are every single TTL file that scribes the standard and then at the end, you specify your own TTL files for your plugin. Hello? Maybe here, just a second. What I'm going to do now to make some things a bit faster, I'm going to clone the LV2 repository directly from upstream. I can actually just clone it here and I'll run the validation without my custom script because not everyone has it, but the syntax is easy to understand. Sort validate everything about the specs. In this case, there's the meta and everything else. If you have the mod, you should also pass it the mod specification, which I can give you a link if you need, and then at the end, you pass your own TTL files. This should be, no, it's not cloned yet. Yes, the internet is slow here. So I can show you their moddevices.com. That address has the specification for mod that defines what the mod GUI is in the traditional LV2 API style and then some properties that we use for mod like the brand and the label, the brand that you can't really see it, but the label is the name that appears in there on the plugin and the brand is the one that appears on the bottom that is a little bit cut off now. Mod has some specific LV2 properties that you should implement in your plugin if you wanted to work on mod a bit better. Okay. So this one has cloned already and if we go like this says my path to LV2 is actually here, LV2 folder and my path to my plugin is, oops, come on. Yes, I know this is a bit tricky and actually you get a warning about parameters and this seems like an actually a warning in the LV2 spec itself, which I should report. But, yeah. The actual tool to verify the plugin has bugs. So because not many people use it, I guess, then there's not many people doing checks for it, but the syntax is that one. Sort of validate the path to everything on all the TTL files in the LV2 project code and then the TTL files on your actual plugin bundle. That way you can verify if, for example, there's a typo. I saw some. For example, if you have, instead of instruments, you write introtemp, something like that. A check like this will let you know that you have a typo somewhere. The output is not always easy to understand, so you have, if you don't understand it, just post it to the LV2 mailing list and we'll help you figure it out. Yes. Is that Robin Garry saying that sort of validate with the error? It's a bug in one of the example plugins and it's not a bug in the spec. It's a bug in the example plugins. In one of the example plugins that would be scanned because you're actually scanning that whole directory for the LV2 spec, which also includes the example plugins. We should fix the example plugins then. We should still fix it. It's not the spec itself. Yes. At least that's good. Okay, so, yeah. That part, the cloud also runs something like this, but if it gives warnings, it only tells the developer if the build will not fail, if there's warnings regarding sort validate because they're not exactly easy to parse. But if you have warnings there, hopefully you'll fix them. Very hopefully. And the error checking I was showing you. You can run it in the SDK if you don't want to run a full browser thing to check for errors. Let's see if I can show you here. On github.com slash moddevice slash mod SDK. The file that does all the parsing is inside mod SDK. Then it's called lilvlib.py. You can see it at the end. If you understand Python, you know what's going on. You can pass your bundles as parameters in the script, and then it will show you some of the warnings. You can see it here. I won't show you stuff about mod specifically because if you're running this standalone, you probably don't care too much about mod right now, but hopefully you will in the future. And yeah. If you want it, let's see. Where's my code here? github.com slash moddevice slash mod SDK. The SDK is there. I'll show you a bit more of that very soon. Next. Now, because as I said, the mod is not an Intel architecture. It's ARM. You need a cross compiler. And we have our own that, well, the cross compiler that we made public recently is the same that we use to build the plugins on the cloud. So the binaries, the resulting binaries will be very similar. And I can just show you. If you're part of the developer's mailing lists, the mod developer's mailing lists, you already know about this. The main builder is the name of the repository. This screen is very slow. But yeah, you have the description here that just tells you what the dependencies are. And to start. Hello. And initially, you just run the boot. There's a bootstrap script here that you run first. It sets up everything, the cross compiler, et cetera. And then there's the build comments to build mod-specific packages, the same way that the cloud does. And you can close the repository and run the bootstrap. You can even run it right now. But it takes at least one hour on a powerful CPU. So we don't have time for now. I did, however, I think. Yes, I already have it here locally. And if I'm not mistaken, I already did the bootstrap and everything is okay. Let's see, let's see. This computer is very slow. But yes, after this, if you want to try to compile your own plugins to mod, if you want to bring... Well, just tell me your URL to your source code. I can try to compile it. Or you can do it yourself if you have a mod. Everything takes a while to compile. If you have a slow computer. This is just the pre-setup. I'm just making sure that everything that I did last night is still working. Yes, okay, no errors. I'll show you some examples there on the mod... Where is it? Mod plugin builder. Inside here, we have all the plugins we have in mod right now. Not all of them compile. For example, the Cintv1, because it needs Qt, I still have to handle that. But the simple example is the Lv2 thing, which is the actual Lv2 source code but compiling just the plugins. This is the MK file, like some rules. So you know how the cloud can build your plugin. This is actually already using a predefined format. This is the build-root MK file. If you know how to write make files, this syntax is very similar. The important bits are right on the top. The version, where to get source code from, what dependencies it has, and what bundles you want to take from the final build. The build will install in something like user-local-lib-Lv2, and then you can define what bundles are important. You can have... Well, there's some plugins that might not make sense for mods. Something that requires a desktop UI or something like that. So you can skip those ones there. And this one uses WAF. You can see it here. And all the build steps are defined in there. So if I can build it like this, I hope you can see it with the examples. Yes, this will take the MK file and then build everything for you, and then take the bundles that you defined on the MK file, then copy it to a separate folder, then you can just deploy it to a mod. And it actually will compile the plugin right now. I'm not... This is actually quick. Okay. Now I'm going to show you the result. Workdir plugins are this. This is the resulting plugins that we compiled right now, and running the SDK with this Lv2 path. Okay, now we have the bundles that we just installed to that directory. Let's see. At the AMP, it complains about comments, but the version doesn't even have an author name, nor the mod-specific stuff. The magic thing, the thing that you want is the deploy, which if I do it like this, if I'm not running an old version, there is. Just a second. I have the SDK here. Basically, what I want to do is just get my plugin and put it inside mod. I exported Lv2 paths, just so the SDK just only sees the plugins inside that folder, and hopefully it should be it, I think. But now I have too many plugins. And I don't think I have the latest version of this. Nope. And I need to fix this. No. This is depo... Ah, wait, wait, wait, I know. Come on. I actually need to send not the local host but to the actual device. Yes. Effect installed. If you do it like this, now... You saw it before that I didn't have HG AMP. Oh, wait, wait, wait, wait. Now HG AMP. Is it HG AMP? This is my fault for having so many plugins in there. Yeah. And this display doesn't even fit everything here. But the process is this way to deploy locally. You click on that button, that button will install it on the mod if you have it connected via USB. And then it will trigger refresh here. Maybe our plugin will be inside the mod. You should still do the TTL verification and everything like that. And that's the basic step. You can also SSH into the mods and copy it manually. And then you'll have to manually restart the audio and stuff like that because it doesn't know that you push it a new plugin there. So it's usually better to go with the SDK deploy there than it knows it needs to do a refresh. Microphone. Is the process going through SSH documented anywhere yet on the wiki? It's not documented yet because we might disable SSH in the future. This still up to discussion. We'll leave it probably in the menu so you can enable it. But with a warning that you should know what you're doing because if some random user enables SSH and there's random stuff, you can break it. Sure. So we have to have some precautions. But yes, the SSH is just using the SCP comments. Then you transfer to the slash root slash dot lv2. And then you do a restart of mod ui and mod host and the plugin will be there. Because that requires some manual steps we prefer it to do VSTK that does the refreshing for you. Everything for you. Yes. Any questions so far? More questions now. So, now that we created some plugins, you saw it. I compiled the lv2 thing. I'm afraid I still have a question. I'm already thinking about generating Faust lv2 stuff for the mod. So the build process takes place in a way that I could actually call the Faust compiler there in this .mka file, right? Yes. And then, okay, so that everything is fully automatic? Yes. Yes. With these restrictions that the right information should be in the metadata and stuff like that, of course. For Faust, you probably want to write a TTL first, generate a TTL, then modify it by hand to make sure everything is all right, to add some comments, stuff like that. No, the right way to do that would be to actually have a minus mod option or something like that or metadata in the Faust source so that you can really write your source and then forget about it. That's the right way to do it. Yeah, I agree. We just have to make sure the Faust is available in the cloud then later on. I'm not sure if default build route provides Faust, but it should not be hard to compile, I guess. Yes, but the cross compiler can be installed locally. Yes. We can test it out there and once everything works and we know it works with this or that Faust revision, then I can just give you a heads up probably and then we can talk about getting it up in the cloud. Yeah, it depends if you want to provide the Faust file or the CPP-generated code of that Faust file. If you just have the CPP file, then it's okay. Just the GCC builds it. Okay, then you don't need anything special on the cloud. If you want just to provide the Faust file and then the Faust generates to the CPP first, we'll have to make sure the Faust is on the cloud. I guess it's not hard, it just runs simple command. No, I mean to compile an LV2 plugin, you just need mainline Faust and that doesn't have much dependencies and stuff. That's good. Yes, now you'll probably want to create your own interface for the plugin so it doesn't look like the Tuna can. And the tool that we use for this is the SDK here. But let me just make a small alteration to LV2 path. When you run the mod SDK and create an interface, the interface will be put on your .LV2 folder. The thing is that sometimes the LV2 path doesn't include that folder, so it will put a file there and then doesn't know it. It's a bug that I need to fix, but if you just include your .LV2 always in your LV2 path, then it should be okay. And well, if you haven't seen this, this is pretty nice. You have your default Tuna can. There's a button here to launch a wizard and we have some templates. They're ready to use. For example, a brown one with three knobs with this style. Let's actually just one off. Yes. And with that, we have an interface for your plugin. Maybe I can put it full screen. Okay. On the next page, we define just the... something for the author and for the name. In this case, let's put it dropula. And simple amp. Here, if you have more than one parameter, you can define the order of the knobs. This case is just the game. And next. And you have interface done for your plugin. We have a tool to make screenshots automatically, which hopefully doesn't take too long in this laptop. The screenshots are the things that appear here. That way you can show a screenshot without loading the plugin. And yeah, now this is the screenshot for your plugin. If you made a mistake, you want to change something. You can just change here. Let's see. This. Then next, next. The previous data is saved. So you can just continue one step as you were before. The screenshot is still the old one. Obviously, you need to generate a new one. And, well, that gives you a basic interface for your plugin. You probably will want to customize it a bit if you know HTML. As I said, the plugin will get the mod GUI. It will be in .lb2. And we have it here. And yeah, this is the screenshot. The data files for returning here. You have the HTML, which, well, there are some things regarding automating the audio inputs and outputs. Because it's a list. But something for later, only if you want to customize it. And basically, with that, you generate the interface for the plugin. Because now the interface is in a separate folder, you'll probably want to merge it with your current bundle. And there's a simple process for it. Let's see if I still have... Wait. Having the plugins, I did HTML. This has a manifest. This is the definition of the mod GUI in .lb2 format. We don't want to override the manifest. So what we usually do is make the mod GUI in a separate file so it doesn't affect the main plugin data. And then on the manifest... Let's see what is here. We can just add the mod GUI.tl as a C also. So when the plugin is scanned, it will load that data file. And the SDK is ready for this process. If I make it like this, and let me show you now by restarting it, it loaded your icon. And because you did it in a way that the SDK is expecting by using a mod GUI.tl, if you do changes, it will not make the data file in .lb2, but it will override the mod GUI.tl file that you have. You can see it here. On the .lb2, the plugin, the folder is empty, but actually changes was this folder, the mod GUI folder. That way, if you make it on your plugin so it has a mod GUI.tl, you can keep running the wizard without worrying about losing data or about duplicating data, having mod GUI in two separate places. Everything cleared so far? Yes? Okay. Felipe, do you only have... There's also this other template with the big... Ah, yes. Is that in the GUI builder as well? I thought I saw that somewhere. Yes, let me... Okay, yeah, there's this... Step zero, maybe? I want to show some other plugin that has more parameters. Does Medigate have parameters? No. Sampler doesn't have parameters. Scoped is in load. Let me copy some other plugin there, some plugin that has a lot of parameters. Then run this again. Not here. I should have a three-band EQ. Okay, this has a bit more parameters. Yes, the first one is the boxy that you already saw. There's the template for the boxy-small that only has a footswitch for the bypass. There's one for presets. That small combo box there will show the presets for your plugin. This is in the case of plugins that don't export parameters, but have a bunch of internal data presets. I made this for ZinatsubFX. Let's see, the next one I have the British. Which is nice. Drag this. You have a few models to work with. There's more. This one. Also the Japanese model. Well, we can add more knobs if you want to. If there's something missing in the style, and then defining seven or eight knobs. And the last one is Lata. This is for the big plugins that have a very large number of parameters. You can also, of course, then do your own. Let me show some examples of this. You're not limited by the SDK ones. You might know that one. I know what's going on with that one. Vocoder. Just some examples. You have here the interface for MDA Vocoder. And in there, the interface for the Necobi. Yes, if you know HTML, and, well, if you know a bit, if you know how to design, it should be easy to make something like this. I can't actually help much, because I don't know much HTML myself. So this is something you probably want to help somewhere else. But okay. What do I have next? Using the SDK. Yes, I showed the wizard. And, well, if you want to publish the plugins through the mod, you'll have to do a package like this one. The contents will probably depend on your build system. I can show you some different types of it. Vocoder, plugins. I believe RTX is actually one of the easiest ones, because it's CMake. If you don't care about the custom DTL files, it's not important now. But this is basically your MQ file. Because you use CMake, there's the parameters for passing custom options. In this case, Harry is a good man, because you have an option to disable interface. Nice. So yeah, if you use something that's like CMake, just that file is enough to get you started. If you use a custom build, I guess like X42. Well, this doesn't fit everything here. Yep. You have a little more work, because you have to pass a bit more flex to the MAKE here. This is one of the robin ones. I actually like, because I can pass saying, I don't want optimizations, and I don't want the desktop interface, which is nice. I love to build the plugins without too many changes. And, well, yes. But if you do it like this, and you have your mod build, your copy of mods plugin builder, running and working, compiling the plugin like that, then as soon as the cloud build system is working, you should be ready to push the plugins there. And I think that's basically, it's, ah, yes. The metadata is important, of course. I can show you some example of, this was a mistake that I did initially. I have this parameter, the waveform that I initially was doing as a Boolean, because if you look at it, it looks like it's a Boolean, it's an on-off, but it's not actually a scale point of two values. If I do it as a Boolean, it will appear on the interface as something like this, like the one on the left, and this is not what I want. So, adding metadata, extra metadata to the plugins makes sense. And you can see, like, here, the units appear as percentage. If you have some other plugin, I'm not sure if the vocoder does it have, yes. Percentages, hurts, stuff like that, a good plugin will usually look like this, where you have options, so you know exactly what you're doing. If this was a Boolean, it was just on-off, you don't know what's going on. Yes, scale points. And, well, I don't think this one has. But, yeah, you get the idea. Also, we also have some custom property, yeah, question. Just to follow up on the metadata, what you're saying is that the way that each plugin exports the metadata, the mod will understand that metadata and actually change how it maps to the hardware based on the metadata. So, if a plugin is actually exporting things like milliseconds and hurts, then the dials and the screens on the mod will actually respond in an appropriate way. Yes, cool. This is the quickest thing I can demonstrate. Oh, that's okay. Yeah, yeah. For example, if I wanted to assign this to the mod, which now I stopped working because of the USB, but assigning that to an, if it was a Boolean, I couldn't assign it to an op because an op doesn't have on-off. But because it's scale points, I can assign it to an op now and just turn left or turn right. That helps with the workflow. Yeah, and yeah, I was saying about the... Where is it? Do I have it here? Yeah, we have four things in Mod that we override on LV2. There is the LV2 default, and then the LV2 maximum, the minimum, and the range steps. This is because those values that you have on your desktop plugins might not be the same that you have on the mod. The gain value, for example, on the mod could be a bit higher, the default value, or maybe you want to restrict the range, the minimum and maximum for the hardware and for the desktop, give it the full range that might be one of those examples. So if there's no mod ranges specified, will it fall back to the default ones of the plugin? Yeah, if it has Mods maximum, it will use that one. If it doesn't use LV2 maximum, if it doesn't have LV2 maximum, it gives an error and then doesn't upload to the cloud. One thing which always confuses me, the range steps are the number of steps or the number of scale points. The difference of one. I'm always unsure about that. The range steps are not related to scale points. The range steps, I think I can show it. Let's say we have a step size of one and have values from zero to ten, then it's eleven steps or is it ten steps? Because actually it takes ten steps to go from zero to ten. Ten steps, eleven values, I think. So the number of range steps that you specify in LV2 is then eleven, because I've seen both in the various plugins. So nobody seems to be sure about that. I think it's actually you need to specify the number of scale points and not the number of steps, but I don't quite recall my... It's not really related to scale points. This is mostly used for flow-out parameters to say how many... But let's say I want to have points zero, one, two, three, up to ten, then I need to specify... Well, you could say the points are the steps or you could say the steps are the steps. Then you have ten steps or you have eleven points, of course. I think that should be a good question for LV2, my list. Yes, I already... But I was a bit embarrassed that I couldn't figure it out by myself. I think I'm currently using the letter theory, at least in my plugins. I think the rest of us were just too afraid to ask that same question. We haven't got that far yet. Post it up and there's probably... In the description there's probably a way to read it that we can come to a conclusion. But if you have something that is an integer, you can just say it's an integer and then you don't have to worry about... Right, but I mean we have those cases and I remember that, for instance, in the tuning controls, there are some cases where I need this for the false plugins and... Yeah, anyway, so we need to find out. Okay, Harry is already at it. No, I thought you just posted to the mailing list. Yeah, that's something we needed to discuss, I guess. There's also a similar thing about LV2 version because LV2 has specific rules for versions that it can't be zero, otherwise it's a stable plugin. It has to be an odd number, you know, or even. I think it needs to be an even number to mean it's stable and if it's odd, it's unstable. Yeah, we need to make that somewhere in the SDK because it's not clear to outside developers that that rule actually exists. And for myself, I actually don't understand that versioning completely yet. It's something that I'll probably do this week to get those details sorted out. And about the range steps, the range steps, if you customize it, it will appear here to say how many steps, like when you move an odd, how many... Well, how fast it goes. That's the range steps here. And I think that's basically it. Yes. Now, if you have a plugin that you like and you like to see it working on the mods, now you can. And basically, that's it. I'll welcome everyone to go see here how it works and everything. So, yeah.