@inlandempire
You're completely right.
This was posted before I got any good at filters. It's far from accurate to the Oberheim filter - I was naïve when I posted this. This here was my first attempt to match the filter, and didn't factor in any nonlinear components in the circuit.

It sounds like you've found some odd issues. It's possible that I wrote the node wrong and that it's become outdated as Hise updated - this was also released back when I had very little experience with writing nodes for Hise... This is to say, don't expect too much from this filter. I personally wouldn't use it now.

I'll be releasing more free dsp in the near future, so if you're interested in filter designs, my better filters will be available in hopefully not too long.

@Oli-Ullmann

Thanks very nice!
I don't think it's particularly new technology wise, but all the options they've given to the user are wonderful.
Most WT synths already have the tech behind the scenes, but it's not touchable by the user. These guys have managed to give it a really nice GUI and expose all the controls.

Same can be said for a lot of synthesis features really. There's still a fair amount of useful but untouched possibilities that haven't been given a GUI.

@dannytaurus

My first plugin will be released at the end of this year
It's been a few years since I started development on my largest synth which was before pivoting to Hise (It's been 6 years already!? geez), and I think I'm only halfway through developing it still. So it's time to put together a smaller mvp and get something released already! It's been long enough.

Good luck to everyone

@PJSanre

It completely depends on quality, and how long you want development to take.
The EQ + megaphone + Delay stuff can be commissioned cheaply (I myself would do it cheaply anyway), Autotune and Reverb are the heavyweight tasks. You can expect it to cost around a thousand each for those two pieces of dsp.

The absolute cheapest path would probably be around a thousand?
That's really pushing it though. This would be if you were willing to use the stock Hise EQ, stock hise convolver for megaphone effect, stock hise reverb, stock delay, and have the autotune be the main piece of custom commissioned dsp.

However, that's just dsp costs.
There are potentially (but not necessarily) more costs than just dsp, for a project like this.

For example, if you don't want your project to be GPL open source licence you'll need to pay the Hise and Juce liscence fee costs.
There is also the matter of creating your GUI and Installer, and getting a codesigning liscence for Mac and Windows / any other platform you plan to release on (codesigning makes it so that your software won't get immediately flagged or blocked by default security / antivirus software).

Developing a piece of software is a step up from making presets, you should be prepared for the trouble involved! That being said, it is possible, and a dsp engineer will be able to make custom dsp to match your patcher preset, that part is completely possible, it's just down to cost and time!

@PJSanre

Nope not with visual coding.

You need custom dsp for this. You can do those processors if you get hold of c++ stuff to plug into Hise, or get a developer.

Autotune and good reverb is the kicker.

Both of those are 'life's work' type effects that take years to develop from scratch, and so nobody likes to give out their implementations of those for free.

Megaphone effect you can do in default hise using the built in convolver if you're willing to use convolution. EQ can be done that way too, or using the stock hise EQ (It's not an amazing eq I don't reccomend it) but it would work.

I'm a perfectionist so take all of the above with a grain of salt. Maybe there is a mediocre but easy way to do it that I've never considered. But I'm fairly confident that you're out of the scope of the built in hise modules. 100% Definately out of reach if you don't want to code at all.

@lijas90

Absolutely possible.
Hise has built in (simple) audio players and oscillators. It's possible to send audio right into your scriptfx and listen to the result.

Also notice the option to render output to disk in the Hise toolbar settings at the top of the app I think it was under tools

@Christoph-Hart

Is this the recommended method to use for modulating a c++ node? Works with the matrix modulation system and such? I've been needing to investigate the best way to do modulation.

@ustk

I only know for windows DBG works. Using the VS debug console prints

Have you asked gpt about it? I have a feeling it will know

@Christoph-Hart

Nice work

@ustk

Ah yeah you'll be fine linearly interpolating the waveshaper curve. The one thing to watch out for maybe is cases where you want discontinuities. Linterp will very slightly smooth those, you may want logic to preserve jumps. Like you said, the actual drawing of the curve by the user is of limited fidelity / accuracy, and that's the real limit.

I'm doing all sorts of interpretation in mine to assume intent from the user.

@ustk

For getting started, just using linear interpolation will be usable.

When you take in your table, sample it to a table of like, 2048 or 4096 samples using linear interpolation. And then you can read it using linear interp too for different speed playback.

It will be aliased, but for use cases like slow modulations, it doesn't matter terribly. Like, if its an LFO, it won't be unusable with alias.

For antialiasing, it's a complex ordeal.
See this paper:
http://www.mp3-tech.org/programmer/docs/resampler.pdf

@ustk

I resample it into discrete sample values.
It's the same idea as wavetable synthesis oscillators, or a sampler. We end up with a waveform shape sampled to the amount of samples we want.

You'll incur aliasing if you don't take measures against that.

@ustk @HISEnberg

jokingly
If we make this a contest, I'll just be putting my table through my super strong antialiasing resampler. Can't beat antialised tables...

That said, we could probably pump out a hell of a table, if we pooled our resources lol

@ustk

haha indeed, we have the same system.

@ustk

Idk if you have used a different strategy, but the way I'm doing it, is sending only the control points and tensions into c++
Since the GUI code only contructs the graph at the resolution it needs to for each segment, there is no point calculating a high resolution graph on the hise side of things.

The c++ then constructs the actual modulation shape in high resolution to be used for audio processing.

@Oli-Ullmann

Indeed, that's my thinking. It would be nice for table 2.0!

Although, I'm likely to do it custom no matter what, as is my preference for high control!

@HISEnberg

It's hisescript.
Currently only integrated for custom c++ projects with my custom modulation source.

@DanH

it's not quite integrated with hise fully.

If we could get Christoph to adopt one though, that of course, would be better.

@DanH

I have one

If we could get Christoph to adopt one though, that of course, would be better.

@dannytaurus

Multiple wavetable synths will use a lot of memory.
Christoph's WT engine creates mipmaps (multiple antialiased copies of the wavetable).
If you have multiple WTs loaded into separate WT engines simultaneously, each one will have multiple copies of the wavetable.

However, this memory is probably still small compared to say, a regular multisampler... However 100 wavetables is gonna get big I can imagine you could pass the GB mark of ram usage.

Can't speak for cpu, you can try it but I'd assume cpu is okay as long as you don't have the inactive synths do any processing when silent.

If you are trying to acheive clickless swapping or something (idk if the WT engine does this already? Or what your goal is with having multiple WT engines - fast loading maybe??? No silence dropout???)
You could just have two WT engines, keep one silent, and use the silent one to load the new wavetable, once ready, volume fade between them. Then you get a seamless handover to a new engine.