The hidden reality behind releasing an audio plugin

本站添加: 2026-05-30

[00:00:00]Welcome to Panorama Labs. Okay, my name is Nicholas Dorenzo. I'm a two-time Grammy nominated mastering engineer from Melbourne, Australia. I've been mastering records for the past decade.

[00:00:12]But the reason why we're here is because I've got a bunch of notebooks like this with all these fun ideas of DSP. And I've just had these notebooks in sessions. There's something I couldn't do. There's something I had to route weirdly to get make to work or I've done something funny in Reaper or in Meta Plugin. I write down a schematic. I take ideas. I take notes. And over the past few years, I've started building these notes in sandboxes like Meta Plugin to see what holds water, what doesn't.

[00:00:43]Some of those Meta plug-in builds. U Meta Plugin is a sandbox tool that you can route audio within. Um have made it into my regular workflow. One of them I've made into a plugin. Um, and it's frustrating because something I learned is that it is really easy. Oh, not really easy. I'm I'm sort of overselling it there. It is much easier than I thought to build a plug-in using a juice framework.

[00:01:11]Building a plug-in means [ __ ] Like, it means nothing. So what? You can you can have audio route through a nice gooey and you can deploy it to your own DAW.

[00:01:24]Who cares? You know why? Who cares?

[00:01:28]Because actually taking it from something that works in your own DAW and to the market is just is just wildly different. And I did not realize this.

[00:01:37]And I'm documenting this process at the moment because I want to start a new plug-in company. I don't know if it's something that is viable, feasible, or doable based on my expectations and what I would want it to achieve for me. And here's why. Um, and here's why I really want to document this is because so many plug-in companies at the moment, for good, bad, better, or worse, um, actually I don't think it's the plug companies. I think it's a miscommunication between plug-in companies and the market.

[00:02:14]They're like butting heads. The market at the moment are like plug-in companies are coming out and the prices are too expensive and their marketing is really slimy and the market is sort of recluding back. I don't I don't feel like people are like jumping on plugins the way they used to 3, four, five years ago. The plug-in companies are sort of like, okay, how do we I don't want to say dupe cuz I don't think that's what they want to do.

[00:02:47]They're like, well, how do we maximize what we have and expand our reach, get as much recognition as possible, and keep this a viable running business.

[00:02:58]And I just think there's a miscommunication in the in in like between the two parties. plug-in companies, at least in my experience, as beautiful as they are and the developers are, they're very gatekept in what's going on. And I think a bit of honesty and brutal honesty would go far. So that's why I'm trying to build this these ideas or my plugin that I want to bring to the market around that. Um, so I'm going to talk to you a little bit about my history and why a plug-in hasn't come out yet. Oh, actually, um, just quickly, down below there's a link and you might want to put your email in it. And here's why. I want to share with you some of the not like the behind the scenes. Oh, look at me with my dog having a Frappuccino, but like in Reaper, I build out little routing things where I test ideas in and concepts in before I put them to like a plugin. Um, and also in what's the other one? Meta plugin. I build out little tools and it'll be cool to share them with you because while they might not be fullyfledged plugins until they go to development, they're a good way to stress test ideas, get your feedback, and be a part of this process together.

[00:04:08]Anyway, let's get back to the video. Um originally this idea three years ago I had three different um software companies that I had lined up and I'll tell you a story sort of around them and why nothing went through is because the reality of partnering I realized um didn't fit my own moral code at the end of the day or not my moral code cuz I think that sort of might be a diss at people who have partnered but sort of like what I felt was within the bounds of my comfort zone.

[00:04:41]The reality of partnering. Okay, so the first company I approached didn't really want to borrow me because I didn't have big enough of a following at the time.

[00:04:49]Fair enough. You know, they've got the infrastructure and if they're partnering, they need to be able to recoup. They need to be able to like actually make coins. So, I didn't have a big enough following three years ago.

[00:05:03]Now, I have a pretty big following at my studio and with my career and a brand image. Um, two other companies, um, I approached one, another one approached me. Um, we've gotten to the contract stage on pushing a plug-in over the line, but there are a lot of things that I push back on uh around definitions around revenue, merchants of record, um, brand rights and likeness, IP ownership, indemnity clauses in those contracts that I felt for me, unless those things are addressed and we couldn't get to a point where we could address them, I felt like I was selling ing my customer base into a black hole of unknown whereby that's all good and well to sell lots of plugins. Great. People get a great tool, lots of people get a great tool. You get a nice cash check. Um, what's there to complain about?

