@d-healey many ways yes!

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

@Christoph-Hart yes !! Additive synth but a lot more of other DSP weirdo things. Will try the HISE-source-killing way :)

Will take a look to that commit! Thanks a lot Christoph!

You can actually use the normal image handling of HISE in C++ projects. Just make sure that the image is loaded somewhere on your scripted interface before you export, then call

auto myImage = hise::raw::Pool::loadImage("{PROJECT_FOLDER}MyImage.png");

Link Preview Image HISE | C++ API | raw::Pool

C++ API Class reference

favicon

(docs.hise.audio)

You get some benefits over the traditional BinaryData approach: the images are shared across plugin instances and are more compressed.

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.

@Christoph-Hart Was as simple as this :)

String ScriptingApi::Engine::getWhirlpoolHashFromString(String data) { return Whirlpool (data.toUTF8()).toHexString(); }

It's much more secure than SHAs, and since (for the moment) I don't need encryption, a good hash is enough...

@ustk What are you trying to achieve?

@Christoph-Hart Thanks! Will try!

Yes!! Thank you, now works perfect

You need to use a conversion function. If you search for pitch in the API browser you will see the two conversion functions available.

@dustbro that would be awesome :)

@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!

I played around with SOUL which is a new language from the JUCE guys. It‘s supposed to be OpenGL for sound, but it‘ll take some time until it can be used in a production environment.

Yes, I ran into some build errors with both projects. I‘ll post more details later when I‘m back at machine.

@SteveRiggs @dustbro @SteveRiggs Bro Could You Please Supply The .cpp For Limiter And Compressor File So I Can Swap Them With Confidence 🙏🏻 God Bless

@Christoph-Hart said in Copyright protection for subscription based services:

iLok SDK

Excellent thank you for the info Christoph!

@d-healey My approach is to build different versions of Hise, modified and original. This way I have a Hise that is specific for the project I am working on, which can be different from another modified version for another project. Because you might not want the same modifications for all your projects.

I am not talking about GitHub here because I don't know what would be the approach.
So the downside of my technique is that, if the source files are updated with a new version of Hise, I need to manually remodify the new source (but preset browser is not updated that often...).
If you have just a few modifications, it's not an ocean to drink though... :water_wave:

@orange :love-you_gesture_medium-light_skin_tone: :love-you_gesture_medium-light_skin_tone: :love-you_gesture_medium-light_skin_tone: