hckrnws

We killed growth too when we had one of these generous trials.

I worked on a (once) popular Saas app :) We were losing customers when I came in. But then started growing again (slowly) when we started shipping a bunch of great things.

But then the owner wanted to get rid of the "free trial" and was adamant we offer a free version. That would boost our growth to an incredible new level he promised. I could see the reasoning. Our free trial still required you give us a credit card up front. We just wouldn't charge you for 30 days. Asking for a credit card has to be bad for growth, right? People want to kick the tires before they become our customers, and there's a lot more of those folks.

So we ditched the collection of credit cards up front and went to a totally free plan. You could upgrade to a paid plan of course.

Growth started tanking again and we never got it back.

One theory was collecting the credit card just got the really eager shoppers and now our growth was from zombie, forgetful, monthly Saas payments. And that's valid of course. But I wonder too, if just asking for a credit card gets you to be more serious too about trying a product. If you have to put in a credit card, you'll probably focus in here for a bit and not sign up for 10 other things the same day to try. And successfully collecting a credit card while someone is in the process of choosing anything, is probably always going to be easier than trying to convince them in 30 days to come back and get into a buyers mindset again. Unless you really are selling something so deeply crippling not to have it again after 30 days.

I recommend "Alchemy" by Roy Sutherland. [0] It deals with human and behavior that drive economics and highlights ideas that would fail on paper and actually work. Example, turns out you can use Disney like characters painted on the outside of a store to reduce brake-ins at night.

It goes through similar scenarios. Example, "Offering a free version and not requiring a credit card can push the idea that your solution has no value so why should I use it?"

[0] https://bookbrief.io/books/alchemy-rory-sutherland/summary

OMG, i love that book and Rory's talks. He's always got a nugget to think sidewise about something.

This ones actually hard to believe. Did you guys actually track the user signups?

I would bet its the "zombie, forgetful, monthly Saas payments" like you're saying, not a decline in actual signup/use

Might it simply be that people find the app for a use they have, right now? When it works great and solves your immediate problem, what's a few bucks?

Whereas if you have a full function trial period, it solves your immediate need for free and then you already have this mentality "this functionality should be free". Maybe even uninstall the app, erase all its data, and then register for a new trial period next time you need it etc.

I'd have loved for the article to explore such reasons.

Not only that, but if the trial works that way, you can repeat it any time you need to record something. The app probably dropped a prefs file somewhere (the old-style Mac XML preferences files), delete that and go again.

This would actually be easier than just paying.

Easier, yes. But it's cheating.

I'm often saddened by all the normalization of all the things people do to cheat their way through life. Why does everything need to be physically prevented just so people don't find a loophole to exploit? And then just act like it's nothing or are even proud of it? There is a trial period + you are asked to pay if you keep using it after? Well, pay up if you do. You also (hopefully) don't steal candy from the supermarket, even though it's "actually easier than just paying". Why would it be any different for software?

I love Audio Hijack, and I do use Loopback and SoundSource as well. Windows users love to complain about the fact that we have to pay for this stuff, but forget to mention that no amount of money can give you half of the same functionality on their preferred platform.

I guess you can do some of it using a Windows port of JACK Audio or something, but this isn't trivial to get working - and would still pale in comparison. Why it still is so difficult to route audio in Windows is beyond me.

To give a bit of context; I can sit in a Teams meeting using compressors and saturators and whatnot to make the audio better and put any amount of VST plugins in the chain on my own microphone. At the same time I can mix the output from an ambient track from Spotify with audio from liveatc.net and stream the whole thing to an Icecast server while ripping everything to a file.

Trying to do the same thing on Windows will just drive you insane.

Just last week I wanted to add some VST Effects to my microphone input on Windows like I do on my Mac. Basically just an EQ and Compressor. With SoundSource this is - as you said - pretty easy. On Windows I've tried Virtual Audio Cable and was initially confused by the Banana and Potato version. Also it required a separate VST Host, something that SoundSource has implemented. In the end my setup worked by using Virtual Audio Cable, routed my microphone into FL Studio into my effect chain and then from FL Studio back into the system so each application gets the microphone with effects. I also tried Minihost Modular as a VST Host but that does not support VST3 and in the end I just gave up because sometimes it was far too complicated

you might want to check out carla[0], it's difficult to find when looking up vst hosts, you have to get past a couple "unbiased" top 5 list sites & outdated ones without vst3 support still being recommended, but it's the one that's brought me the least issues (expect one or two crashes setting it up anyway). seems it's made for linux first but i've had no (big) issues running it on windows so far. you will need to download third party vsts for every effect fl studio usually implements out of the box

