Get Your Stuff
Out There.
Complete Pro Audio Review Content Packages.
All Things Pro Audio
I create in-depth, high-production content for sample libraries, virtual instruments, mixing and mastering plugins, and hardware.
All Angles Covered
Deep Dives, “No-Talking” demos, written reviews, Spotlight videos, and high-impact short-form clips — my content packages are built to reach every audience segment and buying mindset, from detail-obsessed power users to fast-scrolling decision-makers.
Authenticity & Transparency
My reviews are blind (barring a manual read), first-impression deep dives — unbiased, transparent, and genuinely honest. Expect deep and sharp analysis, the occasional bad joke… and biceps.
Trusted by
What the Viewers Say
Packages
Build Your Own
All add-ons build on the Deep Dive, which is why it’s required with any combination.
'No talking' demo
-
Requires the 'Deep Dive' service
-
The Deep Dive edited down to just the music. No talking, no explanation, just the sound.
Blog
-
Requires the 'Deep Dive' service
-
A written review of the instrument/plugin published on the Blog (25K+ monthly visits)
Editorial Spotlight Video Review
-
Requires the 'Deep Dive' service
-
A 10-15 minute talking-head-style editorial review: scripted, on-camera, fully produced. Covers what it is, where it excels, where it falls short, and who it's for.
Vertical Short-form Clips for Social Media
-
Requires the 'Deep Dive' service
-
Vertical clips capturing the highlights of the Deep Dive session. 9:16, motion graphics and animated captions, delivered as files you can run on your own accounts as well as mine.
Content Package FAQ
The most commonly asked questions can be found here. Please read these first to see whether your question is covered before contacting.
Every way of making content is monetised somehow, even when the creator isn’t paid directly by the developer. Ad revenue, affiliate links, sponsorships, traffic deals — the money is always coming from somewhere, and each option carries its own financial and, more importantly, moral questions.
I love music technology, but I’m not interested in producing vast amounts of thinner content just to chase ad revenue or affiliate commissions. I’d rather go for quality and depth, and that takes time — time taken away from my other work, like composing, or from my family.
So the time has to be justified somehow, and I choose to do that simply and equally for everyone: standard rates, depending on which package you pick. No case-by-case deals, no negotiating behind the scenes. That’s easier for me to run, and clearer for everyone else.
You can’t ground trust in whether or not someone gets paid. Everybody gets paid, one way or another — now, directly, or later through ad revenue and affiliate links. And I do believe work should be compensated.
There’s no payment model that guarantees a person stays unbiased. Some can be swayed by an NFR licence landing in their inbox. Some are swayed by wanting views, and hype everything they touch. Affiliate links pull the same way. Some want to get on the good side of a developer. Every structure has its own gravity.
What I can tell you is what the payment covers on my end: production time and a place in the schedule. Not the verdict. That’s the line, and it doesn’t move. All opinions are my own, both in good and bad. I will never accept a collaboration if I’m being asked to say something specific, or to modulate or tone down my words.
But you shouldn’t take my word for that either — anyone can write a sentence like the one above. So it comes down to the same thing it always does with people: consistency. Trust is built by spending time with someone and learning to read their patterns, whether the stated motives hold up over time and across everything they make. Come and watch a Deep Dive with me some day, and decide for yourself.
And if you ever have concerns about anything, send me a question. I’ll answer it.
No. I need to be genuinely interested in what I’m covering. That doesn’t mean a product has to look obviously brilliant before I’ll take it on — some of the most interesting things I’ve covered were the ones I couldn’t quite figure out from the outside. But the curiosity has to be real.
I can’t fake it, and it shows when anyone tries. If something doesn’t interest me, there’s no version of that where the coverage is worth your money or anyone’s time.
Because I make the content I’d want to watch myself. I want to see and hear a product in actual use, not in a flashy edit. Those videos can look and sound great, but they don’t tell me what happens when I put my own hands on it — and that’s the only thing I’m ever really trying to find out.
So I show everything I can: the interface, the keyboard, the player, all of it at once. The relationship between those things is where the instrument actually lives, and you can’t get at it from a cutaway.
What I’m optimising for is usefulness. I want you to know exactly what you’re getting before you buy it — or as close to exactly as I can manage. That doesn’t come across in polished, curated editing. It comes across from some weird guy in Finland sitting in his dark dungeon, actually using the thing. That serves developers too — informed customers are happy customers.
The length has another purpose as well. Every Deep Dive is the foundation for everything else I make about that product — the written review, the Spotlight video, all of it. If the deep work doesn’t happen first, none of the rest of it is worth reading.
You probably should — but they’re not the same purchase.
An ad tells people what you say about your product. A review tells them what someone else says about it, and everyone knows the difference. Buyers have spent twenty years learning to discount the demo video, because they know the demo was made by the person selling it.
The two also work on different clocks. An ad runs while you’re paying for it and stops when you stop. A Deep Dive sits there permanently, and it’s what someone finds two years from now when they search your product’s name before buying. That’s usually the moment that decides it.
What I can’t offer is reach on demand. Ads let you buy a specific number of impressions aimed at a specific group of people, and I can’t do that — my audience is the size it is. If what you need is volume in a hurry, buy ads. If what you need is for someone to trust the product enough to spend money on it, that’s a different job.
There’s also the obvious thing: an ad always says what you want it to. A review might not. That’s exactly why it’s worth more.
Most of this runs on the same clock: one to two working days per stage.
I can usually get to filming within one to two working days of booking, depending on where the queue is. Scout is another one to two days of production after that. Ranger adds another one to two on top, and Vanguard another one to two again — so a full Vanguard package typically lands inside a working week. Recon livestreams are filmed within the same window, and a written blog review takes one to two days as well.
You don’t have to wait for the whole package before anything goes out. Each piece is released as soon as it’s finished.
Yes. The site currently gets over 25,000 visits a month, most of it going to the blog, where people come to read reviews. Video views range from a few hundred to a few thousand depending on the product, the timing of the release, and how much demand there is around it.
Worth saying plainly: a Deep Dive will never pull the numbers a five-minute walkthrough does. That’s the trade. The people who sit through an hour of someone using an instrument are the people deciding whether to buy it, and that’s the audience you’re paying to reach. Views are a rough proxy at best — actual sales are the metric worth watching.
If you want more detailed figures, ask and I’ll send them over.
Then I say so, in the review, in the same detail as everything else.
That’s the part you’re actually buying. A review that could only ever come out positive isn’t worth anything to your customers, which means it isn’t worth anything to you either. The reason a good word from me carries weight is that a bad one is possible.
In practice it’s rarely dramatic. I don’t take on products I’m not interested in, so I’m not going in hoping to find fault. What usually happens is a mixed picture: some things work beautifully, some don’t, and a few will be down to taste rather than quality — and I’ll say which is which. When something doesn’t work for me, I explain why and who it might still suit.
Being critical isn’t the same as being negative. A product doesn’t have to be perfect to sell — it has to do something a customer actually needs, and it has to be honest about where it stops. Most people are perfectly willing to accept limitations, and to accept that a product will grow over time, as long as nobody pretended those limitations weren’t there.
What causes trouble isn’t a missing feature. It’s a buyer who thought the feature was in there. A refund request costs you more than the sale was worth, and someone telling their friends they felt oversold costs you more again. That’s the thing accurate coverage actually protects you from — not the criticism, but the mismatch.
You’ll see it when everyone else does. I don’t send reviews for approval before release, and I don’t take notes on the verdict. What I will do is check factual claims with you if I’m unsure I’ve understood something — misrepresenting how a feature works helps nobody.
And the fee covers the work, not the outcome. It isn’t refundable on the grounds of the review being critical.
A licence for the product, and whatever press materials you have — logos, UI screenshots, product artwork, anything you’d send a magazine. I use them in thumbnails, graphics, and the written review, and having them upfront saves both of us an email exchange later.
Send the documentation too. Manual, walkthrough video, anything you’ve written up. And if there’s something about the product you think gets missed or misunderstood — a feature nobody notices, a workflow that only makes sense once someone explains it, a design decision people mistake for a limitation — tell me. That’s some of the most useful material you can send, and it’s the sort of thing that only the person who built it knows.
To be clear about what that does and doesn’t do: it tells me what to look at, not what to conclude. If I try the thing you’ve pointed me to and it doesn’t work for me, I’ll say so. But I’d much rather have understood what you intended and disagreed with it than missed it entirely.
Timing matters more than anything else. Get in touch well before launch if you want the coverage to land near release — the queue is the queue, and a week’s notice usually isn’t enough. I’m happy to work with pre-release builds, and I’ll tell you if something feels like a bug rather than a design decision.
Beyond that, not much. You don’t need to prepare a brief or tell me what to cover.
Yes, and I’d encourage it. Quote it, clip it, embed the video, put a line on your product page. If people are reading what I said about your instrument, that’s the whole point.
Two conditions, both obvious. Quote me accurately and in context — don’t turn “this is excellent for sustained textures, less so for fast passages” into “this is excellent.” And attribute it, with a link back where you can.
One practical thing about clips. If you’re cutting a section out of a Spotlight video, you’ll need to replace the background music with your own. My music licence only covers use on my own channels, so it doesn’t extend to your posts — and rights holders do come after this, so it’s not a technicality worth ignoring. I can send you the video without the music bed so you’ve got something clean to work with. Embedding or sharing the full video as it stands is fine; the restriction only applies when you’re re-uploading a cut of it.
If you want something specific — a clean pull quote, a particular clip cut out, a version without music underneath — ask. It’s usually quick.
Want me to demo/review your product?
Take things to the next level.
It's dangerous to release alone.
Pre-Release Quality Audit
-
A complete pre-release audit and analysis of your product (sound and UI/UX) – delivered as a video analysis and a written report.
Not ready for a content package, but need coverage?
The Pro Audio Release Radar (PARR) is my commitment to providing developers a no-cost way to get coverage for their releases.
PARR – FAQ
The most commonly asked questions can be found here. Please read these first to see whether your question is covered before contacting.
The Pro Audio Release Radar is a more chill and relaxed quick look livestream format where I check out the week’s new pro audio releases at first-impressions depth rather than full review depth. Every release still gets my full attention; there’s just less time to go deep on any one of them.
A PARR livestream usually runs 1–3 hours, during which I check out a handful of releases from several different companies. I always try to pick releases that share a common theme.
Once you have a product out — or even better, one coming up — send me an email or use the contact form on my Contact page to apply. I review every submission manually, since I only check out products I’m personally interested in. That’s partly for the viewer’s sake and partly for mine: something I don’t have an angle on doesn’t make for very engaging content.
If I decline, please don’t be discouraged. It’s not a statement about your product’s quality, just about what I happen to be interested in right now. Do reach out again when you have something new on the way.
Please include the following in your application: product name, a link to the product page (if it’s live yet), an NFR or discount code — whatever lets me download it — the manual, and marketing materials: product and company logos, plus any screenshots or product images you have. Feel free to add anything else that fills in a gap the product page leaves.
As with my paid content packages, honesty is my number one value. If I can’t say what I’m thinking, I’m not interested in doing a review — paid or free.
As discussed in the Content Package FAQ, no review model guarantees an unbiased, impartial, objective review. Plenty of incentives can shape what a reviewer says, and no monetization model — including free — makes anyone neutral by default.
PARR costs the developer nothing, but that doesn’t mean I get nothing out of it. Views and attention have value. Affiliate links have value. Both can just as easily be argued to reward hyping things up.
So it comes down to whether you trust the reviewer: whether you know who they are, and whether you believe what they tell you. That takes time — time spent together, watching whether someone actually holds to what they say.
Come join a livestream one day and decide for yourself.
No. I need to be genuinely interested in what I’m covering. That doesn’t mean a product has to look obviously brilliant before I’ll take it on — some of the most interesting things I’ve covered were the ones I couldn’t quite figure out from the outside. But the curiosity has to be real.
I can’t fake it, and it shows when anyone tries. If something doesn’t interest me, there’s no version of that where the coverage is worth anyone’s time.
PARR is my commitment to providing no-cost coverage for pro audio developers, and the format has to fit that. Each stream covers several releases, so each one gets a focused look rather than a deep dive. The goal is a clear, useful first impression — enough to tell you whether something’s worth your attention.
I aim to cover releases as close to launch as possible, though PARR streams currently run on a when-I-can basis. In practice that’s anywhere from same day to a week out. New releases get looked at weekly at minimum.
Then I say so, in the review, in the same detail as everything else.
A review that could only ever come out positive isn’t worth anything to your customers, which means it isn’t worth anything to you either. The reason a good word from me carries weight is that a bad one is possible.
In practice it’s rarely dramatic. I don’t take on products I’m not interested in, so I’m not going in hoping to find fault. What usually happens is a mixed picture: some things work beautifully, some don’t, and a few will be down to taste rather than quality — and I’ll say which is which. When something doesn’t work for me, I explain why and who it might still suit.
Being critical isn’t the same as being negative. A product doesn’t have to be perfect to sell — it has to do something a customer actually needs, and it has to be honest about where it stops. Most people are perfectly willing to accept limitations, and to accept that a product will grow over time, as long as nobody pretended those limitations weren’t there.
What causes trouble isn’t a missing feature. It’s a buyer who thought the feature was in there. A refund request costs you more than the sale was worth, and someone telling their friends they felt oversold costs you more again. That’s the thing accurate coverage actually protects you from — not the criticism, but the mismatch.
You’ll see it when everyone else does. I don’t send reviews for approval before release, and I don’t take notes on the verdict. What I will do is check factual claims with you if I’m unsure I’ve understood something — misrepresenting how a feature works helps nobody.
As with my paid content packages, fees only cover the work, not the outcome. Same principle applies to PARR reviews, even when there’s no payment.
A licence for the product, and whatever press materials you have — logos, UI screenshots, product artwork, anything you’d send a magazine. I use them in thumbnails, graphics, and the written review, and having them upfront saves both of us an email exchange later.
Send the documentation too. Manual, walkthrough video, anything you’ve written up. And if there’s something about the product you think gets missed or misunderstood — a feature nobody notices, a workflow that only makes sense once someone explains it, a design decision people mistake for a limitation — tell me. That’s some of the most useful material you can send, and it’s the sort of thing that only the person who built it knows.
To be clear about what that does and doesn’t do: it tells me what to look at, not what to conclude. If I try the thing you’ve pointed me to and it doesn’t work for me, I’ll say so. But I’d much rather have understood what you intended and disagreed with it than missed it entirely.
Timing matters more than anything else. Get in touch well before launch if you want the coverage to land near release — the queue is the queue, and a week’s notice usually isn’t enough. I’m happy to work with pre-release builds, and I’ll tell you if something feels like a bug rather than a design decision.
Beyond that, not much. You don’t need to prepare a brief or tell me what to cover.
Yes, and I’d encourage it. Quote it, clip it, embed the video, put a line on your product page. If people are reading what I said about your instrument, that’s the whole point.
Two conditions, both obvious. Quote me accurately and in context — don’t turn “this is excellent for sustained textures, less so for fast passages” into “this is excellent.” And attribute it, with a link back where you can.
One practical thing about clips. If you’re cutting a section out of a live stream video, if there happens to be any background music being played, you’ll need to replace the background music with your own, or make sure you have a license that covers use of the same music. My music licence only covers use on my own channels, so it doesn’t extend to your posts — and rights holders do come after this, so it’s not a technicality worth ignoring.
For sections where your product is being demonstrated, I don’t use licensed music — I either write something myself or use cleared samples, so those parts are safe to clip and share.
Breaks and talking segments sometimes have background music playing that I haven’t cleared. If you’re pulling clips, stick to the demo sections, or check the track before you post.