Thanks for sharing.
I've found it to not really have any artistic prowess (as to be expected).
But for quickly exploring different UX approaches to the same problem, and being able to swap out different strategies quickly, it's been quite convenient for that purpose!
"Different ways to draw a rack of page tabs"
@Sounddiy
No problem! Good luck!
sometimes you have to change the values specified in the schematic
Not only that, but even if you go so far as to rip the components out of the real circuit and measure them electronically to create a model of each component, it won't be accurate.
Because an assembled circuit behaves differently to a disassembled one! So the true solution is to build mini circuits that are loaded the same way as the specific circuit you are modelling.
The deeper you go into Analog Modelling, the deeper the rabbit hole becomes!
It's not necessary to go to such lengths to create a great sounding product though. You'd be surprised to learn that almost all of Arturia's plugins are not real Analog models but are waveshapers and compressors in certain arrangements... ; )
It's not possible to know the internal levels unless you probe it electronically. You can make a guess if you know the schematics though.
However, you can work it out roughly from audio measurements, if the hardware is nonlinear (which I am assuming it is).
If you use volume sweeps on various test signals, passing into your hardware, you can look at the harmonics and nonlinear behavior at different volumes. And then you can look at your digital model of the same effect, and figure out how to gain stage your digital effect such that it behaves the same as the hardware.
This is something you have to fine tune as you keep developing.
As for impedance, if you have the schematics of the hardware, you can work out the theoretical impedance (of course you won't fully know for sure unless you measure it electronically), and your recording interface will have published impedance specs, so look those up.
In the end, assuming you won't open up the hardware and probe it, this is something you will have to fine tune over time, by looking at the frequency response (particularly high frequency roll off) after you've already done a good deal of the modelling.
TLDR do this stuff while you develop. You can't really do it at the start, so you have to start doing it after you've already done lots of the analog modelling.
The process to follow for all serious good analog modelling is to make a theoretical model first (based on schematics and known facts and basic measurements) and then once you've developed this, you compare to the hardware and now the real work starts: why does it sound different? Why is it so asymmetric in real life? Maybe there is hidden bias in certain places in the circuit? Are certain published "facts" about the hardware design actually not true in practice? Do certain components behave differently when placed in this specific circuit than their published specs and measurements?
This is where the fun begins. But make the theoretical "simple" model first.
Some people mistakenly stop at the theoretical stage. You will sometimes see plugins making claims like "100% created from the real schematics and component values". Not realizing that this is actually very far from accuracy to the hardware and is a gross simplification!
: )
Happy modelling.
@Jeetender
I'll have a look when I have a moment of free time!
@orange
Very cool, thanks for sharing.
I've got DSP but not an example project.
(Automatic resonance suppression needs high-performance spectral processing. I'd use custom C++ DSP for this.)
The algorithm for resonance suppression works like this:
1
Analyse the incoming audio through two overlapping FFT analyses. A short window that can react quickly and a long window that can resolve more narrow frequencies.
2
Smooth the spectrum across the frequencies to get a smoother version. Subtract that from the original spectrum and keep the positive difference. This shows where peaks stand above their surroundings. The louder a peak is, the larger the difference and the more gain reduction you will apply (Alternatively for a more gentle detection approach, compare levels as ratios against a broad frequency response profile instead, so detection depends more on relative differences than absolute level)
3
Now you can use those detected peaks to decide how much to turn down each frequency. This gives you a set of gain values covering the entire spectrum, updated as the audio changes. For example: “cut 800 Hz by 4 dB, cut 3 kHz by 2 dB, leave everything else alone.”
That is one shape containing several cuts.
Apply attack and release ballistics to these gain updates. Attack controls how quickly the cuts deepen, release controls how quickly they return towards no reduction.
4
Turn the set of frequency gain values into FIR filter coefficients.
Pass the audio through the "short stage" filter first, then the "long stage" filter.
If you can live with the latency, apply these filters to overlapping FFT frames and add the filtered frames together.
If you want low latency, keep filtering incoming audio with the latest available filters while analysis continues. Each time you calculate a new filter, crossfade from the old filter’s output to the new filter’s output. The convolution still uses FFTs internally, but the audio doesn't have to wait for a full length frame.
5
Combine the processed signal with the delayed dry signal according to your mix control (you'll need to delay the dry for any latency in the wet path caused by the various filters)
You've put your question in the wrong category, and it's not marked as a question!
Edit your post and do both those things, and you will get answers I'm sure!
As for your question, you can do this via scripting. ScriptFX have a container module called "soft bypass" meant exactly for this kind of thing.
If I have a spot of free time I'll make an example.
Personally I think one of the really good things about Hise is that it's free. And that it wraps Juce.
And so at no cost you can start learning what you need to know about plugin development without being dropped completely in the deep end.
I think there are plenty of people who are still interested in the process of developing audio technology, and I think that HISE fills a useful gap for beginners of this kind.
Personally I was never interested in the codeless aspect, I wanted to get into the weeds with DSP from the start, I just found plain Juce so dry and dull to work in when I was starting out.
Of course, now I don't use Juce either, I ended up going down the Kilohearts/Fabfilter route and use my own plugin core. But HISE (and every other platform / library I used) paved the way to where I am now.
In the present day, a fair chunk of my income comes from rewriting vibecoded projects, and creating LLM harnesses. But if HISE hadn't been around, I likely wouldn't have gotten over the initial tediousness of Juce, which was a necessary first step in eventually reaching the point where I know enough to work on new agentic coding technology.
This is just my personal perspective. Which is probably alternate to many people here.
Agreed, I missed out on the last few meetups, it would be great to have another!
@Christoph-Hart
Didn't know you did work in Japan!
Most of my music work is for the Japanese entertainment industry!
@scottmire said in Vibe Coding Custom Nodes:
Now, I'm trying to do as much as I can on my own without bothering too many people
Feel free to bother me, I could talk about DSP all day. It's already the thing I do day and night.
TLDR At Bottom
It's pretty rough in my opinion.
(But also, take my opinion with a grain of salt, I get a bit serious when it comes to DSP).
I'd say it depends what kind of quality (and efficiency) you are after.
AI can totally make a "working" C++ node very easy, but it won't be that efficient and will have all kinds of artefacts, and there are things that are straight up impossible to develop without investing in additional equipment.
So it comes down to what kind of effect/synth you're wanting to develop, and how much of a purist you are!
(again, this is my opinion) The main issue with Agentic Coding (and especially vibecoding) is that it works by asking the AI to deliver an outcome. And you're then at the mercy of whatever method the AI decides to use, to fill in the gaps in your prompt.
Vagueness and lack of knowledge can be a problem, for example, ask it to create a waveshaper distortion effect. Sure, it will write one, and it'll probably be smart enough to suggest that it needs to be oversampled to reduce aliasing, or use a modern antialiasing technique such as ADAA.
Well, if that's all bundled implicitly into the vague prompt of "make a waveshaper distortion" then it will probably not devote much effort to deriving a good quality oversampler, it probably won't realize that a quick and dirty oversampler can audibly roll off your high end or give you ripples in the frequency response. And there is the tradeoff of latency to consider if you want to go linear phase... And designing the coefficients for an oversampler is an entire research task in its own right. Techniques like ADAA have tradeoffs depending on how exactly this waveshaper is going to be used in your final plugin. For example if this is in a plugin that already has latency, you could probably use a higher quality oversampler and compute it gradually over time, using the latency that the other parts of the plugin are creating as extra time to do processing, massively reducing CPU and allowing you to do a much higher quality result.
But since the prompt was just "create a waveshaper distortion" the AI will likely just throw together the most quick and dirty method, and then hand that back and say "there you go, the waveshaper is done!". And you'll be none the wiser.
For some people this is good enough.
But you can imagine how worse this gets for actually complex DSP.
If we take analog modelling as an example, the current leading industry methods involve measuring DC and other electrical measurements from real real circuits under different conditions in order to get the datasets you need to replicate how components behave when they are actually inside a specific circuit, and to be able to compare your emulation to the real thing and find out why it differs.
But an Agent, if asked to analog model a piece of hardware, is unlikely to tell you anything about this process, and will just "imagine" the measurements and then give you back a program full of made up assumptions, claiming this is a good analog model.
But the thing is, the program will totally work. And lots of people are happy with this, so really it depends.
If you're a hobbyist, it's probably going to give you a result better than you could've made without the AI.
Plus, the "simple" approach the AI takes means it's quite easy to debug, and you won't get challenging cross platform issues or with different hardware not supporting the approach.
And heck, if we are talking about purely creative sound design, then it doesn't matter: maybe that "roll off" in the highs and ripple, are part of "the sound" and people love it.
So there are advantages. But the likelihood for "quality" DSP or low-artefacts is very low.
Since it just skips right to the end result instead of doing the months of research required to produce the kind of work a professional engineer would deliver.
You can tell, I get frustrated with AI, but I'm actually not against using it for audio coding. I just wish it was better suited for the task, because I'm constantly arguing with it and having to give up and do it by hand 
TLDR:
If you're writing stuff from scratch, you might run into problems down the line.
And you might need to end up learning all the DSP theory anyway, just so that you can tell the AI exactly what to do, or complain at it.
On the other hand if you're just porting existing DSP to C++ Scriptnode Nodes, that will work excellently as long as you make sure to tell the AI agent to check that the CPU performance and Numerical Outcome of the DSP is the same as the original code. AI can still make transcription mistakes and end up taking shortcuts that remove optimizations "by accident". DSP is pretty fragile math, subtle changes can end up creating a different sound.
If you're going to do this, I recommend Codex:
https://chatgpt.com/codex/?utm_source=google&utm_medium=paid_search&c_id=24184341331&c_agid=198291088223&c_crid=822139703727&c_kwid=kwd-111182835&c_ims=&c_pms=9208073&c_nw=g&c_dvc=c&utm_campaign=24184341331&gad_source=1&gad_campaignid=24184341331&gbraid=0AAAAA-I0E5dTcdT4kjWBldRGjwm0ADIX7&gclid=Cj0KCQjwxKfWBhDkARIsAMKwkNbDY-zY7xKGSKfYxHXKVElvVZLUsP64_A6UMpZV2h8trCJ-l6ZoeIEaArGXEALw_wcB
@dontoyumur
Software needs to be compiled on the OS that will run it.
A software compiled on Windows will only run on Windows (and depending on how it was coded, it can also depend on the hardware of specific PCs but lets not get into that can of worms).
@dannytaurus
That much is true.
Technically.
Not legally, by the way.
At least not where I am, in the UK.
You can decompile software partially and only in the case that you're making a piece of software that needs to be compatible with the thing you are decompiling. Not so that you can learn it's inner workings for any other reason.
My loophole was to go and talk to a large number of developers about their works.
It cost a lot of money and time to do the interviews, but that's one way to gain a lot of knowledge on a subject, learning personally from the best in each discipline. No decompiling needed.
(sorry Lindon! I've messed up your thread a little)
@dannytaurus
You're probably right, that it's more than good enough for a wide variety of tasks!
The knowledge gaps become an issue in fields where information is less free. And noticeable in fields where small imperfections = failure.
However, I've also had to trundle through quite a lot of entirely vibecoded codebases lately from various clients and there have been some horrible dumpster fires 
lol.
So my perspective is probably a bit tainted by these experiences!
@dannytaurus
That's interesting!
Maybe we are working on different kinds of projects?
I've been using GPT Astra Max, for DSP science. And I've found it to not be "clever enough" with it's coding. Part of the problem is likely that a lot of DSP solutions are proprietary and so there is a gap in it's knowledge, but even when I supply the solutions, the code (or advice) produced, is short sighted, and blocks off many quite important optimizations down the line if I were to take it's advice seriously.
And without a very good measurement harness (super-resolution frequency response, phase, sidebands, etc), it wasn't able to QA audio properly either to realize that its solution was nonsense.
It's the kind of thing where I think many people would take it's word for it as well.
@dannytaurus
For this reason I only ever use AI to advise with code, if it's something with an instantly falsifiable result (eg. that math was supposed to result in a flat frequency response, but we measured ripples, therefore it failed). Making it reason about abstract problems and solutions still performs very badly in the absence of good measurement tools to determine sucess.
Actually, even if an Agent is in a good feedback loop where it can run the code in question, and check the result of its idea, I've found that it still ends up cheating the problem and writing the code in a way that will come back to bite you later, even if the immediate answer is correct.
Perhaps it will continue to improve, the advancements in this field have been speedy indeedy.