[0] https://github.com/falkTX/Carla/

Make sure to check for potential problems while using the SoundSource trial if you have any "professional" audio system extensions installed. I have Dante Virtual Soundcard and a few others (I do live keyboard performance with my M1 Pro macbook), and SoundSource yields intermittently glitchy audio for me when using it casually to multiplex a few simple sources/destinations (Music, browser, bluetooth speakers). Core Audio is a very complicated piece of technology, so it's also very possible the issue is on Apple's side, or in the "pro" extensions themselves.

(That's as of now -- August 2025 -- so it's possible in the future this issue will be resolved. Don't take this as necessarily true if you're reading this in 2026 or beyond.)

This was the case when there was only MME. With something like a Voicemeter and Audacity you can have similar setup. I was able to have voice call on Messenger and simultanously stream it to the Facebook using OBS.

But it's very clunky, that's true.

You know what I really love about MacOS? Every time I pair my bluetooth headphones it defaults the microphone to that sound input. Can you disable that microphone like in Windows? Nope.

I use SoundSource because without it digital audio has audio levels locked, which is also asinine. We have to admit, audio control on Macs is straight up garbage, and having to buy third party tools to do something the other major OS does out of the box is not a good look.

Perhaps not in the same vein, as it's been quite some years, however, I recall using kX Audio A LOT in my Windows days to fiddle with audio/DSP on my SB/Audigy hardware.

>I can sit in a Teams meeting using compressors and saturators and whatnot to make the audio better and put any amount of VST plugins in the chain on my own microphone.

trivial and free with https://equalizerapo.com

> To give a bit of context; I can sit in a Teams meeting using compressors and saturators and whatnot to make the audio better and put any amount of VST plugins in the chain on my own microphone.

DJ Screw has joined the meeting

XD

I can’t remember exactly when I started using Audio Hijack, but it might have been from that very first release with the free-trial bug, as I used it to record streaming radio programs beginning around 2002 or 2003. I still use it now. In fact, it’s running on my Mac at this very moment, capturing a live stream from BBC Radio 3.

There aren’t many other applications I have used for so long and with as much satisfaction as Audio Hijack.

Same here - it's one of those it just works apps that has given me a ton of utility for more than a decade, at a reasonable price.

While the bug is how soon the cutoff occurs and the prompt is shown...

Comparing the dialogs; did the 15-day expiration dialog have a "purchase" button at the time of the bug? (its screenshot in the write-up does not.) Making the purchase easy to initiate with the purchase button seems like something that would increase conversion rate, too.

The way I read it, the first dialog showed up the first time you launched the app, and never had the Purchase button. The idea was that 15 days later, you’d see the second dialog (after 15 minutes of recording). Due to the bug, however, the second dialog showed up after 15 minutes of recording from day 1.

The second dialog was always shown (and presumably always had the purchase button), but the difference was between whether users got 15 full free days first or not.

So, letting people try it out it for two weeks prevented them from buying it? That doesn't reflect well on customer satisfaction.

I'm sure this is some MBA 101 stuff, but I'm slowly learning that all sales come from a sense of urgency.

A two-week long trial ends and you're not even on the computer? Oh well.

You're recording something longer than 15 minutes that you want completed _right now_ and the only way is to upgrade? Instant purchase.

That doesn't mean that urgency has to come from a place of in-authenticity. In this case, I think the trial time limit is fair. People still get real value (actually for even longer than just two weeks), but if you want the full-offering you have to pay for it. It's a decent balance.

Bingo. The best trials are those that allow the user to determine whether the product is capable of solving the user’s immediate problem without actually solving it unless the product is purchased.

It's a shame that HN doesn't appear to have a "save comment" feature beyond just upvoting, because this is a neat and succinct statement I'd like to remember.

Click on the comment’s timestamp. The “comment thread view” (don’t know what to call it) has a link to favorite it.

Thanks, useful to know!

If only there was a product that moved this link to a more convenient location! I would buy it on the spot!

The "Refined Hacker News" browser plugin adds the "favorite" link on top of every comment.