[00:06:04]But in the background of it, in the contracts I would sign with the company, in the back of my head, I would know there was certain things I would not have control over. And I felt those things I could not have control over were too high risk for the customer base to wear because like I I can't go into details like specifically there, but like there was just a feeling like [ __ ] if this goes tits up, the person who's going to wear the cost isn't the developer. It's not me, it's the customer. And I did not like that. Um I I think one specific thing there were multiple ones but one specific thing would have been like around updates and bug fixes and the promptness of that. All actually actually I can get specific on that. All I wanted was timebound performance clauses around um bug updates frequencies and time parameters.

[00:07:09]And all it said in the contract was like, we'll endeavor to achieve achieve this in a timely fashion. Well, what's a [ __ ] timely fashion? I can't sign a contract and and then sell customers a plug-in based on a timely fashion, which is a subjective sort of thing. Anyway, that's one of many things I push back on. So, the reality of partnering isn't something I want to do. Panoram Panorama Labs is where I want to head. That's my north star. So, you think partnering's difficult? Well, solo building is is more difficult. Now, before I go into some of the things and start breaking down the headaches I'm currently like got mapped out for me in a solo build, um I want to give credit to people who are going to go unnamed, but because like I want to protect I know that some of these people have things going on in the in the plug-in world and um I don't want to like put their name publicly. I know they wouldn't appreciate that, but they've been super kind, super generous with their time with me, consulting um and discussing things and even like me telling them my experiences. Anyway, I know a lot of people are plug-in companies. I know a lot of developers. I know a lot of people in the tech game and we're beautifully acquainted and great friends across the board and I've had multiple calls with people. Um, so before I go into the reality of solo builds, as much as this is me doing it myself, I just want to thank all those people who have jumped on a call with me, told me about their experiences, answered my questions, and just been beautiful about it. So, the reality of a solo build, I said earlier on, it's really easy with a juice framework to throw something together. um I thought I was so cool and then I sent off a VST to a good friend of mine who's another mastering engineer and he couldn't open it because and like um Wavelab wouldn't even let him open it because I didn't have an Apple developer registration. I didn't notoriize the plug-in. And that was the start of a list of things that you need on the infrastructure side if you're going to do this solo and be the developer that I didn't realize you would need to do. Now around notoriization, this is one of I think seven things I've got in this list here and I'm not going to go through all seven, but like this is one of seven things where there is in my eyes or my frame of mind and also my ignorant understanding so people can correct me on this is a moral choice to make here.

[00:09:40]We've all received when we've installed something that unidentified developer message and you have to go into security settings and approve the unidentified developer to install on your system.

[00:09:50]Morally, I don't like the idea of that.

[00:09:52]And here's why.

[00:09:54]The idea of notorizing a piece of software is that when you have the software, it uploads to the server and then it code signs your unique developer ID to that version of the build that is then deployed back to you. So if it's ever tampered with, it will not pass a security check because it will lose that notoriization.

[00:10:14]Morally in my head and my understanding of it is that if I'm selling somebody a plugin or a tool, I want to know one for one that that when they go to install that that they are installing the verified version that I built for them, not something that may have been hacked or cracked or edited or malicious potentially. That would kill me. So there's a licensing fee for that.

[00:10:38]There's a licensing fee for um the extended validation for Microsoft which is like five times the Apple one. Um there's a whole bunch of licenses and associated expenses just at the baseline to keep this thing going. Now from deployment from l from deployment to licensing to cost to to merchant of sale to um just like back-end infrastructure having an account you can log into to see your licenses the expense perom on a perpetual product so a perpetually licensed product the cost perom for that infrastructure is anywhere on the light end from $2,000 on to the high end of $4 and a half thousand US dollars. That is the main risk a lot of people don't talk about and they don't consider in the cost of a plug-in and why plugins cost a certain price. Here's the thing though, that infrastructure is not one for one. You don't need to rebuild that infrastructure for every single plug-in. Once you own the means of that infrastructure as a developer, it scales exponentially. So on the first plugin, that's quite a bit to chew off your bottom line. But then over two plugins, that's split that cost is split in half. And then over three, it's split in third. And over four, it's split in quarters. So it's only getting that critical velocity that's an issue. So once you get over that hurdle of building that those foundations, you've got them and you can use it as a leverage. But um it's a hidden thing people don't really see in the in the plug-in game. And like I said, I really want this to be a transparent process um to hopefully get to the endame where I end up releasing this plugin. The other thing that isn't costed here is sweat equity to actually build this thing. Nobody pays me to build it. This is all time that is opportunity cost to do other things, to go do other records, to go spend time with my family. Um, and I've budgeted, quote unquote, um, about 250 hours. Now, my mastering rate's $185 a master. That takes me anywhere from 45 minutes to maybe a little bit over an hour. So, if I cost this at 100 bucks an hour, that's about 25 grand of opportunity cost potentially there I'm going to be putting into this project. So, my break even for a launch is about 500 units based on my projected um cost price and and sale price and all that. So 500 units to make things like we're good, paid for my time, paid for the overheads, can manage like can keep the business going. The other thing people don't talk about is in the reality of a build and a release is one person I was consulting with um had a conversation with really nice guy um so awesome. Unfortunately, the day his plug-in went live, the main licensing server that they were using was shut down for 24 hours. Like, it just had a major issue and had a 24-hour downtime, which means just as everybody was purchasing their plug-in, the next morning he woke up to a couple hundred emails all with the same issue.

