Comments by NyquistLimited
Hi there. I'm starting to release my EQ devices individually for $8 each, so you don't need to commit to the full pack without knowing how well they work. If you bought this, please consider leaving your impressions here or in private via Gumroad/Lemon Squeezy. Thanks!
@shinytheshiny: Have you studied the code in detail? Or better yet, have you tried building these yourself, since you claim to know what went into it?
Have you taken me up on my offer to get the devices for free and report back whether they feel low-effort or little added value?
If you do the above, you might understand why it's not safe for you to assume this is a bunch of sloppy vibe-coded devices. Rather than asking your friend Claude (not mine) "build me an emulation of a Neve EQ" and letting it hallucinate some mess that sounds nothing like it, takes your CPU hostage, and is built off of stolen IP anyway, I studied multiple open source codebases by people who know DSP better than myself. I compared the EQ curves with multiple big-name VST emulations of the same hardware. In one case (in fact, the device you're commenting about) this involved porting the code from a different programming language and in the process fixing a mistake in the original filter equations.
The authors of the code that I adapted all had different reasons to release the source: some used to charge for their plugins before open-sourcing them; others built them for their master's thesis. I've been in touch with them and they've been appreciative and supportive. I feel the same when someone builds on my open source code (I've been doing this since before Github existed and we all used Sourceforge).
I've decided when I built my first M4L device that all my code would be open source, regardless of whether I was legally required to do so. Plenty of companies build on MIT-licensed code without releasing any code, and it's all legal. And there's probably enough out there who are infringing the GPL-3 license, knowingly or not. I love that your response is what I get for doing things transparently.
Curious to hear what apparently reinforced your "original assumption".
Have you taken me up on my offer to get the devices for free and report back whether they feel low-effort or little added value?
If you do the above, you might understand why it's not safe for you to assume this is a bunch of sloppy vibe-coded devices. Rather than asking your friend Claude (not mine) "build me an emulation of a Neve EQ" and letting it hallucinate some mess that sounds nothing like it, takes your CPU hostage, and is built off of stolen IP anyway, I studied multiple open source codebases by people who know DSP better than myself. I compared the EQ curves with multiple big-name VST emulations of the same hardware. In one case (in fact, the device you're commenting about) this involved porting the code from a different programming language and in the process fixing a mistake in the original filter equations.
The authors of the code that I adapted all had different reasons to release the source: some used to charge for their plugins before open-sourcing them; others built them for their master's thesis. I've been in touch with them and they've been appreciative and supportive. I feel the same when someone builds on my open source code (I've been doing this since before Github existed and we all used Sourceforge).
I've decided when I built my first M4L device that all my code would be open source, regardless of whether I was legally required to do so. Plenty of companies build on MIT-licensed code without releasing any code, and it's all legal. And there's probably enough out there who are infringing the GPL-3 license, knowingly or not. I love that your response is what I get for doing things transparently.
Curious to hear what apparently reinforced your "original assumption".
Did you take a look at the code (which I open sourced)? Does it look like a low-effort vibe-coded project?
Unfortunately it's hard for end-users to tell between cobbled-together devices with a fancy UI and ones that were made with care to actually be usable in a serious project.
If you contact me in private, I will send you a 100% discount so you can actually test the device
Unfortunately it's hard for end-users to tell between cobbled-together devices with a fancy UI and ones that were made with care to actually be usable in a serious project.
If you contact me in private, I will send you a 100% discount so you can actually test the device
Hi Crampe. I'm glad that, despite a few hiccups, you're getting some good value out of the devices.
Since you had a technical issue with running the install script, can you respond to your purchase confirmation email so we can debug it?
I've also included manual install steps in the User Manual (more in line with other M4L devices).
You're clearly knowledgeable, so here is some info about your other points.
The fixed folder locations are a trade-off to guarantee that the devices integrate well with Live, while avoiding excessive complexity. Although Live's indexing system tracks various file types (such as audio samples), extensions like .nam aren't treated as first-class citizens. Extra care is needed to make "Collect All and Save" work with them, for instance.
Recent NAM captures include loudness information, which Amp Modeler reads to adjust gain before hitting the amp. However, some captures are just intended to be hotter than others, since they reflect different amp settings. There is no well-defined way to adjust their output in real time to match some desired level, without altering the dynamics.
The included captures are a starter pack, but you have thousands of models to explore (both free and paid) within the NAM ecosystem. You might want to curate your own library to prioritize volume consistency.
You're welcome to elaborate more on your ideas. Perhaps shoot me an email?
Since you had a technical issue with running the install script, can you respond to your purchase confirmation email so we can debug it?
I've also included manual install steps in the User Manual (more in line with other M4L devices).
You're clearly knowledgeable, so here is some info about your other points.
The fixed folder locations are a trade-off to guarantee that the devices integrate well with Live, while avoiding excessive complexity. Although Live's indexing system tracks various file types (such as audio samples), extensions like .nam aren't treated as first-class citizens. Extra care is needed to make "Collect All and Save" work with them, for instance.
Recent NAM captures include loudness information, which Amp Modeler reads to adjust gain before hitting the amp. However, some captures are just intended to be hotter than others, since they reflect different amp settings. There is no well-defined way to adjust their output in real time to match some desired level, without altering the dynamics.
The included captures are a starter pack, but you have thousands of models to explore (both free and paid) within the NAM ecosystem. You might want to curate your own library to prioritize volume consistency.
You're welcome to elaborate more on your ideas. Perhaps shoot me an email?
My background is in mathematics and software engineering, including 10 years at Google. I'm now focused on pushing Max for Live beyond typical patch-based devices through optimized C++ externals.
My DSP code is developed in the open, combining and extending existing open-source implementations into a coherent library of high-performance audio tools. I then benchmark against multiple commercial plug-ins to achieve comparable analog character with lower resource usage.
You can read my code at https://github.com/apresta/max-studio-tools. I'll keep this updated as I release more devices. You're welcome to contribute to the codebase or reuse it in your own projects.
Thanks for reading, and please share any ideas or feedback!