a thought about HISE

[aombk]

HISE is an awesome piece of software. its just not extremely useful to me, since it doesn't quite fit my plugin design.

anyway, I was thinking, since everything seems to be in place, how hard is it to modify HISE into a tool like REAKTOR, MAX , Flowstone that can export VSTs and AUs etc?
MAX was built with JUCE. also JUCE contains that AudioPluginHost project that demonstrates basic node input output connections.
i mean i can imagine it will be a lot of work, its not a petty task, but is it out of the question?
wonder if @Christoph-Hart or anyone else is interested in this.

just a thought.

[d.healey]

@aombk It is possible of course, but it would be a lot of work. I imagine it would require someone to be quite dedicated to the task. I also think it goes beyond the intention of HISE (Hart Instruments Sampler Engine) although HISE has already evolved beyond that original definition to some degree anyway.

[aombk]

@d-healey yes that makes sense, i understand and agree with your remarks. i also believe a great number of people need a tool like that and would be willing to support it.

[Christoph Hart]

I don‘t think that‘s going to happen. The main reason is that HISE is based on a tree data structure mirroring the XML paradigm and any visual programming environment is using a graph (or they fake it to some extend). I chose the tree structure and its close parent-child relation for performance reasons.

But honestly I didn‘t find one scenario which can‘t be done with a tree - actually a graph must be serialised into a processable chain at some point anyway and the tree just makes this step more simple.

[aombk]

"I chose the tree structure and its close parent-child relation for performance reasons."
performance of what?the exported plugin or the HISE editor / compiler?

ok visual graph nodes are very intuitive for visualizing and manipulating signal flows, taking outputs of various nodes and combining them, feeding them back etc. but sure, graphs are not an absolute necessity if HISE provides alternate ways for this routing.
generally @Christoph-Hart , are you interested in turning HISE to a complete framework for effect and instrument development?

[Christoph Hart]

Not sure what makes you think it isn‘t already?

[aombk]

@christoph-hart oh it is? thats awesome! :)

the simplest thing i can think of that i have no idea how to approach in HISE is a delay effect with delay time, feedback, mix, filter type (for the delayed signal) filter frequency and filter Q, all of the above separate for left and right channels. and i would like to modulate feedback, mix, filter frequency and filter Q by separate LFOs.

this can be done in a matter of minutes in a graph / node based environment by using simple building blocks. in HISE i really dont know where to look at. do i make this effect in C++ like you did your modules?
do i need scripting? that script FX? javascript? and if i need scripting for this, what about performance?

@d-healey answered in an older post of mine that i could modulation parameters through scripting but that might not be efficient.

if i should write my own module? why not write my effect using JUCE then?

dont get me wrong im not criticizing HISE, these are honest questions

[aombk]

so, no suggestions?

[d.healey]

@aombk HISE is really great for making instruments, which is what it's designed for. It also has some limited capability (which I haven't explored) for making effects but it's not really the best platform for that as that isn't its main focus. You'd probably have more luck with something like Cabbage, although as far as I know that doesn't provide a node based GUI.

You could write your own C++ module for HISE which would probably be better than writing your own effect from scratch in JUCE because you'd be able to take advantage of the things that are already part of HISE, such as the routing system and existing effects. You could also incorporate your module into the HISE source so that others could benefit from it and build upon/off it.