Talk-Zone #77 Interview with Piruz Labs

[cs_content _p=’92429′][cs_element_section _id=”1″ ][cs_element_layout_row _id=”2″ ][cs_element_layout_column _id=”3″ ][cs_element_text _id=”4″ ][cs_content_seo]An interview with Piruz Chaman Afruz about emotional VSTs, DSP, AI-assisted development, and running a boutique plugin studio.
About Piruz Labs\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][/cs_element_section][cs_element_section _id=”5″ ][cs_element_layout_row _id=”6″ ][cs_element_layout_column _id=”7″ ][cs_element_text _id=”8″ ][cs_content_seo]I am Piruz Chaman Afruz, and Piruz Labs is an independent studio in the EU making what we call emotional VSTs: instruments and effects built around one feeling first and the DSP second.
Before this I spent years building software for enterprises and had a good deal of success with it. At some point I decided to spend my time on the thing I have cared about since I was a child, which is sound. I started this with a plan for fifteen products rather than one, because after long enough in software you learn how to build things efficiently, and seven of them are out now.\n\n[/cs_content_seo][/cs_element_layout_column][cs_element_layout_column _id=”9″ ][cs_element_image _id=”10″ ][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”11″ ][cs_element_layout_column _id=”12″ ][cs_element_text _id=”13″ ][cs_content_seo]Designing Plugins as Worlds

1. Hello Piruz, welcome to the Noizefield.com Talk Zone, and thank you for taking the time for this interview. You have described your philosophy as designing plugins as “worlds rather than toolsets.” Where did that idea come from, and what does it actually change about the way you design a plugin, including what it costs you in usability?
I have loved music and sound since I was a child, and there are songs I first heard many years ago that still dazzle me now. That does not happen because someone set a ratio correctly. It happens because the record puts you somewhere.
So when I start a plugin I do not start with “what processing is missing from the market”. I start with a feeling or a memory, and then I ask what has to happen to the audio for someone else to feel that. The engineering comes second, and it serves the feeling.
A toolset is easy to evaluate in ten seconds because you already know what a ratio does. A world is not. Someone opens The Guilt Device, sees a knob called GUILT, and has no idea whether that is a filter, a delay or a joke. That costs me sales from people who wanted a compressor and found a mood. I accept that. The people who do stay are not comparing us to the next EQ, and that is the trade I chose.

2. Talk Moonshine is probably the clearest example of this. Please explain a little where the interface concept came from, and how much extra development work a UI like that created compared with a more conventional plugin.
Talk Moonshine started from wanting harmony you could place rather than dial. In most harmonisers your voices are a list of numbers. In real life, voices are somewhere. Behind you, to the left, further away. So the interface became a space you drag things around in, and each voice carries its own position, level and send.
The extra work was not the visual part, it was the consequences. Once a voice has a position, everything downstream has to agree with it: panning, level, the amount of space it gets, how it moves when you drag. And it must all stay sample-accurate and smooth while you are dragging, on the audio thread, without allocating. The UI took a few weeks. Making the engine honour what the UI implies took considerably longer than building a conventional row of knobs would have.

3. Your controls often carry names like GUILT, DENIAL and DOSE instead of technical descriptions. Why is that important to you, and can you give us a specific example of it causing real confusion for a user or a beta tester?
Because those names tell you what will happen to you, and “feedback amount” does not. If I label a control DENIAL you already have a suspicion about what turning it up will feel like, and that suspicion is usually right.
In Harsher Reality, DENIAL is a recovery stage. It pushes the detail and the attack back into a signal that has already been wrecked. The risk with that name is obvious in hindsight: DENIAL sounds like a destruction control, so the natural instinct is to turn it up expecting more damage, and instead the sound gets clearer. The name is emotionally correct and functionally misleading, and I have not fully solved it.\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”14″ ][cs_element_layout_column _id=”15″ ][cs_element_raw_content _id=”16″ ][cs_content_seo]\n\n[/cs_content_seo][/cs_element_layout_column][cs_element_layout_column _id=”17″ ][cs_element_raw_content _id=”18″ ][cs_content_seo]\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”19″ ][cs_element_layout_column _id=”20″ ][cs_element_text _id=”21″ ][cs_content_seo]The Engineering

4. Let us get into the technical side. What does your actual development stack look like today, languages, frameworks, DSP tools, DAWs for testing, version control and anything else that is central to your workflow?
C++17 with JUCE 8, CMake and Ninja for builds, git for version control. Testing happens mainly in Logic Pro and Ableton Live, with spot checks elsewhere. Those two have caught the majority of the real problems, and they fail in very different ways, which is the useful part. Plus a set of command line tools I have written per product: offline renderers that push audio through the real processor, and DSP smoke tests on the products where the failure modes are hardest to hear.