(It's one of the few browser plugins I use.)

> all sales come from a sense of urgency

all coerced sales come from a sense of urgency. Not the same thing.

> That doesn't mean that urgency has to come from a place of in-authenticity

In-authenticity is a subjective term here, but are there competing incentives against offering a "use only once" price alongside the full product or a subscription model? You bet.

I believe this goes hand in hand with certain types of customers. Purchasing software is often a long-term decision, but many people only need it once. In 15 days, they can complete one or two projects and then forget about it. With a 15-minute limitation, however, you are effectively encouraging them—assuming the quality of your product matches the price—to purchase the software.

So customers were satisfied anyway, but because of the bug their satisfaction did not last enough:-)

I think more than anything it reflects on the fact that most people don't need to record audio all that often. If the product is fine, but you've done all the recording you need, why would you buy it. I would wager that most users never even saw the trial end nag screen simply because they didn't need to open the app anymore.

This. It's not an app that you would necessarily use every day, so basing the trial on a certain number of days wasn't a good fit.

Audio Hijack is one of the best pieces of software I've ever used. Your takeaway is misguided.

It's much more about aligning the freemium window with the urgency horizon.

A two-week trial won't convert a user that's solved their issue within that window.

How does it compare to Audacity or OBS or other free tools? With so many written and video tutorials on capturing audio with Audacity and OBS, it seems like a high bar, especially for a single use.

Audacity can do most of the audio editing functions of Audio Hijack.

OBS can replicate the audio routing (though not as smoothly) though I'm not too familiar with its audio processing capabilities. I mostly see OBS and Audio Hijack as complementary products.

That said, Audio Hijack is so good for routing and processing audio that it's not even a competition, AH all day.

I've done so much mischief and tinkering with AH just because it's so easy. You can reroute audio between applications, fiddle with L/R channels and filtering, and pipe it through to others, all on the fly. I've used it for everything from being a DJ in zoom calls, to setting up presentation audio, to setting up a virtual sound board that repeated audio snippets I collected in real time from the conversation, to connecting a facetime audio call from one teammate into a zoom meeting.

There's so much flexibility and setting up the workflows is a breeze. AH hurdles the bar IMO.

It's more complicated than that. People have the highest intent for a product early on (ie, at the moment they sign up). That is when they are most likely to pay, and by paying, they make a commitment and invest the time to get value back out of the product.

A free trial gives them a chance to waffle, and usually by the end of the trial they have haven't put in the effort to decide they want to buy the product, so they don't. Paying earlier also creates a commitment bias.

I've seen this over and over again in products. You want to give people enough usage that they can have confidence the product is worth paying for, but not enough time that they waffle.

It's more like for many people the software is a solution to a temporary problem ("job to be done", in a recent MBA fad phrase). Once you get the job done, satisfied or not your need to buy Audio Hijack is diminished.

So it seems; there's a lot of software you only use incidentally, I suspect this one was right in that spot. Like, once a year or so I need to clean up my hard drive; do I buy a license for a disk usage visualizer, or do I pass because I only use it once? If there's a timed demo I can do my task and forget about it again.

I see you weren't around when such shareware was the norm.

With a two weeks trial, the effort to reset the app whenever the restriction popped up was minuscule, hence nobody paid money for it.

This is almost certainly why the bug changed everything.

It's really hard to do time limited trials in any durable fashion, where that encompasses more than a single runtime of the program. Something, somewhere, has to persist some kind of indication to the program as to when that period started, and you can always modify it, nuke it etc.

Do you own anything Apple, because few bucks for app is nothing, if you just spend several hundreds bucks for monitor stand or RAM. :)

Probably. I use a lot of trial and free software 1 - 3 times in a single week. I love that its an option. But if everyone forced me to pay I would probably have to.

It's sad that the more generous, user-friendly trial policy led to worse sales. ;-(

I'm actually not so sure. Even if 100% of the signups to the new version came from users trying for the first time, the previous version being essentially free could have got the app a lot of publicity in tutorials, recommendations or even just showing more highly rated or higher in the download charts.

All of that could increase discoverability of the version with only 15 minutes free trial, so it would be essentially trading sales for advertising.

That said, 2 weeks evaluation on a tool you might use only once effectively means it's just free. Those who might have a need say once a month might just uninstall and reinstall it, and feel completely justified because they didn't get their 15 days, only one day.

I agree with you that if the app was indeed "essentially free", it could have seen all the benefits you suggest.

But it wasn't "essentially free". For myself, whenever I encounter a tool I might want to use and it has a limited time trial, I typically skip it unless I'm already fairly certain that I'll keep paying for it after the trial period. I think loss aversion comes in here as well: I'm worried about "wasting" the trial. It's like consumables in a video game: yeah maybe this tool would be useful now, but what if I encounter something later where it would be more useful?

