Good idea, thanks!

Our JUCE module contains most of the stuff you need to handle licensing & delivery:

License activations (more on this later) Time-limited trials Offline activations Update notifications on new releases Analytics back to Moonbase (optional, stuff like host/daw/etc meta)

Our licensing flow is a bit different than most, we want the smoothest process we can, and so what it does is just open a browser on your website, where our web SDKs take over the process and activate plugins on the website. Since customers are usually already logged in to your website, since they made a purchase, downloaded your plugin, or whatever else, we can immediately activate the plugin.
We have a video of this flow, including the default UI of the JUCE module in our BSA customer story: https://moonbase.sh/stories/blacksaltaudio/

Having customer authentication on your website is a really good way to also provide a fully personalized storefront experience, where we can showcase segmented pricing, enabling loyalty discounts and a bunch of other cool things.

The biggest hurdle to adopting our JUCE module in HISE projects is the fact that it depends on JUCE version 7. I'm not the original author, but I know there's probably two things that would need to change for a downgrade to JUCE version 5 (which I think HISE is still using?):

The device fingerprinting needs to change. We had issues with the older JUCE (< v7) fingerprinting in cases where we crossed ~100k devices, where we saw collisions and unstable fingerprints. I believe we're also using some utilities from the newer URL/HTTP classes, but I'm not 100% certain of this.

Generally, it's not a super complex module, but it is very battle-tested, powering hundreds of thousands of plugin installs.

@ulrik awesome

@d-healey said in SoundSync: Reseller, Security & Serial Management Platform:

@trillbilly said in SoundSync: Reseller, Security & Serial Management Platform:

Im working towards a complete audio plugin/product backbone that allows developers (new and old) to quickly and reliably manage the entire backend of the business (and some development tools).

Sounds similar to Moonbase

Thanks for the shout-out! I'm Tobias, the founder of Moonbase.
Won't hijack this thread, welcome any competition in this space - it needs more modern options!

I believe we have 3-4 HISE users already onboarding onto Moonbase, integrating the JUCE module, but I'm not sure about the current status. It will need some changes here and there, but nothing too major I hope. I tried reaching out to @Christoph-Hart a while ago after we met in Berlin, but didn't hear back. Maybe it's time to re-visit a collab here? :)

Interfacing with resellers better sounds like a really cool approach, and something we have on the roadmap too. It gets tricky fast to get a grasp on actual cashflow and revenue sources when you have sales scattered across several channels, including your own. Happy to share any experience we have doing software sales @trillbilly !

@Orvillain I'm ignoring all the UX suggestions and minor glitches as I'm completely unsatisfied with how it behaves at the moment and I will have to do a third or fourth complete redesign of the UI of this thing.

The only glitch I see in this video is that if you have more than 2 groups (eg. 5 or 8) it still only performs 3 groups - probably it knows that there is no sample in the last group and then it resets the counter, but I'm not sure why it does that.

But in general it's expected that you use as much RR groups as you have RR variations, so you're already in weirdo land if you use more RR groups than samples.

Now if you have different amounts of round robin variations within a single samplemap you can achieve this by using multiple RR layers - which is where this complex system starts to show its strength, for simple RR stuff you don't need that in the first place.

So let's assume you have closed hi hats and open hi hats in the same sample map. For closed hi hats you have 8 RR variations, but for the open hi hat you only have 6 RR variations. You cannot setup a single RR layer to work with both types, instead you need to create 2 RR layers:

One for the closed hi hat samples with 8 groups One for the open hi hat samples with 6 groups

And then we assign the closed hi hat samples to be cycled by the first layer and the open ones by the second. Now comes the important part: in order to tell HISE which samples are subject to which layer you can use the Ignore flag (so in this case both layers need to have the ignore flag enabled). This works like this:

Assign the closed hi hats to their respective group in the first layer Assign the open hi hats to their respective group in the second layer Assign all closed hi hat samples to the ignore group in the second layer Assign all open hi hat samples to the ignore group in the first layer.

Note that this idea can be combined with any layer so you can create very complex group arrangements. If only the UX would make it easier to understand that stuff...

@DanH said in Preset Browser - List item background:

@ustk ok back on this again 😆

What would be a crafty way of adding multiple 'tags'?

