@Franck_c

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.

• By the way, are you wanting the routing of A and B, to be parallel or series? Is one supposed to feed the other, or be completely separate? Because that will require setting up a bit of routing too!

@dannytaurus

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.

@David-Healey @Christoph-Hart

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.

@scottmire

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).

@Christoph-Hart

@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.

@Morphoice
Ah, no but that is a reason to reset everything!
Under many conditions, changing parameter values all at once can produce monstruous audio. Like, if the DSP effect has feedback, if you don't clear all the buffers, the audio from before the switch, could blow up under the new parameters. There are scenarios that can sound really horrible or blow out your speakers. I mean, let's say the new preset has different reverb parameters, you'll get all the reverb knobs yanked while it's still playing, and get all that washy doppler... Of course that's not a horrible situation, but you can imagine that certain DSP would produce really loud nightmares. Which is why it's quite sane for Hise to send reset() on a preset change, to clear out all the buffers and start from silence. It's the safest thing to do.

But I agree that creatively, there are situations where this is not what you want. But you can understand why Hise went with the blanket solution.

@Morphoice

Hise calls reset() during those changes, so i'm afraid it's Hise actually telling the dsp to clear the buffers! Reverb can't be continuous unless you do some really hacky stuff, like leaving the reset() function empty and using prepare() to cut off tails instead (lots of Daws call prepare() before audio rendering and so that can be used as the reset function) but it just dawned on me that Hise might also might be calling prepare() too when you change presets... not sure.

But If I were you, I wouldn't use any hacky methods like that, because not all Daws will work the same. This seems like a tricky situation! I'm not sure if there is a Hise feature that makes sense, that could be proposed? The fix would have to be in the Hise engine, but it's a bit of an odd feature. So I'm not sure if Christoph would be enthusiastic about it. Maybe worth asking him about this scenario.

I'd probably investigate @ustk 's suggestion first, to make a custom preset system.

@Morphoice
Sounds like an interesting project!
I'm looking forward to seeing the results, this is exactly the kind of thing this project was for.

@Lindon

I was under the impression that Hise has a Hisescript way to probe latency?
And so you could measure it whenever you make a change to the FX stack. But maybe I was mistaken.

If I'm honest with you, in this situation, this is the kind of task I would be lazy and let an AI agent handle.
Although I know already that you might not have something like that set up.
But if it were me solving it, I would be tempted to be lazy and brute force it, use the REST API and Codex, and have it send timed impulses through the empty chain, and then through each FX once loaded individually. That then becomes the lookup table of all the latencies. Do it for different sample rates to find the ones that scale with sample rate. Since its a serial chain, you can basically just add together the latency that each processor give you. I would also entirely discard any latency that is non-linear / different for different frequencies, for individual effects.
I would discard the entire value for that effect, because those are likely nonlinear-phase / group delay latencies and it will actually have a worse sounding phasing if you compensate for those.

That's the lazy route. It's pretty wasteful.
And I suppose you could actually do this by hand too, using the Hise latency finding tool, and write the LUT yourself.

But personally I always keep track of the latency of my own DSP while I'm developing it, so it's never a mystery. But I can only do that because I only use my own C++ DSP in Hise.

An alternative is that you could read through the source code of whatever DSP pieces you are using and find all the delays though (it will mostly be explicit delay lines for lookahead, feedback stabilization, and things like Linear phase oversampling (dont try to compensate nonlinear phase oversampling), and FIR filters, FFT) those all give measurable latency.

But yeah, if there is a Hisescript API for measuring latency, I would assume that is the thing to use! You could even build a LUT using Hisescript and no C++, if that feature exists.