5. When you have an abstract idea for an effect, how do you turn that into DSP? Do you prototype mathematically or in something like Python or MATLAB first, or do you tend to experiment directly in the plugin code?
Almost always directly in the plugin code. I know the mathematically clean route is to prototype in Python or MATLAB first, and for a filter design I sometimes will. But the thing I am chasing is not a transfer function, it is a feeling, and I cannot hear a feeling in a plot. I need it in my ears, in a DAW, on real material, as early as possible. So I build the ugly version fast, listen, and then go back and make it correct.

6. Harsher Reality’s DENIAL stage is a particularly unusual concept, it tries to recover something from material that has already been damaged. How did you translate that idea into an actual DSP problem, and what is actually happening under the hood?
The idea was: what if damage was not the end of the story. Each of the six media in Harsher Reality (tape, cassette, vinyl, VHS, radio and digital) removes something specific. Tape loses air and adds flutter. Cassette narrows and wobbles. Vinyl adds surface noise and a slow wow. VHS drifts. Radio squeezes the band. Digital does not soften anything at all, it just fails hard.
DENIAL keeps a clean copy of what came in. It splits that copy into three things: the fine detail, the body, and the attack. Then it feeds those back into the damaged signal in proportion to how far you turn DENIAL up, with the body weighted by the warmth of whichever medium you are on.
The reason it does not just sound like adding treble is the attack term. It tracks a fast and a slow envelope of the source and uses the difference between them, so the recovery pushes hardest exactly where the transients were. You get the punch back, not just the brightness. The sound stays broken and refuses to die, which is the emotion I wanted.

7. How do you test your DSP? Do you rely mainly on listening, or do you also use automated tests, reference signals, measurements, null tests or other techniques to make sure the processing is doing what you think it is doing?
Both, and I have learned the hard way that listening alone is not enough.
The products where the failure is hardest to hear have automated tests now, and I am still working the rest of the catalogue up to that line. For The Elyssica I needed the relaxation player to calm a preset without flattening the differences between presets, which is genuinely hard to judge by ear because your ear adapts as you listen. So I wrote a test that measures it. It showed the damping made the output about a third darker while the presets stayed as far apart from each other as they were before, which is what told me the character had survived.
Recently I found that one of my own smoke tests had a blind spot. Its assertions were about peak level and residual energy, and total silence satisfied both, so it would have passed a build that output nothing at all. A test you trust that cannot fail is worse than no test.

8. What is the most technically difficult problem you have run into on a Piruz Labs plugin, and how did you end up solving it?
Talk Moonshine 1.0.2 crashing hosts, and it is a good story because the bug was invisible in the place everyone looks.
The audio was fine. The DSP was fine. But processBlock was allocating four audio buffers on every single block. At 44.1 kHz with 128 sample blocks that is roughly thirteen hundred allocations per second on the real-time thread. You are not allowed to allocate there, and the punishment is not immediate. It is statistical. Eventually the memory allocator’s internal consistency check trips and it takes the entire host down with it. In Ableton it surfaced as a free_list_checksum_botch, which tells you nothing about harmony processing.
The fix was conceptually trivial and took a while to find: hoist those buffers into members, allocate them once in prepareToPlay, and have processBlock only read and write the active region. That shipped in 1.0.3. I finished the job in 1.0.6 by removing the last stragglers, some scratch vectors and filter coefficients that were still being built during playback.

AI and Development

9. Do you currently use AI as part of your plugin development process, and if so, how do you use it in practice?
Mostly on the parts of the job that are grind rather than art. Finding and fixing bugs, working through crashes, writing and running tests, and a big one, the time-consuming interface work. Interface code is enormously repetitive: layout maths, state plumbing, the hundred small alignment corrections. That is a real help and it gives me hours back.
What I do not hand over is the decision about what the plugin should feel like, what the controls are called, or what the sound should do to you. Those are the product.

10. Let us be direct about this one. If you had to put a rough number on it, what percentage of the actual code in your plugins is written by you versus written or suggested by AI?
Around 40 to 45 percent of the labour, and I want to be precise about the word labour, because that is not the same as 40 percent of the product.
What that covers is the work that is effort rather than judgement: debugging, tests, the repetitive interface plumbing, and a lot of the reusable scaffolding that every plugin needs. I come from software and IT, so I lean hard on reusable code and a proper lifecycle, and AI fits naturally into that half of the job.
The other half it cannot touch. The spirit of a plugin, the sound, and the whole wiring of how the thing feels under your hands, that comes from emotion and from a mindset, and AI is not going to get there, because that part is bound to being human. I love emotions and I love sounds. You cannot outsource that to something that has never been moved by a record.

