These days in my experience most people don't use a sidechain signal, just chop out, or filter, enough of the first base note so that it doesn't clash with the kick. People still refer to it as "sidechain" just because historically that's what it was. Most popular plugin to achieve this is LFOTool but also Shaperbox is used now too which is nice as it lets you cut in frequency ranges in different amounts. Its all about making it gel with the kick. You want your bass to be powerful but in the modern sound you always want the kick to win.
Yes phase alignment is important too. There's always a sweet spot where it just sounds "right". Plus staring endlessly at an oscilloscope to check they aren't interfering. Then doing it for hours and hours and wondering at the end if it sounded better before you started mucking around with it actually but your ears are so tired of it you can't tell anymore.
This stuff is such a rabbit hole. Lots of fun though.
This has reminded me of the awe felt by 12 year old me when someone showed me that you could use a hole punch to make a hole in the corner of a single sided 3.5" disk to double the capacity.
Adult me is now going to go look into how or why that worked.
It feels to me as though LLMs should (eventually?) really shine at these kinds of tasks where the intent is already defined in code of some sort and the challenge of the task is lots of detailed legwork that humans find hard, more because it's time consuming and not interesting so hard to focus on, rather than because it's technically challenging.
So swapping languages, yeah maybe, but I expect of more practical use would be the situation where you inherit a legacy codebase in an ancient version of a language or framework that hasn't been loved in a long time. I saw this so many times when doing dev team for hire work.
Obviously you'd want to do boat loads of testing and there may well be manual work left to do afterwards, but I think it would be the kind of manual work that felt like you were polishing something new and clean and beautiful rather than trying to apply bits of sticky tape to something unmaintainable.
I also wonder about eventually being able to say to an LLM "take this codebase and make it look like my code", or maybe one of your favourite open source developer's code. Maybe everyone could end up with their own code style vector attached to their github profile describing their style. You could find devs with styles close to yours to work on your team, or maybe find devs with styles different to yours so you could go and argue about tabs vs spaces or something.
That's it precisely. I'm working on the exact same thing GPT-migrate is doing, but I'm approaching it from the other direction first. My project is trying to generate a test suite that aims to cover the full original functionality (bug for bug as they say). That way a tool like GPT-migrate has a much better chance of generating the translation without errors and whoever uses it can have more confidence in that the output will be correct.
I'm a bit intimidated that Josh came so close in just a week of work but it's also inspiring confidence that this is the right track and it's actually going to work when all the puzzle pieces fall into place.
edit: damn, this project actually creates rudimentary tests as well. It's such a lean approach, makes me feel like I'm still coding in 2022 when Josh is firmly in 2023.
I agree! This is a pretty elegant approach and while like you I haven't fully internalized the 2023 way of building AI native product, I'm inspired and increasingly confident in how much can be accomplished in a lean way.
> take this codebase and make it look like my code
That's exactly what LLMs don't do. In my experience, there is no way to convince ChatGPT (even v4) to follow any conventions or obey any rules. It might try a bit, but it always ends up writing everything its own way, usually as verbosely as possible.
You are 100% false on this one, especially with GPT-4. I can take entire vanilla JS functions, and ask the language model to rewrite them using typescript, snake case naming conventions, and show it a block of other code that I've written to adhere to the same structure including jsdocs and it nails it nearly every time.
In your example, you are asking GPT-4 to rewrite code from one public style to another public style. I was saying that LLMs cannot reflect your personal style, because they know nothing about it. Even when instructed at length and provided with short examples (that fit in the context window), they always gravitate to the public average.
Then you're doing something wrong because it's exactly what it does for me.
> Given this schema
... some create statement for a table
> Use this as a template
... some unrelated function
> I want you to implement this
... some pseudo code
> So swapping languages, yeah maybe, but I expect of more practical use would be the situation where you inherit a legacy codebase in an ancient version of a language or framework that hasn't been loved in a long time. I saw this so many times when doing dev team for hire work.
I'm exploring this problem space - this is a wide spread pain point across almost all companies that are older than 3 years old. I've seen this at tech startups as well as very large companies and anything in between. Dropbox is arguably a top tier engineering organization that probably manages tech debt as responsibly as can be expected and they still had to make major investments to move their codebase forward from various eras of web tech
1) https://dropbox.tech/frontend/the-great-coffeescript-to-type...
2) https://dropbox.tech/frontend/edison-webserver-a-faster-more...
Everyone else is much worse off so the investment required to move forward is usually immense. This leads to full rewrites. Which is nice but error prone and sometimes entails huge opportunity costs
> Obviously you'd want to do boat loads of testing and there may well be manual work left to do afterwards, but I think it would be the kind of manual work that felt like you were polishing something new and clean and beautiful rather than trying to apply bits of sticky tape to something unmaintainable.
Agreed. In my opinion, now's a great time to get started with a semi automated approach like this while betting that the program synthesis and code generation capabilities will rapidly improve over the next few years. Larger context windows, solutions for hallucinations / reliability and better training data will help reduce the manual labor required.
> I also wonder about eventually being able to say to an LLM "take this codebase and make it look like my code", or maybe one of your favourite open source developer's code. Maybe everyone could end up with their own code style vector attached to their github profile describing their style. You could find devs with styles close to yours to work on your team, or maybe find devs with styles different to yours so you could go and argue about tabs vs spaces or something.
I've been thinking that personal style / training / fine tuning could become somewhat of an asset. "You are a principal software engineer at Google with particular expertise migrating codebases from {sourcelang} to {targetlang}." works fine but imagining a much richer portable input would possibly be quite valuable.
I’ve encountered lots of companies that keep paying license fees to oracle for DBs that could just as well be Postgres but for the work of updating and testing the code…
It grinds my gears a little bit when people pretend that Google came out of nowhere and invented a new paradigm for accessing information and making money by selling ads there.
It was a well recognized problem they solved with Page rank!
It isn't really for learning theory but more for wielding it to write chords.
I use it as a VST in Ableton but you can use it standalone.
I also started learning piano as an adult around 6 years ago and have mostly been trying to use it to understand the theory to compose and improvise rather than perform. The more theory I learnt the more bits of Scaler made sense and I think half recognising concepts from Scaler as my piano teacher was explaining them at the piano was a help.
Also one other thing that I want to stress as I see it - some of theory is based on fundamental truths to do with clashing frequencies but also some of it is just trying to put a framework around what we already know sounds good, and the ultimate rule for music I think is, if it sounds good, it is good. Good luck!
Its been very interesting to watch all of this play out. FTX going under feels somehow bigger than Gox, bigger than the DAO. Gox looked like it was held together by bits of string, the DAO was always something new and had the potential to be a risk, but FTX seeemed safe as houses.
For crypto to exist in the regular world, its always seemed like more regulation of some sort is inevitable. Particularly for a company like FTX with US ties, and it looked like SBF was starting to cosy up to the regulators and fit himself in among the powers that be in the US. His big political donations, sports sponsorships, philanthropic funds. It looked to me like a person who believed in the idealism of crypto was fitting himself into the old world, and all of this lended credence to FTX being trustworthy.
In the end his views on regulation went too far for many and this was strangely the thing that led exposing the dodgy things going on behind the curtain (with the leak of the balance sheet, and CZ saying he would exit his FTT).
That said, Alameda Research, the trading arm, were clearly no slouches, they used to be up there on the Bitmex leaderboard and it seems so hard to grok that they couldn't have modelled all of this risk properly. Accounting for who is holding large amounts of FTT and the price impact that could have.
I sort of feel there must be more to it, or maybe, then again, it just comes down to the same thing that's caused many other crypto funds to blow up - simple greed. The collateral is sitting there, so why use it. What's the worst that can happen?
> it seems so hard to grok that they couldn't have modelled all of this risk properly
I think they did, but their management got greedy and overly hopeful that Bitcoin was going to break 100k last year. This is a trend in crypto for quite a while now: companies get big when the price increases, then get overly complacent and greedy when the market turns.
Remember, you can have perfectly simulated risk assessments, only to have your boss say: "but we want to risk it anyway" and just ignore your protests.
Gox was always dodgy as shit, and FTX felt even more dodgy. Especially its bossman having a raging hardon for tradfi regulations.
> His big political donations, sports sponsorships, philanthropic funds. It looked to me like a person who believed in the idealism of crypto was fitting himself into the old world, and all of this lended credence to FTX being trustworthy.
All of that made FTX seem even less trustworthy to me tbh. Much, much less trustworthy.
I have a beast of a desktop PC but still find myself getting into console games far more than PC games.
I think when I'm at my desk there's always this nagging feeling telling me I could be doing something more productive (code, music, learning) whereas on the sofa with a console I don't feel that.
Ah this looks great. My Dad would buy and sell second hand BBCs and my whole family were well into all of the Repton 3 games. I remember loving discovering the level editor too and proudly making my own themed set of levels which I think scratched a similar itch to programming for 7 year old version of me.
I always thought Repton was the greatest game ever. Am keen to see how it holds up now.
I also remember Imogen being very clever, Citadel I found a bit creepy, and everyone loved Chuckie Egg except me for some reason.
Today I learnt that BBC kids had a weird knock-off of Boulder Dash called Repton instead of a weird knock-off of Defender called Repton. :)
(Wikipedia claims that Beeb Repton was built entirely on the description of Boulder Dash found in a review, rather than actually playing Boulder Dash.)
This is going back a fair few years now, but having played both, my recollection is that Repton is a bit of a different game. The diamonds in are always stationary, and everything else runs in lock step, so there's no chance of outrunning the rocks or the scrolling.
MUD2, the next incarnation of the MUD by Bartle and Trubshaw mentioned in the article is still running and free to play (I believe), http://mud2.com/. I played it on and off from 1994 to 1999 or so. If your character was killed in combat you died dead dead and had to start all over again which made it feel very high stakes when you could spend months building a character only to have to start again.
I decided the only way I'd get it out of my system was to make Wizard which I did eventually (that was quite the phone bill) and I stopped playing a little while later. I've never really got into another online game since.
I seem to remember some gaming service in the UK trying to make a client for MUD2 with some graphics to try and give it more mainstream appeal. It didn't really work. I do remember the conversation of "I wonder if it's possible to make a MUD but with graphics?" came up in the teamroom chatter from time to time.
Now my kids play Roblox, which is also kind of amazing in its own very different way. It has the social element of a MUD (although my kids mostly know the people they play with in real life first), and its a gateway to programming, but all the experiences are far more lightweight and short lasting whereas I think the land of MUD2 has left some kind of lasting impression with me.
I use black by default across all our projects now and I'm all for it, but it does seem kind of ironic that whilst the main selling point of black is to take away these kind of code style discussions there seem to have been way more of them since black came to popularity :)
I do expect it'll just be fine once everyone's got used to it. Maybe its a consequence of a tool like this coming into existence on a language with such a long history already.
I don't think it increased the amount of discussions, just centralised it. Before it would happen between developers in the same repo, now it's all in the same place.
I think that a good thing. Formatting discussions are important (arguably), but it should be decoupled from a specific project.
Yes phase alignment is important too. There's always a sweet spot where it just sounds "right". Plus staring endlessly at an oscilloscope to check they aren't interfering. Then doing it for hours and hours and wondering at the end if it sounded better before you started mucking around with it actually but your ears are so tired of it you can't tell anymore.
This stuff is such a rabbit hole. Lots of fun though.