Posts made by ohtravioso

@DanH Thanks. Yes I wanted a very simple install so I wrote some custom code to look for a file called Samples.hr1 in the Application Data folder. If it finds it, it does the automated install, loads the first preset so you don’t need a reboot.

@Tania-Ghosh Yes, looks like several chapters require a premium membership now. I don't recall it being that way.

Thanks everyone! Excited to have it out.

@Rudra-Ghosh I could add a VST3 version. Didn't seem necessary unless there's a DAW that only supports VST3. Also, the project outputs from HISE only support a single VST target, so it's a little cumbersome to go back and reoutput for VST3. I also read from Christoph that there weren't any VST3 features being used.

@yall I'm paying both JUCE and HISE for a commercial license. I didn't want to release my source code or my samples.

@Tania-Ghosh I've been working in JUCE for a while, so making a custom UI in C++ using JUCE was much easier for me than learning the scripting in HISE. Also, it allowed me to build whatever I wanted. There's a good course that's free on Kadenze by Output for making your first audio effect plugin using JUCE.

@iamlamprey Could be conveyed clearer. Basically, at some point, you'll have the downloaded installer and the uncompressed files on disk at the same time. Then you can delete the installer when finished. The 650mb refers to the space you'll need to have it installed. 1.3gb is for during the install, essentially double the installed space.

Proud to release my first sample instrument, BOLD, today. Used a custom JUCE UI and the raw HISE engine. Really happy with how it turned out. Enjoy!

Available for $9 USD.

www.shoutaud.io/bold

Re: ExternalFloatingTile with parameter plugin state saving

@Christoph-Hart I have a nice raw C++ project using the VCSL example.

My knobs use UIConnections to hook up to Processor Attributes. I have my own preset setup using the addToUserPreset method. I’m adding parameters for the host to use as you do in the VCSL example.

1. That approach does not allow the UI to update the host parameters. Only the host parameter updates change the UI as their bound to the same attribute. Is there an example where I would call setValueNotifyingHost as well instead or in addition to using UIConnection?

2. I had to add some methods to use macros. Is there an example of a macro being a Plugin parameter? All the PluginProcessorParameters seem to end up calling setAttribute rather than setMacroControl, and I want the user to automate the macro control, not the individual parameters of the macro.

3. is it possible to put the setIntensity values of pitch modulators into the preset to load? That method is not a parameter attribute of a modulator, just a public method to call on the modulators. And the Data template specializations used in the preset don’t have a version for those.

UPDATE: I added a new method to MacroConnectionListener virtual void macroLoadedFromValueTree(int macroIndex, float value){} which I call when a new value tree is loaded for the macros. My custom component calls setMacroControl on the sliderValueChanged callback, and updates the slider value on the macroLoadedFromValueTree callback.

To watch the parameter, I search for the first parameter for that macro index and set up a parameter watcher, converting the NormalisableRange to a linear 0 to 1 value in the callback.

Since parameters can change with every preset, I set that parameter watcher up at the same time macroLoadedFromValueTree is called making sure to dispatch to the MessageManager for any repaints.

It's not as convenient as a UIConnection class, but it works.

I'm building my UI and modules using the raw C++ approach. The UIConnection::Slider class and Parameter watchers have been helpful for binding my custom controls to the various Processor parameters.

Now, I want to use Macros with my custom sliders to control multiple parameters at once. I've been looking over the code a bit, and I'm not clear on the best way to proceed. I only want to show the custom macro control Not the parameters it controls.

There's no implementation of a UIConnection for a Macro, such that changing the slider updates the macro value, and when the macro changes, not from the UI, my slider gets updated.

I've also used the Parameter Watcher to bind to a parameter in that one way direction to the UI, and that would also be needed for my implementation.

Setting the macro value when moving the slider is simple. But getting updates from the macro when it changes is the challenge.

Any thoughts? I can write a custom UIConnection class, but I don't know how to solve updating the UI only when my slider didn't initiate the change.

I'm Raw.cpp constructor, I'm calling addToUserPreset with various attributes. Is that way you mean?

@Christoph-Hart I worked off your example, and got a raw version of my sampler setup along with all the attributes I wanted in the preset. I was able to use the ProcessorHelpers::restoreFromBase64String() to get modules in the same state as I had them in the HISE app. All works well.

Question is how to restore the loaded preset for a plugin state. Ableton Live is restoring all the samples maps and parameters correct on loading. But the plugin has no idea what User Preset was loaded.

Is that another attribute I store in the preset? The preset file itself? How do I add it so that the preset API restores the value correct from the value tree?

Ah, no. I’m just doing a standard plugin, but I have more JUCE and C++ experience and wanted full control over the GUI.

I thought I could use raw::Builder::createFromBase64State with a HISE snippet, but on the scriptnode branch, looks like that feature isn't complete. So once you go to the hise::raw side of things, you need to create the processor chains in code, rather than in the HISE application.