Because of this, I put off signing up for services that automatically have a premium period at the start, followed by the free tier after one fortnight/month/year (as opposed to a time-limited trial you can manually activate). What if I need those premium features at some point in the future and want to actually trial it?

> I'm actually not so sure. Even if 100% of the signups to the new version came from users trying for the first time, the previous version being essentially free could have got the app a lot of publicity in tutorials, recommendations or even just showing more highly rated or higher in the download charts.

You've just described enshittification 101.

it is the unfortunate truth of the world. It's why I just roll my eyes when I see comments like "nagging reminders mean I'll never buy your product!" Those were probably never going to be customers anyway, they're just finding ways to justify it to themselves.

I still have not gotten around to buying WinRaR. On other hand if it stopped working I would probably install something else.

30 year non-paying customer of WinRAR here. I really don't think anything would have changed if I spent some money on it 30 years ago. In fact, way back then, I was correctly afraid of someone sniffing or leaking my credit card info. Today, I'm afraid to buy it because everything is getting AI baked into it. I'm switching back to PKZIP if that happens.

QED

Linked story [0] in the footer sounds even better.

[0] https://weblog.rogueamoeba.com/2023/03/24/the-riaa-v-steve-j...

As I was reading this I was hoping that they had completely disabled the limitations and unexpectedly found alternate routes to sustainable profits, or that people suddenly became more willing to pay when there was less pressure to do so.

But I guess the real bug and its outcome was more in line with the (often disappointing) reality that we all share.

Free-trial-based approach to software distribution is not the best. Compared to at least one better alternative, it is:

0) worse when it comes to developer bottom line (if you are being generous, try to provide enough trial time and usable software during trial period, a large chunk of your users will just never pay);

1) worse when it comes to user experience (you are interrupted, you encounter blocked-off functionality, which basically means that upsell is part of core GUI);

2) worse when it comes to developer experience (now you don’t just program one great product, you also have to program into your core GUI the upsell—the various ways in which it becomes restricted while remaining usable);

3) worse when it comes to product improvement (the unhappy user will simply delete the software and you’ll never know what they didn’t like);

4) exactly identical when it comes to honest paying user’s expenses.

No doubt, there are worse options. (One that takes the cake: advertise it as free software, but constantly upsell the “full version” offered on subscription basis.)

What’s that better alternative I’m comparing free trials against, then? Simply offer returns. Buy it, get a license, make your trial period however long you like; don’t like it—request a refund, get money back, get license revoked. What it means is that “tried and not bought” is no longer one of the “happy paths”. As a result, you have a better chance of really understanding what was wrong (if I must ask you for refund, you are in touch with me), and you also exhibit more confidence in your product up front.

I believe App Store in fact works this way. If someone’s thinking about distributing there and feels like the only way to offer a trial is IAP, maybe reconsider: you don’t need that overhead, one fully featured version is enough if your users can already get their money back if they don’t like it. I believe refund process happens automatically for you as a developer, though I’m not sure whether or not the feedback they provided will be forwarded to you. Willing to be corrected.

I like your line of reasoning and you may be right. But as a user I'll probably try a few of the free trial competitors to see if they do what I want before I put money down. I don't always trust front line customer service and the returns process. Sure, maybe you are the good developer who makes it instant and easy. But maybe you're not and either employ dark patterns to keep me in place or don't respond to me at all to return my money. Then I have to consider if the cc charge back process is worth my time and hassle.

Is chargeback a hassle? I’d think it’s absolutely in the interest of the developer to be responsive to refund requests because chargeback is so trivial with a credit card.

If anything, a downside of the approach I advocated for would be if too many dissatisfied users just issue a chargeback and not even request a refund. For a developer, high rate of chargebacks can presumably cause issues for billing.

There is a big penalty for chargebacks, so not presumably, definitely.

Depends on your platform, pricing, how good your product is. Stripe charges $15 per chargeback; if your software costs $100+, it’s probably not a massive concern. If you distribute via a well-run walled garden, chances are it’s not a concern at all.

Chargebacks aren’t so scary. It’s never a default recourse for any customer, especially not the type financially able to buy your product outright (remember patio11’s advice: the higher you charge, the better educated and less problematic are your customers; and any amount is higher than zero). You don’t just issue a chargeback if you didn’t like your new iPhone; same with anything. Whoever issues chargebacks all the time, rather than going through a refund process, is in no time dropped by their bank for chargeback fraud.

