AI capex may or may not flatten in the near future (and I don't necessarily see a reason why it would). But smartphone capex already has.
Like smartphones, AI chips also have a replacement cycle. AI chips depreciate quickly -- not because the old ones go bad, but because the new ones are so much better in performance and efficiency than the previous generation. While smartphones aren't making huge leaps every year like they used to, AI chips still are -- meaning there's a stronger incentive to upgrade every cycle for these chips than smartphone processors.
Lifetime curve is something they can control. If they can predict replacement rate, makes sense to make chips go bad on the same schedule, saving on manufacturing costs.
Operating a car (i.e. driving) is certainly not deterministic. Even if you take the same route over and over, you never know exactly what other drivers or pedestrians are going to do, or whether there will be unexpected road conditions, construction, inclement weather, etc.
But through experience, you build up intuition and rules of thumb that allow you to drive safely, even in the face of uncertainty.
It's the same programming with LLMs. Through experience, you build up intuition and rules of thumb that allow you to get good results, even if you don't get exactly the same result every time.
> It's the same programming with LLMs. Through experience, you build up intuition and rules of thumb that allow you to get good results, even if you don't get exactly the same result every time.
Friend, you have literally described a nondeterministic system. LLM output is nondeterministic. Identical input conditions result in variable output conditions. Even if those variable output conditions cluster around similar ideas or methods, they are not identical.
The problem is that this is completely false. LLMs are actually deterministic. There are a lot more input parameters than just the prompt. If you're using a piece of shit corpo cloud model, you're locked out of managing your inputs because of UX or whatever.
Ah, we've hit the rock bottom of arguments: there's some unspecified ideal LLM model that is 100% deterministic that will definitely 100% do the same thing every time.
We've hit rock bottom of rebuttals, where not only is domain knowledge completely vacant, but you can't even be bothered to read and comprehend what you're replying to. There is no non-deterministic LLM. Period. You're already starting off from an incoherent position.
Now, if you'd like to stop acting like a smug ass and be inquisitive as per the commenting guidelines, I'd be happy to tell you more. But really, if you actually comprehended the post you're replying to, there would be no need since it contains the piece of the puzzle you aren't quite grasping.
Strange then that the vast majority of LLMs that people use produce non-deterministic output.
Funnily enough I had literally the same argument with someone a few months back in a friends group. I ran the "non-shitty non-corpo completely determenistic model" through ollama... And immediately got two different answers for the same input.
> Now, if you'd like to stop acting like a smug ass and be inquisitive as per the commenting guidelines,
Ah. Commenting guidelines. The ones that tell you not to post vague allusions to something, not to be dismissive of what others are saying, responding to the strongest plausible interpretation of someone says etc.? Those ones?
> Strange then that the vast majority of LLMs that people use produce non-deterministic output.
> I ran the "non-shitty non-corpo completely determenistic model" through ollama... And immediately got two different answers for the same input.
With deterministic hardware in the same configuration, using the same binaries, providing the same seed, the same input sequence to the same model weights will produce bit-identical outputs. Where you can get into trouble is if you aren't actually specifying your seed, or with non-deterministic hardware in varying configurations, or if your OS mixes entropy with the standard pRNG mechanisms.
Inference is otherwise fundamentally deterministic. In implementation, certain things like thread-scheduling and floating-point math can be contingent on the entire machine state as an input itself. Since replicating that input can be very hard on some systems, you can effectively get rid of it like so:
ollama run [whatever] --seed 123 --temperature 0 --num-thread 1
A note that "--temperature 0" may not strictly be necessary. Depending on your system, setting the seed and restricting to a single thread will be sufficient.
These flags don't magically change LLM formalisms. You can read more about how floating point operations produce non-determinism here:
In this context, forcing single-threading bypasses FP-hardware's non-associativity issues that crop up with multi-threaded reduction. If you still don't have bit-replicated outputs for the same input sequence, either something is seriously wrong with your computer or you should get in touch with a reputable metatheoretician because you've just discovered something very significant.
> Those ones?
Yes those ones. Perhaps in the future you can learn from this experience and start with a post like the first part of this, rather than a condescending non-sequitur, and you'll find it's a more constructive way to engage with others. That's why the guidelines exist, after all.
> These flags don't magically change LLM formalisms. You can read more about how floating point operations produce non-determinism here:
Basically what you're saying is "for 99.9% of use cases and how people use them they are non-deterministic, and you have to very carefully work around that non-determinism to the point of having workarounds for your GPU and making them even more unusable"
> In this context, forcing single-threading bypasses FP-hardware's non-associativity issues that crop up with multi-threaded reduction.
Translation: yup, they are non-deterministic under normal conditions. Which the paper explicitly states:
--- start quote ---
existing LLM serving frameworks exhibit non-deterministic behavior: identical inputs can yield different outputs when system configurations (e.g., tensor parallel (TP) size, batch size) vary, even under greedy decoding. This arises from the non-associativity of floating-point arithmetic and inconsistent reduction orders across GPUs.
--- end quote ---
> If you still don't have bit-replicated outputs for the same input sequence, either something is seriously wrong with your computer or you should get in touch with a reputable metatheoretician because you've just discovered something very significant.
Basically what you're saying is: If you do all of the following, then the output will be deterministic:
- workaround for GPUs with num_thread 1
- temperature set to 0
- top_k to 0
- top_p to 0
- context window to 0 (or always do a single run from a new session)
> The problem is that this is completely false. LLMs are actually deterministic. There are a lot more input parameters than just the prompt. If you're using a piece of shit corpo cloud model, you're locked out of managing your inputs because of UX or whatever.
When you decide to make up your own definition of determinism, you can win any argument. Good job.
Yes, that's my point. Neither driving nor coding with an LLM is perfectly deterministic. You have to learn to deal with different things happening if you want do do either successfully.
> Neither driving nor coding with an LLM is perfectly deterministic.
Funny.
When driving, I can safely assume that when I turn the steering wheel in the direction in turns. That the road that was there yesterday is there today (barring certain emergencies, that's why they are emergencies). That the red light in a traffic light means stop, and the green means go.
And not the equivalent "oh, you're completely right, I forgot to include the wheels, wired the steering wheel incorrectly, and completely messed up the colors"
> Operating a car (i.e. driving) is certainly not deterministic.
Yes. Operating a car or a table saw is deterministic. If you turn your steering wheel left, the car will turn left every time with very few exceptions that can also be explained deterministically (e.g. hardware fault or ice on road).
Claiming "completely" is mapping a boolean to a float.
If you tell an LLM (with tools) to do a web search, it usually does a web search. The biggest issue right now is more at the scale of: if you tell it to create turn-by-turn directions to navigate across a city, it might create a python script that does this perfectly with OpenStreetMap data, or it may attempt to use its own intuition and get lost in a cul-de-sac.
Wow. It can do a web search. And that is useful in the context of programming how? Or in any context?
The question is about the result of an action. Given the same problem statement in the same codebase it will produce wildly different results even if prompted two times in a row.
Even for trivial tasks the output may vary between just a simple fix, and a rewrite of half of the codebase. You can never predict or replicate the output.
To quote Douglas Adams, "The ships hung in the sky in much the same way that bricks don't". Cars and table saws operate in much the same way that LLMs don't.
> Wow. It can do a web search. And that is useful in the context of programming how? Or in any context?
Your own example was turning a steering wheel.
A web search is as relevant to the broader problems LLMs are good at, as steering wheels are to cars.
> Given the same problem statement in the same codebase it will produce wildly different results even if prompted two times in a row.
Do you always drive the same route, every day, without alteration?
Does it matter?
> You can never predict or replicate the output.
Sure you can. It's just less like predicting what a calculator will show and more like predicting if, when playing catch, the other player will catch your throw.
You can learn how to deal with reality even when randomness is present, and in fact this is something we're better at than the machines.
The original example was trying to compare LLMs to cars and table saws.
> Do you always drive the same route, every day, without alteration?
I'm not the one comparing operating machinery (cars, table saws) to LLMs. Again. If I turn a steering wheel in a car, the car turns. If input the same prompt into an LLM, it will produce different results at different times.
Lol. Even "driving a route" is probably 99% deterministic unlike LLMs. If I follow a sign saying "turn left", I will not end up in a "You are absolutely right, there shouldn't be a cliff at this location" situation.
Edit: and when signs end pointing to a cliff, or when a child runs onto the roads in front of you, these are called emergency situations. Whereas emergency situations are the only available modus operandi for an LLM, and actually following instructions is a lucky happenstance.
> It's just less like predicting what a calculator will show and more like predicting if, when playing catch, the other player will catch your throw
If you think that throwing more and more bad comparisons that don't work into the conversation somehow proves your point, let me dissuade you of that notion: it doesn't.
There are plenty of non-blockchain, non-NFT, non-online gambling, non-adtech, non-facist software jobs. In fact, the vast majority of software jobs are. You can refuse to work with all of these things and not even notice a meaningful difference in career opportunities.
If you refuse to work with AI, however, you're already significantly limiting your opportunities. And at the pace things are going, you're probably going to find yourself constrained to a small niche sooner rather than later.
If your argument is that there are more jobs that require morally dubious developments (stealing people's IP without licensing it, etc.) than jobs that don't, I don't think that's news.
There's always more shady jobs than ethically satisfying ones. There's increasingly more jobs in prediction markets and other sorts of gambling, adtech (Meta, Google). Moral compromise pays.
But if you really think about it and set limits on what is acceptable for you to work on (interesting new challenges, no morally dubious developments like stealing IP for ML training, etc.) then you simply don't have that FOMO of "I am sacrificing my career" when you screen those jobs out. Those jobs just don't exist for you.
Also, people who tag everybody like that as some sort of "anti-AI" tinfoilhatters are making a straw man argument. Most people with an informed opinion don't like the ways this tech is applied and rolled out in ways that is unsustainable and exploitative of ordinary people and open-source ecosystem, the confused hype around it, circular investment, etc., not the underlying tech on its own. Being vocally against these matters does not make one an unemployable pariah in the slightest, especially considering most jobs these days build on open source and being anti license-violating LLMs is being pro sustainable open-source.
> There's always more shady jobs than ethically satisfying ones. There's increasingly more jobs in prediction markets and other sorts of gambling, adtech (Meta, Google). Moral compromise pays.
I would say, this is not about the final product, but a way of creating a product. Akin to writing your code on TextPad vs. using VSCode. Imo, having a moral stance on AI-generated art is valid, but AI-generated code isn't, just because I don't consider "code" "art".
I've been doing it for about 20 or so years at this point, throughout literally every stage of my life. Personally, I'd judge a person who is using AI to copy someone's art, but if someone is using AI to generate code gets a pass from me. That being said, a person who considers code as "art" (I have friends like that, so I definitely get the argument!), would not agree with me.
> Most people with an informed opinion don't like the ways this tech is applied
Yeah, I'm not sure if this tracks? I don't think LLMs are good/proficient as a tool for very specialized or ultra-hard tasks, however for any boilerplate-coding-task-and-all-CRUD-stuff, it would speed up any senior engineer in task completion.
> I would say, this is not about the final product, but a way of creating a product.
It is the same logic as not wanting to use some blockchain/crypto-related platform to get paid. If you believe it is mostly used for crime, you don't want to use it to get paid to avoid legitimizing a bad thing. Even if there's no doubt you will get paid, the end result is the same, but you know you would be creating a side effect.
If some way of creating a product supports something bad (and simply using any LLM always entails helping train it and benefit the company running it), I can choose another way.
That is because your views appear to align with staunch progressives. From rejecting conservative politics ("fascism"), AI, advertising, and gambling.
From my side the only thing I would be hesitant about is gambling. The rest is arguably not objectively bad but more personal or political opinion from your side.
There seems to be some confusion. I wouldn't call conservative politics as a whole fascist, that's your choice of words. I doubt that "anti-AI progressive" is a thing too.
> The rest is arguably not objectively bad but more personal or political opinion from your side.
Nothing is objectively bad. Plenty of people argue that gambling should be legal if anything on the basis of personal freedom. All of this is a matter of personal choice.
(Incidentally, while you are putting people in buckets like that, note that one person very much can be similtaneously against gambling and drug legalization and be pro personal freedom open-source libertarian maximalist. Things are much more nuanced than “progressive” vs. “conservative”, whatever you put in those buckets is on you.)
It is just from my experience that political discussions online are very partisan. "fascism" in relation to the current US government combined with anti-AI sentiment is almost always a sure indicator for a certain bucket of politics.
To play devil's advocate: all the people using AI are not being significantly more productive on brownfield applications. If GP manages to find a Big Co (tech or non tech) which doesn't precisely bother about AI usage and just delivering features, and the bottleneck is not software dev (as is the case in majority of old school companies), he/she would be fine.
I'm sorry but it simply does not cost a million dollars to maintain Tailwind, a CSS library that has no compelling reason to ever change at this point.
> Electricity prices near data centers go up, right?
I hear this a lot, but the most comprehensive study I've seen found the opposite -- that retail electricity prices tend to decrease as load (from datacenters and other consumers) increases [1].
The places where electricity prices have increased the most since 2019 (California, Hawaii, and the Northeast) are not places where they're building a lot of new datacenters.
I can generally get maintainable results simply by telling Claude "Please keep the code as simple as possible. I plan on extending this later so readability is critical."
Yeah some of it is probably related to me primarily using it for swift ui which doesn’t have years of stuff to scrape. But even with those and even telling that ios26 exists it will still at least once a session claim it doesn’t, so it’s not 100%
The "obvious" solution that I think you're describing is the Hammersley sofa (1968), which has A=2.2074.
For a long time, it was thought this might be the optimal shape, but it was never proven. And it couldn't have been because it turns out that you can do better: the Gerver sofa (1992) is a more complicated shape, composed of 18 curve segments and has A=2.2195.
Nobody knew whether there might be an even better shape until now (assuming the proof holds up).
You're getting at the crux of the issue: it's very hard to distinguish legitimate DMCA takedown requests submitted by individuals from illegitimate ones, and occasionally, they're going to make mistakes. Anything that the author said in his emails could have just as easily been said by someone else who was trying to take down the content illegitimately.
At the end of the day, the best option is to use an attorney who knows the right procedures and would also run the risk of professional consequences if they submitted false claims.
> Anything that the author said in his emails could have just as easily been said by someone else who was trying to take down the content illegitimately
Ok, but then Google needs to say what would convince them that the author is who they say they are. The author asked multiple times how they prove they’re the real author and Google’s replies never even acknowledge the question.
> Anything that the author said in his emails could have just as easily been said by someone else
That's not true. He mentions that he is the owner of the books official websites, which are registered with Google, presumably with all of his personal and billing information.
It would take 2 seconds for anyone at Google to confirm this.
> It would take 2 seconds for anyone at Google to confirm this.
Not really... Google is literally too big, and the fact that they've offshored and/or automated support away and compartmentalized it all where no single IC employee could possibly do much.
I had a billing/tax issue come up with my small biz Google Workspace, and I was getting nowhere via the normal support channels... So I asked my brother in-law who literally works at Google (but not in that team) for help. He could not help me as he had no idea who or what department could handle that and neither did his team members, and it would take weeks apparently to find the right person. I'm not the only paying Google customer with that experience. Google products are great, until you run into an issue you need to talk to a human.
They could have been Slack if they didn't transmogrify it into a social media platform (Google+) and then throw out the baby with the bathwater when it failed.
I’m talking about something much more fundamental, the entire company would pretty much implode within 24 hours (or at most a week) if they couldnt verify who is who.
You're really giving credit in the wrong areas. Google is impressive for its ability to exist beyond the point of dysfunction. It's simply not the case that any Googler would need to verify the identity of any other any more than it is necessary for every server to verify the identity of every other. They only need to verify the identify of the tiny subset they are communicating with at any given time. This doesn't mean everyone has access to a coherent org chart, or that one even exists.
> Ask their managers? But then how do their managers verify?
It's a hierarchical org chart. If you're really not sure ask Sundar.
It's likely any Googler can verify the identity of any other by looking up their username but it's unlikely that the same tool would do something like tell you how the YouTube recommendation algorithm works or who would know that.
They will know the names of frequent collaborators and something about the scope of relevant work but it's not like everyone at Google needs intimate knowledge of every workstream. At that scale it's unlikely anyone has the full picture.
We agree an org chart of some kind probably exists. We disagree on the capabilities. For example I am not confident that it has a concept of a team and if it does that a team would map to a product or feature.
Going from person to team is fairly easy, but going from team to person is hard. That is, you can often confirm a person is a member of a particular team or organization just by looking up their email address, but the reverse direction of finding the right point of contact for a particular team or organization can be difficult.
Searching for the tree root starting from a tree leaf is easy, but searching for the right leaf starting from the root takes a lot more effort.
Aside from the huge array of stuff they've built in house, the "List of mergers and acquisitions by Alphabet" wikipedia page has 264 entries. Some of those bought other companies.
>If googlers dont have an internal org chart they can check, then how do they verify who is on what team?
You really think some guy in some offshore office for low pay, with his boss hounding at him about his KPIs, is going to go out of his way to bother with this?
I don't like it, but the solution here is to hire an IP lawyer to handle the rights process.
Google won't talk to us normies because 1) it's a cost and they don't have to 2) they've convinced themselves that if they tell anyone anything, then the unwashed masses will take advantage of their process/get the service we're owed under law
Google settled a massive lawsuit with Viacom many years ago. The details of the settlement are hidden, but it seems pretty clear that it involves extraordinary deference to large rightsholders who in exchange won't threaten to blow YouTube to smithereens every year.
Sounds like they need to spend some of those billions of dollars on fixing the process and complying with the law, then.
I don't get to ignore the law just because if I follow it, someone who doesn't might get one over on me.
All of this nonsense because Google wants to automate their DMCA takedown process and not hire anyone to deal with real cases as they come, as is their duty to copyright holders.
I have a different reading, the author is reminiscing to the times where trust worked on the web.
A company like Google could trust you for being really the author because who would lie? and those that lie about these things usually couldn't spell or use technology.
The world changed and now Google can't afford to trust someone that says he's the author, because people take advantage of that.
So if you ask me what's worse, this guy having to contact his publisher to get his book off the web, or someone being blackmailed to keep his youtube channel, imo they are right to require a proper lawyer
I wonder if they just prioritize big companies who they either have agreements with or are scared could actually cause them serious legal trouble, and deny everyone else as much as possible because they’ve calculated the risk/reward/cost of getting it wrong.
Google doesn't need to verify anything. They just have to pass along the takedown request and provide a flow for prompt reactivation with a counter notice. After that their responsibilities end and the two disputing parties can litigate.
> The DMV is not a private company with enormous amounts of fraud/scam.
So it sounds like their policy of having a high bar for proving identity but still publicising what is required to meet that bar works for preventing fraud?
If anything, your argument is an indictment against Google.
That's Kafkaesque. We're not talking about SEO here, just simple proof of identity. If they require something sane like ID, they could simply say so. If they need something insane, or have no process at all for proving identity, then this is no excuse.
In this case, a more likely explanation might be "Google won't do this because it would put you in a position to obligate them to do something else". There isn't really a risk of enabling scammers to issue false DMCA takedowns; as you note, that issue is resolved by requiring proof of ownership.
If that were true, how would the judge know who to rule for? Are you saying that anyone can become the owner of any intellectual property simply by filing a lawsuit?
Not all intellectual property is the same. Trademarks have to be registered, patents have to be filed, but copyright is automatically granted by law whenever someone creates a work.
Trademark issues are therefore really simple: is the user of the trademark the one who has it registered or not?
But copyright holders don't have any standard, obvious evidence they can point to that shows it's really their copyright. They can file a DMCA, in which case companies normally just assume the complaint is accurate - but if the party on the other end objects, the case has to go to a judge who will determine who actually has the copyright and if infringement occurred.
Also, the ones abusing the system tend to know it better: often it's their jobs to figure out how to work it to get what they want. The people who just want to use legitimately often it don't have the time and experience to learn it.
(You see a similar thing with benefits and healthcare: often attempts to crackdown on people abusing the system just make it harder for legitimate users)
If you are from US I want to let you know about a scam. Here in asian countries people with good enlgish accents are recruited to pretend to be US citizens and claim benifits that are unused by the real people. There is a whole proper process of how this works. The recruit is given full identity information and a software to make the call appear from the US. The officials on the US side are in on this and get a share for each successfull claim.
I suspect the author is self-published (I don’t know him well, but his emails seem to indicate this).
One of the things that you get, when dealing with a publishing house, is a bunch of IP lawyers on speed-dial.
If you register works with the LoC, it might help in these situations (it isn’t required, but this is exactly the type of thing that it’s supposed to address).
That's little more than corruption. Yeah sure, you can free your issue from the AI-washed auto-reject script if you know the right people. But it's nothing to do with what those people know. It's about who they are.
The whole point of the DMCA takedown process is that it's rubber-stamp on the part of the service provider and all decisions regarding validity are left up to the courts. That's why there's a provision built into the law for the person receiving the claim to file a counter-notice to get their content reinstated. If Google is inserting themselves in the middle and denying claims because they don't believe that the person filing them is authorized to do so, I'm not sure whether that's proper procedure under the OCILLA.
You are completely missing the point. Mistakes can be made. But OP asked repeatedly what he must provide so Google can validate his identity. They didn't answer his questions, even after OP asked multiple times.
> At the end of the day, the best option is to use an attorney who would at least run the risk of professional consequences for submitting false claims.
What if folks signed their work with a private PGP key and published their public key? If you wanted to submit a DMCA request, simply sign a message to prove you’re the content owner. It seems like that could work.
Let’s consider a scenario where you’ve published a video with a public key, and you have a history of using that key for publishing your work. If someone else were to download that video, they wouldn’t be able to sign it because they lack the key. I believe the same principle applies to PDFs and ebooks.
Not the other way around. And since the timing is only given with millisecond accuracy, the bpm should be rounded to the same number of significant digits:
Huh. Get out your red string and pushpins because this inspired a theory.
So if the correct pair of values there ends up being 445 / 216.27000197, then it'll be:
60 * 445 / 216.27000197 = 123.456789
Or, since one of those programs had four decimals:
60 * 445 / 216.27015788 = 123.4567
Or, if it's 444/446 rather than 445:
60 * 444 / 215.78415752 = 123.4567
60 * 446 / 216.75615823 = 123.4567
But I see that they cut the "whooshing intro" at the front, which I imagine is part of the beat — they're in the hands of the machine now, after all! — so if we retroactively construct 123.4567 bpm into the silence (which, they estimate, is 5.58s):
5.58s * (123.4567bpm / 60s) = 11.4814731 beats
Assuming that the half a beat of slop silence there has to do with format / process limitations with CD track-seeking rather than specific artistic intent, we get:
+11 intervals @ 123.4567 bpm = 5.346s
Which, when added to the original calculation, shows:
And so we end up with a duration of 221.616 seconds between the calculated 'first' beat, a third of a second into the song, and the measured 'last' beat from the post:
60 * 456 / 221.616 = 123.4567 bpm
Or if we use the rounded 123.45 form:
60 * 456 / 221.628 = 123.45 bpm
And while that 22+1.628 is-that-a-golden-ratio duration is interesting and all, the most important part here is that, with 123.4567bpm, I think it's got precisely 0.2345 seconds of silence before the first 'beat' of the song (the math checks out^^ to three digits compared against the first 'musical beat' at 5.58s!), and so I think there's actually 456 beats in the robotic 123.45 song!
:D
^^ the math, because who doesn't love a parenthetical with a footnote in a red-string diagram (cackles maniacally)
Not sure if it adds anything, but a factoid I know is that CD timing is expressed in minutes, seconds, and frames, where each frame is 1/75th of a second.
I'm not sure but I think this is also the smallest time resolution.
Then each frame is composed of samples, but they seem to be counted in groups of 1/75th os a second anyway.
I was also wondering about the inherent resolution for the BPM precision claims.
Besides the sample period, the total number of samples matter for frequency resolution (aka BPM precision).
44100 Hz sampling frequency (22.675737 us period) for 216.276 s is 9537772 samples (rounding to nearest integer). This gives frequency samples with a bandsize of 0.0046237213 Hz which is 0.27742328 BPM.
Any claim of a BPM more precise than about 0.3 BPM is "creative interpretation".
And this is a minimum precision. Peaks in real-world spectra have width which further reduces the precision of their location.
This takes my flac rip of the CD and simply uses the full song waveform. This artificially increases frequency precision by a little compared to taking only the time span where beats are occurring.
This is plainly false though. You're saying beats can't be localized to less than one second of precision (regardless of track length, which already smells suspect). Humans can localize a beat to within 50ms.
Yes, I got lost in the numbers and made a blunder by misinterpreting what we mean by frequency resolution expressed in "BPM" instead of Hz.
It is correct to say "0.0046237213 Hz which is 0.27742328 BPM". My mistake was to interpret 0.27742328 BPM as the limit of frequency resolution in units of BPM. Rather, any BPM measured must be an exact multiple of 0.27742328 BPM.
Thanks for pointing out my mistake!
> (regardless of track length, which already smells suspect)
Frequency resolution being dependent on the number of samples is a very well known property of basic sampling theory and signal analysis.
In fact, one can interpolate the frequency spectrum by zero-padding the time samples. This increases the resolution in an artificial way because it is after all an interpolation. However, a longer song has more natural frequency resolution than a shorter song.
Note, this frequency resolution is not related to fidelity which is some messy human related thing that is over a sliding window of shorter duration that I don't pretend to understand.
BTW, the opposite is also possible. You can zero-pad the spectrum as a means of resampling (interpolating) the time domain. This is slower but more spectrally correct than say time-domain linear or cubic interpolation.
These techniques require an FFT and so are somewhat expensive to apply to long signals like an entire song, as I did for the plot. Daft Punk's HBFS takes about 8 seconds on one CPU core with Numpy's FFT.
> And to confuse matters more, in a 2013 interview with Time Magazine, Bangalter says:
> > So we've never actually made music with computers! [laughs] Neither Homework nor Discovery nor even Human After All were made with computers.
> Was he contradicting himself from 12 years before? Or did he forget? Or maybe it's a terminology thing?
The thing is—and this is coming from someone who has been making electronic dance music daily for over 35 years and counting—when Bangalter spoke earlier in their career about a PC (likely an Atari ST or Falcon) it was being used as a MIDI / SMPTE timepiece and master sequencer, nothing more. Later when he speaks about never making music with a computer, the context of the discussion has changed, as by that time computers were becoming more accomplished at DSP. The comment he is making is that they didn't use computers for audio domain tasks, like Pro Tools, Digital Audio Workstation type action.
That said, computers were still deeply embedded in their workflow just not in the way most modern producers would recognize. Even the SSL 9000 J console at the heart of their studio relied on an onboard computer system for total recall, automation, and channel configuration. The distinction Bangalter draws is really about where the actual audio lived: in 12-bit sampler memory, on tape and through analog audio circuits, not as samples and waveforms being crunched inside a CPU. The computer was a conductor, not a performer.
PS: All of this got me thinking about the past and dislodged a bunch of memories from my old crusty techno battered brain.
In that early interview where Bangalter loosely mentions their production setup: an E-mu SP-1200, an MPC3000, and "Logic on a PC." He doesn't specify what kind of PC, and he doesn't say who made the software—just the word "Logic." One thing is for sure he wasn't talking about an Apple computer or software product.
I was working in studios around Europe in the late '90s and if you said "Logic" in a studio context, you were certainly talking about Emagic Logic, and "PC" didn't mean a Windows box. In that era, particularly in France, "PC" was often used colloquially to mean any Atari ST or Falcon, which had been the backbone of European electronic music production for a decade. Given Daft Punk's roots in the French house scene and the timing of Homework's production (1996-97), there's a strong chance they were running Emagic Logic on Atari hardware, because at the time, the ports of this program to other platforms were garbage and were not to be trusted.
The lineage of the software is an entire saga unto itself. What became Apple Logic started life as C-Lab Notator on the Atari ST in the late '80s which dominated Euro electronic music. In late 1992, after a dispute with C-Lab's owners, the core developers, one of whom was Apple's own Gerhard Lengeling, walked out and founded Emagic. They rewrote everything from scratch as Notator Logic, which eventually dropped the Notator prefix and just became Logic.
Around '02, Apple came knocking and swallowed the whole operation. They immediately killed the Windows version, and dropped the Emagic branding entirely with Logic Pro 7. Like I said, Gerhard Lengeling is still at Apple, now their 'Senior Director of Software Engineering for Musical Applications' according to his LinkedIn.
Like smartphones, AI chips also have a replacement cycle. AI chips depreciate quickly -- not because the old ones go bad, but because the new ones are so much better in performance and efficiency than the previous generation. While smartphones aren't making huge leaps every year like they used to, AI chips still are -- meaning there's a stronger incentive to upgrade every cycle for these chips than smartphone processors.
reply