[00:14:12]Fortunately, it was remedied within 24 hours. But that brings me to the next point is long-term support liability.

[00:14:20]Not only is there the cost to build and there is the income that comes in on the purchase as a company you still have a long-term support liability where tickets are still going to come in to maintain.

[00:14:32]So with that I wrote down some percentages that I'm might change. It just might change. So at the moment uh in a hypothetical this is going to market and a dollar comes in for every let's say $100 for easier percentages and numbers for every $100 that comes in 20 to 30% of that in my mind would be smart to tuck away as a safeguard for long-term support liability for any issues that arise for anything that like I need to splash cash at to like go [ __ ] there's something wrong or somebody's hitting me with this ticket or we need to update because Macintosh have went from in Intel to silicon and we need to set aside this time to make sure we get this done or we need to buy new software or licenses that needs to be the safeguard.

[00:15:25]The next thing is the merchant of sale.

[00:15:27]Now there's different structures for selling a product and the cost associated with that. Um some higher than this percentage, some lower, but I'm just sitting this in the middle. 5% of all sale costs will be churned up in merchant of sale and bank fees. Uh 10% of that cost will cover expenses and ongoing liabilities.

[00:15:49]30% of the profit margin in company tax and 25% which is the rest of it is cream. So for every $100 in revenue a 25% profit margin. And I think that's very optimistic. Like that's hyper optimistic 25% cuz most businesses run on like a 10 to 11% margin. So that 25% might be a bit jaded because there's hidden costs in here I'm yet to encounter.

[00:16:19]But that is the foundation and the real reason I sort of juxtapose that against working with a developer is because engaging a developer they have all that infrastructure covered. They have all those costs covered. They have that running system and that's why you profit share with them because that share in the profit covers their their infrastructure and their management of that infrastructure but you have no control over the infrastructure in the same respect. Now, next, we'll go from that and to what this means for me moving forward. Cuz what this means to me moving forward for now is really important cuz that will probably be denoting the next video which comes on. Um, the first thing is I want to settle the licensing thing.

[00:17:10]How I'm going to license this, whether I'll build it myself or use a third party. I've got a meeting on Tuesday with a third party. We'll talk about that. There are some things I want to do that are a little bit I don't know if they've been done with other plugins, but like the way activations are called for online and offline, but something I want to do and make sure for ease of use of my um customer base or hypothetical customer base is that if ever a license key or my licensing system broke in the sense that if I'm using a third party and they no longer supported or their servers are down or whatnot and it breaks or they can't reactivate a license or just say something goes to [ __ ] Um, or even if like that license is revoked or you use a trial and the trial expires, I want the plug-in to be frozen in your DAW.

[00:18:12]So that no, you can't go in there and tweak and use it, but but and this is the big but, your session will not be affected. One of the biggest killers I've had with trials is I try something and I might have used it on a session a few months ago and I never use it again, but I sort of liked it on that sound and then I go to recall the project and the trials expired and I can't use the damn like I can't get that same sound again.

[00:18:38]So, I sort of like the idea of even if the trial expires, they still have access to the way they set it up in their session. They can't tweak it, but they still get the sound of that thing.

[00:18:50]Um, so either whether I build it myself, I've got a meeting Tuesday. We'll see what happens with the licensing because I need to package the licensing into my beta builds because I want the beta testers to be testing the licensing system at the same time because if I go live, I don't want the licensing system to break when I go live. I want to make sure it's tested there. Number two, I'm fortunate to have people I know at Avid.

[00:19:16]Um, I'm on the Apple Avid developer program now and they've sent my details hopefully by now. I sent I gave them to them 2 days ago when they asked for it.

[00:19:27]Um, for the Pace Eden signing tool so I can sign the AAXs. That will be really cool because then I got my ProTools um, set up. So like so when it goes in a beta, ProTools can be baited. And the third thing is I need 20 beta users covering different operating systems, doors, and computer systems.

[00:19:48]And that's my next I'm hoping I can get I'm hoping like I I'm being optimistic to say it would be good to get towards an endgame for that within a week. If by end of next week I've done that, I'm pretty happy. I'll give you a video update next week. So, make sure you subscribe to the channel so you can see this build out. But I really appreciate you guys like or anybody who's interested in this because this is like really new for me. Thanks, guys. Take care.