I believe Minuum is the only app I ever paid for on the Play Store, after having followed it since the Kickstarter campaign. It was the only option that made typing on a small touchscreen feel mostly frictionless for me, contrary to the varying degrees of frustration of other options. As a result, I now hardly type on my phone.
For the past decade or so my bookmark has been set to /feed/subscriptions and I can only recommend that. The one or two times a year I end up on the front page act as proof it should remain that way.
> If you don't enjoy composing music, just don't do it
This supposes that the music is the end goal, and the very point of my comment is that it doesn't always have to be, and in those cases "just don't do it" also means not doing whatever comes after.
Just as you state below, this doesn't replace creating music for the creation's sake. I don't believe it will, or should. It merely replaces having nothing at all, or having the 100,000th video with the same upbeat stock sound.
The difference between today and the hypothetical case of not one artist making ends meet from their music is what, 0.1%? 0.01%?
We would be better off if the other 99.9% didn't have worry about making ends meet, than if we do whatever it takes to keep the status quo of the 0.1% intact. That does not only go for artists.
If you're trying to maximize employment, composers aren't the first, second, or tenth place to go looking. If you're trying to say artists will bleed income, they already have for decades, and will continue to. The ones that make a living out of it mostly get their income from live performances and merch, and maybe adtech on social media platforms.
By the same logic synthesizers shouldn't have been invented that allowed people to make advanced sounds without tediously learning an instrument first, consumers should remain priced out of microphones and editing software, etc.
Like I said, I am not trying to feign ignorance on the drawbacks of the tech which is very real and far from negligible. I am not a tech bro AI maximalist. I just do believe that hyperbole will not put the djinn back into the bottle, and pretending like there isn't a real market between nothing and paying or being a composer isn't adding anything to the conversation.
Not everyone enjoys composing music, and for a large group of people paying an artist is not an option. There's a lot to critizise about current AI tech, saying of all things this has no net benefit seems like the wrong thing to call out, and incredibly short sighted for HN.
Yup. Everything left and right of being an email inbox is a bit iffy, and that makes it feel a bit incomplete at times. Like I said, I like it a lot, and it provides a lot of value for the price I pay for it, but I wouldn't mind an option with just a slightly wider feature scope.
Yeah, you're right. Just a hosted inbox alone would be hard to differentiate in the market and I have no answer for that. For hosted email with auxiliary services there is room to carve out a market. At least that's where I see some value. As for being better: It really doesn't have to be. It just has to appeal to a different audience. I think non-VC funded SMBs that don't have Silicon Valley funds to spend on a dozen different per-seat products is a pretty big market.
What I am thinking doesn't have to compete with the whole Office or Google Docs suite, or HubSpot. There is imo enough value in being an economic all-in-one email solution for "the rest of us". Point DNS there, get email, CRM, maybe even a small transactional mail quota and some marketing email features.
I have two projects I would onboard yesterday if this existed, and I have spent more than a hot minute thinking about going for it myself, just to scratch my own itch. The main reason so far that I haven't is that Migadu + Resend is enough for my needs at this time, and I can do without CRM for now.
I think there could be, sort of. I am currently using Migadu, which works great and I don't plan on leaving. Their selling point is that the amount of domains you add is not limited. It's affordable and reasonable, and a great option as indie dev with multiple projects. No fictional per-seat pricing that does not correlate with costs to the provider.
What I think is outside their target market, but what would be a great next step for projects with slightly more needs would be a Google Workspace/Outlook sort of service with a similar approach. Simple CRM features, shared contact management, calendars, signatures, etc.
Roughly what Proton is doing without the Silicon Valley pricing, or maybe even Hubspot.
I think the main conversation to be had is about incentives.
As operators of app stores, Google and Apple have no incentive to remove shovelware, as they earn a healthy share of every buck made by their creators, at almost no cost.
Similarly, ad networks have no incentives to remove harmful ads, as long as nobody complains enough to cut into profits.
And above all, social media platforms have little to no incentive to remove emotionally manipulative content. It's effectively a symbiotic relationship between the content and "the algorithm".
How do we change the incentives without resorting to censorship? I think the government bodies have in part failed to address these things, because the product to be regulated is information. It's always a slippery slope towards censorship, which makes for a perfect target for lobby work.
The only times I clicked on the picture in picture button in the browser is when I mistook it for the full screen button. I have no idea what I might want to use it for.
> This sounds like "I don't know what a wheel is, but if I chisel this square to be more efficient it might work". Sometimes, it's better to not reinvent the wheel, but just use the wheel.
I'm not sure I can follow. This isn't specific to MP4 as far as I can tell. MP4 is what I cared about, because it's specific to my use case, but it wasn't the source of my woes. If my target had been a more adaptive or streaming friendly format, the problem would have still been to get there at all. Getting raw, code-generated bitmaps into the pipeline was the tricky part I did not find a straightforward solution for. As far as I am able to tell, settling on a different format would have left me in the exact same problem space in that regard.
The need to convert my raw bitmap from rgba to yuv420 among other things (and figuring that out first) was an implementation detail that came with the stack I chose. My surprise lies only in the fact that this was the best option I could come up with, and a simpler solution like I described (that isn't using ffmpeg-cli, manually or via spawning a process from code) wasn't readily available.
> You don't need to know this any more.
To get to the point where an encoder could take over, pick a profile, and take care of the rest was the tricky part that required me to learn what these terms meant in the first place. If you have any suggestions of how I could have gone about this in a simpler way, I would be more than happy to learn more.
No doubt that my limited understanding of these technologies came with some naive expectations of what's possible and how it should work.
Looking into it, and working through it, part of my experience was a lack of resources at the level of abstraction that I was trying to work in. It felt like I was missing something, with video editors that power billion dollar industries on one end, directly embedding ffmpeg libs into your project and doing things in a way that requires full understanding of all the parts and how they fit together on the other end, and little to nothing in-between.
Putting a glorified powerpoint in an mp4 to distribute doesn't feel to me like it is the kind of task where the prerequisite knowledge includes what the difference between yuv420 and yuv422 is or what Annex B or AVC are.
My initial expectation was that there has to be some in-between solution. Before I set out, what I had thought would happen is that I `npm install` some module and then just create frames with node-canvas, stream them into this lib and get an mp4 out the other end that I can send to disk or S3 as I please.* Worrying about the nitty gritty details like how efficient it is, many frames it buffers, or how optimized the output is, would come later.
Going through this whole thing, I now wonder how Instagram/TikTok/Telegram and co. handle the initial rendering of their video stories/reels, because I doubt it's anywhere close to the process I ended up with.
* That's roughly how my setup works now, just not in JS. I'm sure it could be another 10x faster at least, if done differently, but for now it works and lets me continue with what I was trying to do in the first place.
Looks like I have some experiments to run soon.