As a developer, you only run the danger of accumulating chargebacks if you promise a refund and then simply ignore refund requests, in which case it’s squarely on you. Frankly, there’s no excuse not to have a fully automated refund processing pipeline.

A data point of one but for me (a couple years ago).

When I was offering a paid app for 2€ on the AppStore I got less than a hundred customers. A free app with a 2€ IAP resulted in a couple of thousand of purchases.

Note also that the free version of the app didn’t have ads or anything, just slightly less functionality. The IAP arguably unlocked only minor features.

My point is: users put zero value on most programs. They will almost always choose a free alternative if it provides them the bare minimum of functionality

Now, with highly professional software like Rogue Amoeba’s things might be different.

I also wonder if it comes down to requiring users to pay after exposing them to partial functionality (15m of recording) v.s. any functionality (must pay to open from AppStore). I think your free app is actually closer to Rogue Amoeba's approach than the pay one.

Is there already an escrow style middleman?

Want a program, give the middleman some money, get the product.

Within whatever trial period, tell middleman you don't like it, they refund you, program stops working.

Post trial period, money goes to developer.

Provided middleman looks more trustworthy than developer or end user, both win. Roughly what lawyers do in the real world.

If that's not a product already, someone is going to make a killing out of creating it.

As a user, if I make a choice to buy from a developer direct, I already trust that developer and their billing system (like I trust whoever made my OS—there’s no other choice). I am definitely not trusting yet another third party and their PII management practices.

I had the same immediate thought, but I think (as the product provider) it's quite a scary kind of friction to add. Customers already understand the standard subscription model/risk. Adding escrow means they have to learn about a new layer, evaluate it, etc. all in addition to doing the same for your own product.

Plus, never underestimate the ability of funnel customers to just flat out not understand something that seems simple to you. Deviating from norms IME leads to a big drop off. So the value of deviating has to be enough to overcome that.

Free trial is far from the norm. Where else in life does an average person get free trials? Whatever you buy, 99% of the time—be it electronics, clothing, etc.—you make the full payment up front, and if you return it you get a refund. You don’t just issue a chargeback if you didn’t like you new jacket; you don’t get a free trial on a washing machine.

Subscription model is not the norm either (and if you ask me, it’s among the worst models ever when it comes to small focused software of the kind Rogue Amoeba makes).

A major benefit (which, frankly, is a surprise to me that it’s even worth mentioning) is that refunds is the most intuitive process to handle it. Us weathered tech geeks have an intuitive grasp of the shareware business model; however, we are a minority.

I think compared to 'a new escrow platform' (which was the GGP), free trial is vastly more understood. I don't disagree that refunds are a better model, at least for my personal preferences, but most people who have used an app store understand free trials (even if they dislike them).

> most people who have used an app store understand free trials (even if they dislike them).

As far as I know, App Store doesn’t have an option for an actual free trial followed by a one-time purchase (the kind old geeks like me know back from shareware times). If you try to emulate it and make your app stop working after some time unless a payment is made, it will be rejected by the App Store. Instead, it has 1) IAP, which many developers abuse by promoting a “free version” with crippled functionality and possibly full of ads, non-stop upselling you the next subscription tier; and 2) refunds.

I think lack of trials isn’t an issue: there’s no reason an average customer should be even required to understand this concept if refunds (familiar to anyone since forever) exist. Meanwhile, abusing IAPs this way leaves a bad taste, and I don’t think in 15+ years I have purchased a single app using this model.

As a developer, you also don’t want to burden yourself by having to provide support to customers who have not paid yet and, probabilistically, in all likelihood never will pay.

As a prospective buyer, I'm not much swayed by a promise of returns. I never know how easy it's going to be. It might be promised that it's quick and easy, then turn out to be a giant pain. There might be terms hidden in the fine print that I missed. I might have to (the horror) talk to a human, which is not what I want when buying software.