Processor* Builder::createFromBase64State(const String& base64EncodedString, Processor* parent, int chainIndex)
{
	ignoreUnused(parent, chainIndex);

	ValueTree v = ProcessorHelpers::ValueTreeHelpers::getValueTreeFromBase64String(base64EncodedString);

	// TODO
	// Create the processor somehow...

	Processor* p = nullptr;

	p->restoreFromValueTree(v);

	return p;
}

@coreyu21 What is the headless system build? Is that the exporting from the HISE application? Right now, I'm using that system with all of my code in the AdditionalSourceCode folder. If you didn't use that setup and wanted to go more for a from scratch situation, I believe you'd have some work to hook your HISE objects into the audio callback.

Thanks Christoph. I'll take a look. So if I go the raw route, I can use the HISE application to build up the project, export it as a snippet to use with raw::builder. However, the UI will need to be built up in C++ along with the preset data model. Then I'll need to hide the controls I don't want exposed to the user in a public facing build, but have them exposed in a sound design build.

I ended up using the Projucer from the command line to turn my images into binary.cpp files, and place them in AdditionalSourceCode folder. It works.

I'm using the ExternalFloatingTile tutorial example. I have created custom C++ JUCE controls that call setAttribute on a Processor instance with the slider values mapped appropriately.

In my HISE project, I have added controls to the interface so that they'll be part of the preset format. I hide them before exporting so I can use my custom UI.

When using the plugin in Live, changing the parameters affects the sound but their state is not saved correctly with the Ableton Live project. When loading the project again, the last User Preset is loaded correctly, but the parameter changes are gone, and instead match the state of the preset.

I understand this is happening since the HISE interface controls only go in one direction. When you're using the HISE application, and change an interface knob, the parameter you're controlling updates. But when you change that parameter from its HISE front panel, the interface UI does not update. I'm doing the same thing in my code. Changing the parameter directly and not updating the interface UI, so that the state that's saved is that of the user preset I loaded.

So I can think of a few ways forward continuing to use the ExternalFloatingTile test.

1. Use Macros instead of parameters. I believe those are saved with the plugin state, and modifying those from C++ will do what I need, and update the state that the plugin saves with Live. However, there are only 8 slider macros. That's fairly limiting when you're trying to make a custom UI.

2. Modify HISE code so that the scripted interface controls work bi-directionally. They'll listen for updates to the parameters, and modify their state accordingly. That state is then saved with the plugin. So my custom code can continue to modify the parameters directly, and the hidden interface UI will update as well.

3. Modify HISE code so that all the parameters are saved with the plugin state rather than just macros, loaded preset, and scripted controls. Ideally, that's a separate code path from User presets, and it won't affect them.

Which one of these sound best? Is there a way to do this currently that I'm missing?

When I create an Image in the interface editor and add the image file to it, then the image gets embedded in PresetData.cpp on export. However, how do I access the data to load a juce::Image? It looks like all the images get bundled together under a single const char* for PresetData::images. Anyone know how to load a single image in C++ code from that?

I don't see them anywhere in the exported Xcode project files when I do that. Not in PresetData.cpp or in BinaryData.cpp. Since the image isn't being used, could it be getting stripped out on export?

So I'm using the External Floating Tile Tutorial. I'd like to bundle images so they're part of the BinaryData classes generated by the ProJucer. Where do I put these so they get generated, and not blown away on an export of the Plugin?

If I add them to the Images folder, they don't seem to get picked up. If I put them in the Source/Images folder that contains stock HISE images for dialogs and such, they don't get bundled in either. If I add them manually to the ProJucer file, they'll get added but then that ProJucer file is blown away on export.

Any suggestions?

Ok. I understand better now. You create "User Presets", but they got bundled along as factory content. I have to add controls to the Interface designer, so they're part of the preset. But then I have to hide them when using the External Floating Tile with C++ JUCE GUI. And the presets only affect the single chain you've created, which can involve many samplers you can enable and disable.

That gets a little tedious having to hide and show controls all the time since I don't want any of them to show, but seems to be working.

UPDATE: Small tip is to place all those controls in a single Floating Tile, and then just show and hide that one component as needed.

Thanks. Just to confirm, what's the correct way to get a list of sample maps from C++ for loading when using a custom C++ UI with the External Floating Tile demo? I've turned the sample maps into monoliths and I have two. I'd just like to try switching between them for testing.

Maybe I'm misunderstanding the various formats and the hierarchy.

There's a sample map, which tells a sampler what audio files to play from which midi notes.

But isn't there a preset above that storing all the whole signal chain? I thought I'd be able to load different presets with different signal chains, and thus produce a different UI layout... but maybe not?

Or I'd have to use the Raw C++ approach, and load them as HISE snippets?