11. You have also written a book about generative AI. What is the book called, what is it about, and who did you write it for? Where can readers find or buy it, we would be happy to link to it from the interview.
I was fascinated by AI for years before ChatGPT existed. Long before it became a public conversation I was already planning with it and using it across a lot of different sectors and a wide variety of tasks, so this is not something I arrived at recently.
The book came out at the beginning of the image generation era, when suddenly everybody wanted their own image model. That period was genuinely exciting to me, and I wrote it because I wanted to share what I had: the passion, the research, and honestly the trial and error, because most of what I learned came from the things that did not work the first time.
What I did not expect was how fast AI would turn into something else entirely. I am not sure what to call it now. It has become a very strange creature. Powerful, not fully understood, and moving faster than the people using it. So my view today is that the interesting question is no longer what it can do. It is how we put a leash on it, how we keep control of it, and how we learn to use it in the best way rather than the easiest way.
It is called HOW TO COOK YOUR MODELS: A Cookbook for Building Top-Notch Generative Models and GANs, published in July 2023, and it is on Amazon here: Amazon

12. Has AI ever produced code or a technical solution that looked convincing, seemed to work, and turned out to be wrong in a way that took real effort to catch? Please give us a specific example if you can.
Yes, and the dangerous ones are never the obviously broken suggestions. They are the ones that look right, run clean, and are wrong in a way that only shows up later.
The category I have been bitten by most is plausible-looking code that is correct in isolation and wrong in context. Audio code is full of that, because something can be perfectly valid C++ and still be illegal on the audio thread, and nothing will tell you at compile time. It compiles, it runs, it sounds fine on your machine, and then it takes down someone’s session three weeks later.
That is why I have moved so much weight onto tests and onto reading the diff properly rather than trusting that it works because it ran.
\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”22″ ][cs_element_layout_column _id=”23″ ][cs_element_headline _id=”24″ ][cs_content_seo]Noizefield Exclusive: Get 10% Off Piruz Labs Plugins\n\n[/cs_content_seo][cs_element_text _id=”25″ ][cs_content_seo]Piruz has kindly given our readers an exclusive 10% discount on Piruz Labs plugins.
If you enjoyed this interview and want to explore the unusual world of Piruz Labs for yourself, this is a great opportunity to try one of the instruments or effects we talked about — and save 10% at checkout.\n\n[/cs_content_seo][cs_element_creative_cta _id=”26″ ][cs_content_seo]Use code: NOIZEFIELD\n\n[/cs_content_seo][cs_element_text _id=”27″ ][cs_content_seo]Thanks to Piruz for making this exclusive offer available to the Noizefield community.\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”28″ ][cs_element_layout_column _id=”29″ ][cs_element_image _id=”30″ ][/cs_element_layout_column][cs_element_layout_column _id=”31″ ][cs_element_image _id=”32″ ][/cs_element_layout_column][cs_element_layout_column _id=”33″ ][cs_element_image _id=”34″ ][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”35″ ][cs_element_layout_column _id=”36″ ][cs_element_text _id=”37″ ][cs_content_seo]The Independent Studio
13. You have deliberately avoided subscriptions and iLok. How difficult is it to hold onto that principle commercially when you are running the entire operation yourself?
Commercially it is harder every year, and I am not going to pretend otherwise. Subscriptions would smooth out the income, and that is genuinely tempting when a month is quiet.
I keep refusing for a simple reason. If someone buys a plugin and builds a record around it, that record should not stop opening because a payment failed. Renting someone access to their own past work is not a business I want. So it is buy once, own it, no dongle, and one activation after which it never needs the internet again. That costs me the predictable revenue and I would make the same choice again.
On the “running it yourself” part of your question, I should correct that gently. The idea and the direction are mine, and I am the person behind it, but this is not a solo act. I have friends and colleagues who support the work, and people who test. I have also run companies with three-figure headcounts, so I know what it takes to organise work efficiently, and I apply the same discipline here. The team will get bigger soon.
14. Since late May you have released seven products, Talk Moonshine!, Synthimatic, Thrilled Groove, The Guilt Device, Wrong Dose, Harsher Reality and The Elyssica, in about ten weeks. Was that pace planned, or did circumstances lead to a period of unusually fast releases?
Planned. All seven of them.
Before I released anything I had a plan for fifteen products. Twelve of those are going to come out, and three of the ideas were so wild and complex that they are not ready to be built yet. Seven are out now, and several of the ones that exist will have siblings.
The reason that pace is possible is not heroics, it is that I spent years in software and IT before this, so I know how to make products efficiently. The engines share a great deal underneath, and I use the ordinary fundamentals of software development, reusable code and a proper lifecycle, so that once the licensing, installers, notarisation and delivery pipeline exists, the next product costs a fraction of the first. That is a boring answer, but it is the true one.\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”38″ ][cs_element_layout_column _id=”39″ ][cs_element_raw_content _id=”40″ ][cs_content_seo]\n\n[/cs_content_seo][/cs_element_layout_column][cs_element_layout_column _id=”41″ ][cs_element_raw_content _id=”42″ ][cs_content_seo]\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][cs_element_layout_row _id=”43″ ][cs_element_layout_column _id=”44″ ][cs_element_text _id=”45″ ][cs_content_seo]15. Beyond the DSP and the interface, what part of shipping a commercial plugin has turned out to be the biggest headache, code signing, notarisation, licensing, installers, compatibility, support or something else entirely?
Distribution and platform requirements, without hesitation, and specifically macOS code signing and notarisation.
It is not enough to notarise your installer. You have to staple the notarisation ticket to each plugin bundle individually, the VST3, the AU and the standalone. If you only staple the installer, everything looks perfect on your machine, and then a user drags the plugin out and Logic’s Audio Unit scan quietly refuses it. Nothing tells you. There is no error that says “you forgot to staple”.
And a more recent one, which I will share because it is exactly the kind of thing that does not appear in tutorials. A build run from the wrong directory produced an Apple Silicon only binary while the product page still promised Intel support. It was signed, notarised, stapled and completely correct in every way except that it would not load at all on an Intel Mac. Nothing in the pipeline complained. My build scripts now refuse to continue if an artefact is not universal. I should add that when I went to check that claim, I found the check in one of my own scripts was written as an either/or rather than a both, so it happily reported an Apple Silicon only build as universal. I fixed that too. The tooling will not catch this for you.
16. What does a genuinely bad support week look like when you are also the developer, tester, product manager and company owner? Has support ever changed the way you designed a product afterwards, can you give us some insides into a real example?
Honestly, support has not been the painful part. The volume is manageable and the people who write in are, almost without exception, decent about it. I was expecting that to be the grind and it has not been.
The hard version is the opposite of a bad support week. It is when nobody writes in at all and something is quietly broken. The sign-in link in our emails was losing its token during a redirect. From my side everything looked healthy. No errors, no alerts, the site up. From the customer’s side, sign-in simply did not work, and this had been true for every single customer for longer than I want to admit. Nobody had complained, which is worse than complaining.
It changed how I work permanently. I stopped trusting that no news is good news, and I now watch the paths a customer actually walks rather than the paths I imagine they walk. More recently I added proper monitoring after an outage that I only discovered because a customer emailed me about it. If a customer is your alerting system, you do not have alerting.
17. What is the most expensive mistake you have made so far with Piruz Labs, either technically or commercially, and what did it change about the way you work?
Not a technical one. The most expensive mistake I have made was spending my time on projects that were then abandoned, because my other companies pulled me away from them.
Money you can earn again. Those months you cannot. That is the real cost, and it is the one nobody puts on a balance sheet. When I look back, the losses that still bother me are not the bugs or the bad decisions in code, they are the stretches of my life that went into something that never got to exist.
I am an optimistic person, so I will say the other half too: that pain always carried some gain. What I learned in those abandoned projects is a large part of why Piruz Labs can move as fast as it does now. But if you are asking what it cost, it cost time, and time is the only thing I cannot buy back.
The technical mistakes are cheaper than they look. A customer once redeemed a bundle code and received only one of the two plugins, because the licences were being written one at a time with no transaction around them. He had to tell me. That stung, but it took an afternoon to fix properly and an hour to write the tool that checks orders against what they should have delivered. An afternoon is not expensive. A year is.

Closing
18. Looking at Piruz Labs now, is there something about the way you build plugins that you would do completely differently if you were starting the company today?
I would build the boring infrastructure first and treat it as product, not as chore. Licensing, delivery, installers, monitoring, and a way to verify that a customer actually received what they paid for. I built plugins first and treated all of that as something to get through, and nearly every painful day since has come from that end of the system rather than from the DSP.
The other thing: I would write the tests that assert something happened, not just that nothing crashed. Silence passes a lot of tests.
19. Something you always wanted to say to the people using your plugins, but nobody has ever asked you?
Yes, and it is the thing behind all of this.
I believe we are very blessed that we can hear sounds. It is an amazing gift, because just above the thin layer of air we live in, out in space, there is no sound at all.
We are in a thin layer where air carries vibration to us, and we get to turn that into music that can move somebody who was not even born when it was recorded. I do not think that is a small thing. So when I build a plugin I am trying to mix engineering with emotion and with memories I actually have, and to make sounds that are a bit different from what is already there. Not better specifications. Different feelings.
If one person opens one of these and ends up somewhere unexpected, that is the whole job done.\n\n[/cs_content_seo][/cs_element_layout_column][/cs_element_layout_row][/cs_element_section][/cs_content]