I've been buying this sort of software since it was called "shareware" and was obtained on floppies or downloaded over XMODEM from a local BBS. I made a living from it for a long time. The fact that almost nobody has done it this way should indicate it's not as good as it sounds. (The App Store may work this way in practice, but the stated terms are that you request a refund and then it might be granted, at the discretion of Apple. They also explicitly state that requests might be refused for "abuse" which is not defined, and could very well include merely getting too many refunds. It can't really be treated as a trial.)

This almost exact thing happened with me with a hiking app I used to make. We had a 7-day trial when you started the app, but we shipped a release that broke this and made all the paid features immediately paywalled. This led to a big increase in sales and we got rid of the trial forever.

It’s possible that our trial might have worked better if it were like modern iOS trials that start charging you after a certain period, but ours just let you use the paid features for 7 days and then lapsed, and it stifled sales. My theory was people urgently needed the paid features (mostly to download maps for a coming trip) so the trial got in the way of them paying right away.

Seems reasonable that there’s some sort of recency bias here and waiting two weeks can let people completely forget about your app.

So what were the same folks who downloaded Audio Hijack doing on versions 1.5 or older at the end of the 15 day trial period? Download it again?

It’s great that they were able to see higher revenues and take the company forward, but I’m wondering if there were additional features that were only on the paid version and not on trial version which helped with retention and growth.

I'd expect that the 15-minute nag screen prompted users when they were most enthusiastic about the app and therefore most inclined to purchase. After 15 days, your initial interest may have waned, or maybe you even completed whatever recording you needed to do in the first place.

A bunch of users who reinstalled the app every 15 days thought "oops devs figured out my trick, now I can't fool them so easily guess better buy it"

Having used similar software for one-offs I'm not surprised!

Am I the only one who thinks that describing this as a "bug" sounds a bit off? Most bugs don't come with their own updated alert text. It sounds a bit more like they had planned to switch to a different trial method and enabled it earlier than they expected? Or maybe a "rogue" employee added the feature as an experiment and didn't tell anybody?

> Am I the only one who thinks that describing this as a "bug" sounds a bit off?

Yes, you are the only one, because you've misunderstood.

> Most bugs don't come with their own updated alert text. It sounds a bit more like they had planned to switch to a different trial method and enabled it earlier than they expected?

No, the bug was simply that the trial period ended after 15 minutes instead of the intended 15 days.

> Or maybe a "rogue" employee added the feature as an experiment and didn't tell anybody?

There were no employees. At the time this happened, the company consisted entirely of the 3 cofounders. In fact the bug, that is, the shortened trial period, is what allowed the company to grow and hire employees, although the company is still relatively small.

The text in the alert says "You've reached the recording time limit" and "Once you register, the recording length will be unlimited." That requires more than just changing the time variable. They went from "show this after X days" to "show this after X recorded minutes." It's a completely different metric that is reflected in the alert text.

From the article:

> After 15 days, Audio Hijack will nag you to register at launch and will quit after 15 minutes.

Before the bug: after 15 days, the 15 minutes alert would start to appear.

---

From the article:

> In version 1.6, we accidentally broke the intended 15 days of unrestricted usage. Instead, from day one, the app was limited to 15 minutes of recording.

After the bug: the 15 minutes alert started to appear on day 1

You're still misunderstanding. Here's how it originally worked:

(1) For the first 15 days, you could make recordings of any length.

(2) After 15 days, you could use the app for only 15 minutes.

(3) If you paid, then you could once again make recordings of any length.

The bug was that "15 days" in (2) accidentally became 15 minutes, so that after only 15 minutes of trying the app, you were limited to using the app for only 15 minutes, which of course would happen the first time you used the app.

Perhaps you're confused because there were two factors both with a value of 15.

I think this is actually slightly incorrect.

> The bug was that "15 days" in (2) accidentally became 15 minutes

My understanding was that the 15 days became zero. If 15 days became 15 minutes, then depending on implementation it could run 30 minutes of first run? Or could be identical. Hard to know.

But, my reading is that the 15 day timer broke, allowing the other timer to take over, not that days became minutes.

I think you're right. I think what confused me was the phrasing here:

"After 15 days, Audio Hijack will nag you to register at launch and will quit after 15 minutes. Additionally, the recording feature will be disabled."

"Instead, from day one, the app was limited to 15 minutes of recording."

My brain didn't make the jump from "the app quits after 15 minutes" to "the app is limited to 15 minutes of recording."

I had the same interpretation you did, and the same confusion. Great minds (???) think alike?

This is clear. This is not clear in the original blog post. I did not care too read the original blog post additional times to clarify or click the links in it to clarify. The people who wrote the blog post could learn a thing or two about technical writing, and writing for the Internet from this post. The end.

I think the alert text was supposed to only appear starting after 15 days. The bug was that this limitation began immediately.

Option 1: they had a minnutes and days funcion and someone typed days and minutes.

Option 2: they chech every 15 minutes if the trial time is over, so an inmediate expiration is notuced 15 days later. And 15 days - 15 minutes is a coincidence.

15 days/15 minutes is not a coincidence at all. They were both present in v1.5. For 15 days, usage was unlimited. After day 15, recordings were limited to 15 minutes.

In v1.6, the 15 days was inadvertently removed. This meant that the 15 minute limit was in effect from day 0.

Possible, but they almost certainly had functionality to automatically convert from a number of seconds to text like “15 minutes” for rendering.

Unfortunate that some accidental friction was what it took to get users paying for what they over wise clearly found to be a useful product previously.

I definitely prefer a world where being a small software company charging for your product is sustainable. Not everything needs to be ads/SaaS/Mag7 owned/slop...

I tried Airfoil to be able to do the following:

- redirect my music (eg Youtube music) to my Apple Homepod

- still play all other audio (eg some podcast or video) on my laptop

but it doesn't work / is buggy / either puts everything in one location or the other

Has anyone here found a good setup to redirect the audio from exactly one app to the Homepod, and keep all the rest on the laptop audio?

so playing with Audio Hijack, it seems my "Airplay" audio output is *only* present in the interface if I'm currently choosing "Airplay" as my default audio output from the system

So basically with Audio Hijack I can do a "hack" which is: - set my laptop to play on Airplay - play some music there - then if I want to listen to something else on my laptop, I have to create an Audio Hijack pipeline to play some other app on my laptop

Obviously I would prefer the reverse: by default play everything on the laptop, and be able to play a specific app on Airplay... but this doesn't seem to be possible because the "Airplay" device "disappears" from the interface as soon as I stop setting it as the default laptop output

One way to deal with a “transient” audio interface tripping various apps on macOS is by creating a virtual multi-output audio device in Audio MIDI Setup (stock app). That device will be persistent, even when one of its output devices is lost.

In my case the interface was AirPods. It was incredibly annoying when various audio software would reset its output device whenever they disconnect or auto-switch to the phone. So, I set up a multi-output device that outputs signal to the pods along with the wired headphone port, and configured audio software to output to that virtual device. After that, there is no flakiness: when the pods are connected then they get the audio, if they aren’t then they don’t get the audio, nothing else needs to be changed.

Interesting! Can you give more details on how to build this virtual audio device? I tried creating one but it doesn't show as output in the Airfoil app, is there something special to do?

Ensure that at least one of the checked output devices is available and normally it should appear among physical outputs in any software, including Airfoil (unless it’s hidden in Airfoil settings). If it doesn’t appear, then I don’t know what’s going on.

I’ve never used Airfoil though. To be honest, I feel like routing audio through a multi-output virtual audio device might defeat the point of the app if it’s meant to play to wireless devices directly.

> so playing with Audio Hijack, it seems my "Airplay" audio output is only present in the interface if I'm currently choosing "Airplay" as my default audio output from the system

Airfoil will maintain a connection with your Airplay device even after resetting your system audio device.

Though not perfect, but you can use applescript to force Airfoil's discovery of your airplay device by way of control center:

  tell application "System Events" to tell process "Control Center"
      repeat with menuBarItem in every menu bar item of menu bar 1
          if description of menuBarItem as text is "Sound" then
              set soundMenuBarItem to menuBarItem
              exit repeat
          end if
      end repeat
      
      click soundMenuBarItem
      
      repeat with currentCheckbox in every checkbox of scroll area 1 of group 1 of window "Control Center"
          set deviceId to value of attribute "AXIdentifier" of currentCheckbox
          set deviceName to text 14 thru -1 of deviceId
          if deviceName as string is equal to "DEVICE NAME" then -- DEVICE_NAME is the name of your airplay audio device in control center.
              click currentCheckbox
              click soundMenuBarItem
              exit repeat
          end if
      end repeat
  end tell

   tell application "Airfoil"
       set safariSource to make new application source
       set application file of safariSource to "/Applications/Safari.app"
       set current audio source to safariSource

       set aSpeaker to (first speaker whose name is "INSTANCE_NAME") -- Paste the Airplay speaker's instance name here
       if not (connected of aSpeaker) then
           connect to aSpeaker
       else
           disconnect from aSpeaker
       end if
   end tell

  dns-sd -B _airplay._tcp

[0] https://rogueamoeba.com/support/knowledgebase/?showArticle=A...

Thanks for your message! Unfortunately I tried it but it didn't work on my setup (at least the first osascript)

FWIW, Audio Hijack and Loopback are core software for my work setup to process a boom microphone input and make it ready for use with video conferencing/collab software. These two pieces of software are some of the best things I've ever bought for a Mac.

Why do we need a paid app to record audio from the system? Surely it's a small enough job for a small utility/script? This seems very Mac ecosystem to me.

It's very "Mac ecosystem" from multiple directions: a paid-for tool that is often free on other platforms, but also a paid-for tool that provides a very nice UX with easier customizability and features than a "small utility/script".

(I don't use Audio Hijack, nor am I in the market for anything like it. But it's obvious from the product page[1] that it's a nice piece of software. I also know that several podcasters I listen to rave about it.)

That's not to say free options don't exist. BlackHole[2] is FOSS.

[1] https://rogueamoeba.com/audiohijack/ [2] https://existential.audio/blackhole/

Audio Hijack isn't a recording app. It's an app that allows you to selectively route audio from individual apps to different destinations - audio interfaces and otherwise.

Its built-in recorder is a small part of what the overall app does.

It drives me nuts how quickly people jump on the criticism bandwagon without bothering to look up what the thing they're criticising actually does first.

Doesn't change the fact that when you try to find out "how do I record desktop audio on my Mac?", the answer is very often "use Audio Hijack", because macOS has no built-in way to record desktop audio. (Not even QuickTime's screen recorder can record desktop audio, only microphones! It's wild.)

These days, OBS is probably a decent alternative, but it's very video focused and very streaming focused, so it's not exactly great for that purpose.

My experience as a musician and huge linux nerd is: sure, it was all free, and very powerful, on linux, but I never actually made music because of the setup times, learning, hacking, and refining the systems.

Since getting a mac and paying for tools like this, the immediacy of being productive has caused me to actually make music.

it's the same with OBS - wow, what a piece of software. I spent a week going through and configuring it. They really thought of everything. Audio Hijack solved my problem in 30 seconds and made sense for my use case while doing it.

Not great, except for being free, and rock-solid reliable for the purpose of recording desktop audio!

(I pay for Audio Hijack Pro, too — and yeah it is better for the purpose, if the price is worth it to you.)

Don't get me wrong, OBS is great! It's just clearly not made for this particular purpose, and therefore not great for that purpose. If you wanted to make an app whose main purpose is to record desktop audio, it would look a hell of a lot different than OBS.

Please see the dropbox comment: https://news.ycombinator.com/item?id=9224

This is what sparked me to build a Dropbox like web app to connect to FTP servers: https://github.com/mickael-kerjean/filestash

For the past like 30 years I feel there's never been a time some commercial Mac program hasn't filled a simple niche. I remember someone last year posting a Show HN for an ffmpeg wrapper for Mac with a limited feature that focused on transcoding and made $9k in the first 4 months.

Or in the late 90s when there was a commercial program that allowed OS 9 to show real-time window previews while dragging rather than merely showing the window border outline.

Once upon a time, Steve Wozniak paid me ten dollars for what was essentially a fancy GUI on top of an AppleScript.

That is a question for those that did not make that small (free?) script, not Rogue Amoeba that solved the problem with a paid for app.

Indeed. Windows has had a Sound Recorder since 3.1, and it's possible to record the currently playing audio if you select the right input (usually named "Stereo Mix" or similar.)

https://guidebookgallery.org/screenshots/sound

Support for the "Stereo Mix" audio source is a relatively recent thing - and my understanding is that, even now, it's driver-dependent. It most certainly wasn't available in Windows 3.1.

https://en.wikipedia.org/wiki/Windows_Sound_System already had the ability to record from the mixer input (look in the datasheet of the AD1848 codec it uses) and I don't have the DDK to look at currently but I believe it also has an API for the mixer functionality

I used to record the output audio using Sound Recorder, in Windows 95, so the feature goes back at least 30 years.

I'd say that this a missing feature from macOS that windows has had for 30 years already. I believe apple prohibits it for "security" reasons. But there are a number of open source solutions as well, I mainly use BlackHole:

https://github.com/ExistentialAudio/BlackHole

Well, yeah. Mac developers are some of the most conscientious end-user developers in the world, and Mac users want to reward quality software.

It's become less so lately, but the Mac ecosystem historically was what computing SHOULD be.

You don't, depending on your audio hardware. If it has a loopback you can just use sox from the command line to record the loop back channels...

love you guys!!

[dead]

[dead]

And of course you're on MacOS, where very users are used to shelling $$$ for otherwise free apps on other OSes. Well, good for you :)