RE:engineering: You're spot on, on the engineering side it's dead simple. Simple, reliable, serviceable were all part of the goal.
RE:pricing: Other devices in this category are expensive and several have built-in synth engines and audio cards. This build uses mostly off the shelf components in an effort to keep the price down.
Instagram said I 'violated community guidelines'. Not sure how, I posted a photo of the controller and two videos of it in action. I think my error was following too many people too quickly, maybe lots of external traffic from reddit hurt too?
My guess is that it isn't anything you did other than maybe "grow" too fast and it looked like some kind of spam bot. Just a guess though. I don't know much about how instagram works other than personal use, I post pictures rarely.
My advice is to walk away, use the alternatives like FreeTube, Invidious, etc.
They don't work quite as well in my experience, but you don't have Daddy Google breathing down your neck.
Google doesn't care about you and will never scale their customer service solutions to address this issue, they won't even help people who lost access to their email accounts in any meaningful way.
I will say they have made it increasingly difficult to do that.
Behind VPN? "Log in to confirm you're not a bot."
Someone says the f-word or talks about a no-no topic? (oh no!) "Age restricted video, log in to prove your age."
I find the second one especially hilarious, given that I see borderline porn in the shorts section when I'm not logged in with no browser data for it to drum content up from, and that same screen displays to kids when they pull up YouTube.
"For the children" is always a lie, but it's so funny when it's that obvious.
All that said, I don't quite trust it for some reason, but I've been sandboxing FreeTube and using that, seems to work well generally.
> Behind VPN? "Log in to confirm you're not a bot."
Disable it then.
> Someone says the f-word or talks about a no-no topic? (oh no!) "Age restricted video, log in to prove your age."
Saying fuck is not enough to make it age restricted, and logging in isn't enough to verify your age because they require either a face scan or credit card.
I was hoping this would be more fleshed out as an article, but the sentiment is understandable.
Want to throw some of my knowledge of digital music, as you called it out specifically.
In the late 90s most digitally arranged music production was relegated to trackers (think Amiga trackers) and sequencing samples and loops, because the storage simply didn't exist.
Then that would be committed to tape, sometimes on a 4-track, sometimes on studio-quality tape, sometimes on ADAT.
Fully digital music production like we have now was out of reach for most people until roughly the early-to-mid 2000s, when you see an explosion of people, even in local music scenes, quantizing drum parts and using virtual instruments (usually VST) that would normally require tens or even hundreds of thousands in hardware.
Tracker music was always a hobbyist thing, with a few exceptions. Not really relevant in the greater music scene.
But digitally produced music was of course a huge thing in the 90s. Countless genres of electronic music – techno, trance, house, whatever have you, all of that made on computers. And of course pop was almost all synth – digital synth – just like today.
I was specifically talking about end-to-end digital music production being used to "clean up" recordings per the article. Not whatever "scene" you are conjuring.
> Computers helped you make things louder, cleaner, faster.
For people with limited resources (i.e. indie musicians without huge budgets), digital multi-track recording was not democratized until the introduction of low-cost hard disk storage at sufficient capacity to allow digital multi-track recording at home, roughly around 2002~2003.
Of course I'm aware of synthesizers, etc. I was an electronic musician myself during this period, and I lived it. I had the gear racks, ADAT machines, etc.
We did not have the resources as independent musicians to use non-linear digital editing software broadly until storage became cheaper.
Again, a lot of that music was typically done with looping and sample hits arranged on a midi sequencer, similar to trackers, but with distributed infrastructure.
Listen to older KMFDM, for example, the looping really stands out due to the limited storage they had when arranging, they would arrange sample hits and loops as I was talking about above.
Musicians with studio backing and infinite money could afford giant digital productions suites and were using crude versions of Pro Tools by the early '90s, am well aware.
They didn't mean digital music production, they meant digital downloads/streaming of finished music products. As in later in the early 2000s and beyond iPods and mp3 players and then streaming changed everything as far as accessibility.
That's the trouble isn't it? If we can't even agree on the meaning.
I didn't read it that way specifically because of the use of "you", which to me feels like an invocation of the audience or the royal "you" so to speak, to refer to musicians themselves, rather than the concept of digital streaming and distribution.
"Computers helped you make things louder, cleaner, faster...you still needed a band...or a mate that could actually play something..."
Does the streaming/digital industry no longer have a need for a mate that plays drums? I guess you can read it that way.
Maybe I'm the odd one out, but I read it as almost like a lamenting of the emergence of the "one man band" and cheap throwaway music production by the ease of creating digital recordings at home, and even replacing musicians in the broader music industry with digital replacements, which I also kind of disagree with as being necessarily a negative thing. Toro y Moi, Washed Out, etc., would not be possible without such technology, but the metal music production industry itself has largely replaced drummers with drum machines, not streaming and digital distribution companies.
BTW those of us on the internet earlier were downloading mp3s as soon as 1997 or 1998.
When juniors use LLM, because they don't have experience, it becomes a nightmare for tenured engineers, and we just end up "mopping the slop", as I tend to say.
Just as with an LLM, a detailed style and format guide helps an incredible amount both for the LLMs and juniors. If you have standards and they’re not written down, you either require everyone to go teach them to anyone new, or you don’t have standards.
Not very often, and most of the time it shouldn't be generating those but rather formatting code to test that. If you accept the non-determinism and use some of the more recent models, you'll find it can do 99% of it very fast, and with some guardrails and testing it can fairly reliably produce working solutions.
This does not match my experience, have been working with LLM since 2023. We presently use the latest models, I assure you. We can definitely afford it.
I am not saying LLM is worthless, but being able to check its outputs is still necessary at this stage, because as you said, it is non-deterministic.
We have had multiple customer impacting events from code juniors committed without understanding it. Please read my top level comment in this post for context.
I genuinely hope you do not encounter issues due to your confidence in LLM, but again, my experience does not match yours.
Edit: Would also add that LLM is not good at determining line numbers in a code file, another flaw that causes a lot of confusion.
I had a mid-level submit a PR implementing caching. I had to reject it multiple times. They were using Copilot and it couldn't implement it right and the developer couldn't understand it. Stuff like always retrieving from the API instead of the cache, or never storing the object in the cache after retrieving it.
They promoted that guy over me because he started closing more stories than me and faster after he started using Copilot. No wonder that team has 40% of its capacity used for rework and tech debt...
This matches my experience so hard that I wrote a novel below, have seen this pattern a lot, wanted to expand so people can understand the cycle/pattern.
Let's propose a generic scenario that shows why being able to engineer and read code is still important, and is a story we've all heard or seen a thousand times since the great LLMing of 2025.
"Just deliver the feature/product, we expect `ridiculousMetric` increase in productivity due to LLM" screeching from management and product/business.
A junior engineer will find someone who is willing to rubber stamp their LLM PRs so seniors or designated product experts don't even get a chance to check.
The LLM modifies existing tests to game everything to pass, the junior doesn't know any better, and so it quietly makes it to prod.
Because management is thinking in sprints, the way they see it, the ticket is closed, it's a win.
Then the broken production code, which junior will eventually be promoted for because the ticket is closed on paper, breaks prod, causes a huge outage costing `hugeNumber` dollars to the organization, and senior engineers have to clean it up. To boot, the spend metric is trash because of the LLM not knowing how to scale infra.
Since juniors can't meaningfully debug due to the toxic cycle, seniors spend too much time cleaning things up and it blocks their deliverables, and seniors look bad to leadership. Then they get managed out for not delivering, while the juniors lacking engineering experience due to the toxic cycle continue to rise through the ranks for delivering, even though their deliverables are trash.
I don't blame the juniors, they are under immense pressure and genuinely don't know better.
I blame short-sighted leadership.
I've heard this story from contacts at any of the big names you can think of.
It seems US tech industry is flying head-first into having giant teams of mid and senior level engineers who don't know how to debug or deliver efficiency within the next five years.
We're failing our juniors, and punishing seniors for having standards.
If you don't understand code, you're asking for a whole heap of trouble.
Why? You can't validate the LLM outputs properly, and commit bugs and maybe even blatantly non-functional code.
My company is pressuring juniors to use LLM when coding, and I'm finding none of them fully understand the LLM outputs because they don't have enough engineering experience to find code smells, bugs, regressions, and antipatterns.
In particular, none of them have developed strong unit testing skills, and they let the LLM mock everything because they don't know any better, when they should generally only mock API dependencies. Sometimes LLM will even mock integration tests, which to me isn't generally a super good idea.
So the tests that are supposed to validate the code are completely worthless.
It has led to multiple customer impacting issues, and we spend more time mopping the slop than we do engineering as tenured engineers.
Longtime lurker, made an account specifically to give feedback here as an intermediate speaker. :)
This is a great initiative and I hope to see more come out of this; I am not criticizing, but just want to provide my user experience here so you have data points.
In short, my experience lines up with your native speakers.
I found that it loses track of the phonemes when speaking quickly, and tones don't seem to line up when speaking at normal conversational speed.
For example, if I say 他是我的朋友 at normal conversational speed, it will assign `de` to 我, sometimes it interprets that I didn't have the retroflexive in `shi` and renders it `si`. Listened back to make sure I said everything, the phonemes are there in the recording, but the UI displays the wrong phonemes and tones.
By contrast, if I speak slowly and really push each tone, the phonemes and tones all register correctly.
Also, is this taking into account tone transformation? Example, third tones (bottom out tone) tend to smoosh into a second tone (rising) when multiple third tones are spoken in a row. Sometimes the first tone influences the next tone slightly, etc.
Again, great initiative, but I think it needs a way to deal with speech that is conversationally spoken and maybe even slurred a bit due to the nature of conversational level speech.
The tool definitely needs to address tone transformations, it’s a big part of how the language is spoken. Otherwise it’s mostly useful for a first year student speaking in isolation.
Still having some issues that match my previous comment, I'll try to follow your blog and give more feedback as you work on it.
Will comment that the shorter phrases (2-4 characters long) were generally accurate at normal speed, but the longer sentences have issues.
Maybe focusing on the accuracy of the smaller phrases and then scaling that might be a good way to go, since those smaller phrases are returning better accuracy.
Again, really think this is a great initiative, want to see how it grows. :)
他是 is tāshì which doesn't transform I think. Did you mean to write 你是 nǐshì? I think that transforms differently though. With the half 3rd tone only dropping.
The classical example is 4/4 不是. Which goes bùshì -> búshì.
Or 3/3 that becomes 2/3. E.g. 你好 nǐhǎo becoming níhǎo.
The 1/4 -> 2/4 transformation I think is specific to one. 一个 yīgè becomes yígè.
I remember when first learning Mandarin coming across a phrase '你发福了' which literally compliments someone on blessings (i.e. having become more wealthy) but idiomatically means you gained weight.
I'm inclined to buy once I see others test it (I hate being a beta tester, no offense intended).
$250 for this is *stupid* cheap, given your competitors' *stupid* prices.
Feels like a lot of info is missing here, you getting banned from Instagram.
What was the nature of the post?
edit: Also, have you considered a spring-loaded x-y controller or touchpad x-y controller? I find these indispensable.
reply