Still on audio inputs...
-
@Christoph-Hart I'm digging up this old topic that has raised many threads for a long time.
Since the majority of your actual development seems to be DSP oriented (Scriptnode, JIT/SNEX, rebuilt of some script modules...), I think having inputs available in Hise (be it as standalone or as audio FX) is more than ever a hot topic.
Not having an available live signal doesn't serve Hise's DSP side.
I know you suggested several times the use of an internal generator or sampler, but if this could be a "better than nothing" method in the past reveals to be rather archaic now, especially since live in/out comparison is mandatory for hardware-related work.
I don't see myself exporting an FX each time I am modifying a parameter to measure the result. Because another reason for this is to make real measures of the output (through software or electronic lab) by input comparison.I have no idea of the task such a modification implies though...
What is your position on this, Christoph? -
@ustk I thought the plugin has audio in?
-
I am currently working on something that I've called SNEX workbench, which is basically a separate app that is better suited for DSP development. It shares the codebase (and project management) with the default HISE app, but it will be tailored for the DSP development needs.
The workflow then would be:
- Develop the DSP algorithm in the SNEX workbench. There will be a new project subfolder called DspNetworks (or similar) that will contain XML files for each scriptnode network.
- When the DSP number crunching is finished, create a HISE patch that wraps it in the HISE module tree structure with a UI and everything.
I'm open to feature suggestion in order to adapt this to other workflows, so making a VST-plugin version of the SNEX Workbench to allow live-input should not be too hard. However the workflow that I am currently targetting goes in a complete different direction and that is trying to make an environment which allows you to do reproducable tests:
- Load a file (or create a test signal). You can also add test events like timestamped parameter changes or MIDI messages in order to simulate live input
- Load a DSP algorithm
- Process the file and analyse it using the common suspects (signal graph, FFT, spectrogram, etc).
- If desired, compare the output against a previously created reference result.
The advantage of this approach is that these automatable tests will be able to make sure that the algorithm behaves the same for all possible configurations (different samplerates, buffersizes, JIT compilation vs. interpreted node, etc) and allow some kind of test-driven development.
Exporting the FX each time to measure things is of course out of the question, but you could create reference signals that you then can A/B inside the workbench against the DSP algorithm and doing so gives you the ability to do regression tests.
-
nice! I can't wait for this -
@Christoph-Hart This seems very powerful indeed!
However, I can see two main things that are absolutely necessary at least for me.
The fact we lose:- Scriptnode graphs as I prefer to go this way (stock nodes + SNEX/jit node is so easy to use)
- Hardware real-time parallel comparison (if no inputs)
-
Scriptnode graphs as I prefer to go this way
Don't worry, the graphs will still be there. There is a side-by-side view of the graph and the JIT code that represents the graph and you can switch between the modes on the fly.
Hardware real-time parallel comparison
Yeah, it'll probably come down to a VST plugin version, then you can also hook it up to other analysis tools.
-
@Christoph-Hart Youhou that is absolute killer!
Ice on the cake, do you make 24h delivery at the door for free?
-
How is SNEX for physical modelling synthesis?
-
@d-healey No stop I've switched to effects plugins don't drag me back
