Questions about RawTest example

[newage_lightbulb]

Hello, I have seen the posts from Christoph saying he is working on turning the engine into an API. While I await that exciting development I am trying to use the raw test example, but encountering a few significant problems:

• The instructions refer to creating a 'dummy interface'. I followed the tutorial instructions and created one - click the interface button - but I can find no way to make it save. I switch to the interface editor and I see a script with only "Content.makeFrontInterface ..." but there is no 'save project' menu item, saving XML and archives doesn't persist the interface to the next project load, etc. So I don't think the interface is actually being created. And looking at the other tutorial examples I don't see an interface in the master chain. So this is a bit confusing.
• After adding the placeholder interface if I build the RawTest project it errors out on a few pure virtual functions (createEditor, exportAsValueTree, restoreFromValueTree) and a couple of functions with no declarations (createRawEditor, saveStateRaw, loadStateRaw). Those all seem related but I don't know how one maps to the other; for example how would RawDataBase::createEditor be able to call createRawEditor? Is this something meant to be hooked up in the interface designer/script?
• There are also compile issues as the sample refers to RawDataHolder. This was relatively easy to fix by changing those references to RawDataBase ... just FYI
• In general, will there be a way to use the functionality without any interface and without Juce? For example, to load a custom instrument and programmatically play back notes?

Any help would be appreciated.

Thanks!

[Christoph Hart]

If you add a interface and save it as XML, it should definitely retain the interface if you load that XML again. Just note that a HISE project is a folder that can contain multiple XML / .hip preset files and you have to load one of these explicitly (if HISE doesn't ask you if you want to load it automatically after switching projects).

The interface doesn't appear in the module list because you have a InterfaceDesigner and it was constantly creating issues (performance, UX wise), which is why I disabled it about a year ago.

If you try to export it it will definitely throw compile errors because it expects you to subclass hise::FrontendProcessor::RawDataBase and return an instance of it that also creates the plugin editor - you're instance has to override createEditor() and the plugin will call this method to create your custom UI - this is the exact same procedure as with juce::AudioProcessor.

In fact, the RawTest example is already outdated since I have changed the API but forgot to update the example - the one that is supposed to work is the VCSL demo project I used for the ADC presentation here:

GitHub - christophhart/vcsl_hise: The VCSL - HISE Edition

The VCSL - HISE Edition. Contribute to christophhart/vcsl_hise development by creating an account on GitHub.

GitHub (github.com)

Just load the project's VCSL.xml, set the UseRawFrontend flag in the settings dialogue and export.

But be aware that the API and everything in the hise::raw namespace is very WIP and subject to many backward-compatibility breaking changes during the next months - right now the basics are somehow there but I need use-cases to figure out how to generalise the functions.
I will use it for a few very complex projects in the future and along this process the API will be hardened.

About your last question: you definitely won't be able to use HISE without JUCE since it heavily relies on it, and with the current API it is not particularly straightforward to embed HISE into a bigger application / existing projects, but I get this as request a lot so maybe I'll think about a way to do this.

But your use case should be doable with a bit of manual effort - just create some sort of sequencer in C++ load MIDI files (I think there are JUCE classes for that) and call processBlock with the MIDI buffer filled with your MIDI data.

[paul]

This post is deleted!

[jariseon]

@Christoph-Hart
hi,
i created a pull request in vcsl_hise repo to make its raw version compile against the current HISE master (commit 8ef678e on May 23, 2019). tested on macOS Mojave 10.14.6, and somewhat ancient Xcode 9.3.

but which branch should i actually use for c++ development when eventually targeting production? i guess master would be a safe bet, but i've also seen here that develop and scriptnode branches (with a specific commit) are in active use as well. thanks!