So the preset name could be something like BA_LD_PRESETNAME to indicate that it's a bass as well as a lead sound.

Maybe some kind of divider is needed...

Really I watch this sort of discussion a lot here, that can be characterised as "how to bend the preset browser to my will". My experience is that its nearly trivial ( a few days at most) to write your own custom preset browser...

@griffinboy can you give me an example with screenshot? my english its so bad and i think that the google translate its giving me wrong traduction

@Chazrox

Ahh, I see! Thanks duder!

@DanH @Christoph-Hart Wish he told us 120 parameters ago... 🤣

@Straticah I’ve noticed that communicating MIDI information in FL Studio is particularly frustrating (actually I find most things about that DAW frustrating but that’s beside the point). Does this solve the issue in your particular case?

Link Preview Image Typing keyboard not working on plugins

favicon

(support.image-line.com)

@Christoph-Hart is the Notch filter display (in Scriptode) a fiddly fix?

@Orvillain apparently, the problem is in the Reaper itself, everything works fine for me on version 7.23.

I would like to know about this as well. To my knowledge I have not seen a commercial MIDI plugin that can route directly to and from MIDI ports/drivers, but I do remember that the two MIDI plugins here called "midiIn" and "midiOut" attempt to do this:

Link Preview Image pizmidi/pizjuce at main · sleiner/pizmidi

A collection of helpful tools when working with MIDI - pizmidi/pizjuce at main · sleiner/pizmidi

favicon

GitHub (github.com)

Some of the plugins are buggy, so I do not know if they work or not.

I think some of the challenge on Windows is that host apps can gain exclusive control over a port, and I know DAWs like Cubase/Nuendo are aggressive in this regard, but there are utilities to multiply port connections (such as MIDI-OX, Virtual Cable or Bidule), and therefore making it possible for multiple hosts to access the same MIDI input/output.

I would love it if you found a way to do this in a plugin. On an app I believe you should just be able to have access to the output ports from any of the MIDI devices as long as it is not in use by another app (I think it is first-come-first-serve in that regard).

@d-healey Thank you so much
@ustk @Christoph-Hart 👍

@d-healey I did compile it from source (my first time compiing anything as well) and it was the develop branch. Maybe I'll compile it once more just in case I did something wrong.

Thanks for your help, David! I can't believe how fast you responded. I hope to have more meaty questions in the future.

@Christoph-Hart Is there a possibility to remove the shadow from the Favorite Icon next to the preset in the default Preset Browser?

@pcs800 You're referencing the panel like this:

const var displayPanel1 = Content.getComponent("Panel1");

But you are assigning it incorrectly:

Panel1.setPaintRoutine(function(g)

And then later you have a second paint routine which would just overwrite it anyways

displayPanel1.setPaintRoutine(function(g) {

Also you have a bunch of timers set to the panels to repaint them which isn't really the most efficient. It would be better to use the knob's control callback to repaint them like I do in my example.

Probably worth looking into the examples here a bit:
https://docs.hise.dev/scripting/scripting-in-hise/scriptpanel.html#the-paint-routine

@d-healey @Oli-Ullmann haha yes that's why I will leave it up. I think I learned about this before (watching David's video) and just sort of forgot about what the boolean was for. 😆

@Christoph-Hart
I just saw that you fixed it. Thanks very much! :-)
I'll let you know if I encounter any problems.

@Chazrox
Glad you like it. To be honest, there's not that much to do, since @Christoph-Hart has already done all the hard work for us.

Creating the WaveTable:
All you have to do is fill a buffer, which you then load into the WaveTable synth using the WaveTable controller.

Christoph has provided us with some examples in the documentation:
https://docs.hise.audio/scripting/scripting-api/wavetablecontroller/index.html

Appearance:
To make the whole thing look interesting, I drew a panel based on the slider values of a slider pack. The slider pack is transparent and the panel is behind the slider pack.

So you use the values of the individual sliders in the paintRoutine of the panel.

@paper_lung check the MonolithSplitAmount parameter inside the xml converted to monolith samplemaps. If the value from there is higher than you have in the archive parts, then the sampler will not find the monolith. There is indeed a bug in Hise that can add the previous values of the parts of the split monolith when exporting to the monolith. I recently report this bug. But is no actually for fix. Maybe this with low priority, if you have this bug - you can fix it by yourself.