@jdurnil

I shared a basic c++ fft framework that I created for hise on the forum a while ago. It's possible to do fft stuff in hise using libraries / doing it from scratch.

What does your project need to do with the fft?

@ustk

python, julia or matlab is your friend.
There are many scientific libraries for LUT generation, which can do curve fitting and other clever thingies.

I have an entire custom app built in python that can reverse engineer waveshapers from any linear shaper vst. I've reverse engineered many algorithms automatically using this tool.

BTW, use JuceVectorizedMath if using c++
You can do multiply add operations on a whole buffer. Efficient.

@ustk

C++ or snex is the only way I'd do it.
Waveshapers are about mapping raw samples to other values. It's inherently low level dsp since you are manipulating each sample. Simple low level, but lowlevel nonetheless.

for dc offset, there are a few filter designs that are suited particularly to removing it. You can find source code online for them.

LUT waveshapers are something I've done lots in c++
I use python to prototype them and generate a fat array. Then yeah, linear interp between data points, as well as making sure to clip the input so that it can't go over the edges of the waveshaper.

@pcs800

Something to keep in mind though, is that the XML isn't the project.
Saving an xml is like saving a 'picture' of what the project looks like (eg, what modules are there, what order are they in)

But the actual project is the whole folder that is created and saved when you use 'create new project' in Hise, PLUS the xml contained in there.

When you open a project in Hise via xml, it's essentially looking at where the xml is located, and finding all the other project files around it. It's loading a ton of other stuff that makes up the project, just using the XML location as a reference point.

If you make drastic changes to your project, and save an xml beforehand and afterwards, the xml may not be enough in order to recall your backup. Since they are actually existing in the same project. For example if you delete an audio file from the project, that will disappear from the audiofiles folder in the project files. Even if your old XML wants to reference that audio because it remembers it being there, it will not be able to bring it back.

The point is this: Keep your project files separated! If you want to back stuff up, duplicate the entire project folder. Like people are saying, you can use tools like Git for this.

If you are only changing what modules are used where, and the hisescripts, then this data will be saved in the XML and you can backup stuff like this. But other things such as compiled effects. audiofiles, graphics etc are all stored in the project files and the XML does not contain them.

@Allen

I haven't had the chance to revist this yet

@Christoph-Hart Did we ever get an update for the compile time parameter callbacks? A bit higher in this thread, a solution was proposed to accommodate arbitrary parameter counts.

@d-healey

Interesting.
Okay I've never done this before I didn't know set attribute could be used that way.
I'll have a go

@pcs800

Yes, I've never had a problem opening past projects I have over a hundred in my active folder and I switch every day.

The new hise project opener UI is likely what has caused confusion. There are many things you could've done wrong / misunderstand about the way hise projects work, so it's hard to know exactly what has gone wrong for you. The interface for loading projects is very new and didn't use to exist. It probably gives the illusion that the hise saving system works like any other software, but in truth it's a bit more manual work. Different saving options in hise save different parts of a project. Some overwrite, some create copies, some save only the scriptnode networks some save only the structure of the project, etc etc.

It's something I only figured out myself after making mistakes, and manually reading through the files that hise saves.

Create a new project, save the xml.
Now create an additional new project, and save the xml.

You should now have two different folders which bear the respective project names.

To load in one of the new projects, use the load project option and navigate to the first layer of a projects folder. Hise will then open the project using all the project files it's not just the xml or hip that it uses.

@d-healey

Probably because I'm a fool and I didn't get how to call it in the natural state

@d-healey

I'm not sure I get it!

What I'm trying to do is trigger code.
Say I have an array inside a midi processor inside of a scriptnode synth.

If I wanted to clear the array using a button on the main UI, I don't see any way of doing so!

Since code that exists in the interface script is not in the same scope as the scriptnode synth. Since that's the whole point of the encapsulation I guess

@griffinboy

So, my workaround has been to use global variables to pass stuff between the synth scripts and the UI.
This works, but idk if it's optimal. And it's not a callback, but this way I can edit data that belongs to the scriptnode synth in the main UI script, since the data is global...

@ulrik

Recently had to do this myself and took a moment to figure it out, hence,
leaving this additional example here.

// Spawn a background task to hard-stop all voices
 const var bt = Engine.createBackgroundTask("KillAllVoicesTask");


// Call this to kill voices
inline function killAllVoices()
{

        bt.killVoicesAndCall(function()
        {
            // nothing
        });
}

@pcs800

Projects are saved as separate folders with the project name.

Xml files are not projects.
They contain some of the code data associated with the project, such as the UI scripts and the modules.

The xmls are a way to backup these elements of the project but don't contain the entire project itself.

You've likely messed something up, file organisation wise.

How can I get a midi processor to react to a UI control?

I've got a scriptnode synth, and I need a callback or listener of some kind, so that when I change a control on the UI, the scriptnode synth Midi Script Processor knows that there has been a change.

The purpose is to kill all voices and reset some arrays for the scriptnode synth when a control is altered.

@Morphoice

I'm not sure whether vsts are aware of the fact that they are bypassed.

They might be. But I'm not sure I remember seeing any vsts that react to that, apart from native ones to the daw.

If so, nobody would ever accidentally be tweaking things while accidentally bypassed

Edit: seems that I stand corrected!

@d-healey

Or c++ / snex

But two samplers is the easy way I'm sure.

@Christoph-Hart

Good to know that it wasn't anything bad. It didn't seem to be breaking anything.

Is it okay for me to use this function then? It says that I shouldn't here unless I'm rendering. But I couldn't really see why, so I've been using it

@ulrik

I used c++.
I created a script that would accept a 'target' pitch offset value and glide towards the target always.
Then I use event data writing in Hise, and a reader node attached to the c++ pitch target param.
So now I have polyphonic control over voice pitches.

It's a similar method to the hise snippet that @aaronventure made for controlling pitches with event data continuously

@griffinboy

edit* I created a workaround for this for now, so it's not urgent.
But I'll leave this up for curiosity sake

@griffinboy

edit* Rephrased into a more answerable question hopefully!

I've been exploring the hise event system.
I think this is a clever function.

I'm wondering if scriptnode synths can receive it? Is it propagated to them? I've got a c++ node that I would like to read the data from this.

I've noticed that sticking a vanilla hise oscillator into a scripnode synth does not react to it, but the default (non scriptnode) modules do, such as the sine generator.

Synth.addPitchFade()