loadUserPreset - strange behaviour...

[Lindon]

Hey hey hey - lets not descend into this... grief. If the tone of my post was at all uncomplimentary to Dave (one of the most helpful guys I know) then I apologize IMMEDIATELY, AND COMPLETELY

[resonant]

@d-healey yes sometimes very helpful guy I really appreciate that. But sometimes just weird answers. Nothing to bother. I hope he don't get me worng. I am just sayin what I am really offended.

[ossian1961]

@Lindon said in loadUserPreset - strange behaviour...:

@d-healey No you havent been discussing it.. you've been discussing the exact opposite of it. Where you WANT the preset browser to show up properly...well I think that was the essence of the discussion.

..and the IS a need for me to load a preset. I need some form of persistent storage - for authorisation numbers. I cant find any so I was trying this:

On init

load a user preset called "init" , which had the auth number labels saved (they'd be zero)

run the auth function - show the labels and let the user enter their numbers

If the auth numbers are correct - save the init preset (with these numbers in them), then turn saveInPreset OFF for these labels...

It is far from ideal - I NEED some persistent storage!!!! But at least then all the other user presets would not hold the users authorisation keys...

...I confess I'm a bit slow... but, could you explain why you need an authorisation system to load a preset by the user? D'you trying to create a plugin with a code key for protect it by piracy?

[Lindon]

@ossian1961 yes

[ossian1961]

@Lindon You need to protect the plugin, not the presets and if you are going to create a commercial plugin and so protected with a serial key, just talk with Christoph who will help you to create a protection system in that case. That is one of the various help support by Christoph to developers who need a commercial lincensing.

[Lindon]

@ossian1961 wow - if you take a look thru the last few days of the forum you will see answers to all these suggestions...

but just in case:

1. I am using the presets as a (excuse for) persistent storage of authorisation keys, because there is no other mechanism - I ma not protecting presets I am protecting the plug in

2. Christoph's solution is a "call-home" authorisation server - the second most hated authorisation and validation system out there(only PACE inspires more loathing) so its not right for me or my customers.

[ossian1961]

@Lindon said in loadUserPreset - strange behaviour...:

@ossian1961 wow - if you take a look thru the last few days of the forum you will see answers to all these suggestions...

but just in case:

1. I am using the presets as a (excuse for) persistent storage of authorisation keys, because there is no other mechanism - I ma not protecting presets I am protecting the plug in

2. Christoph's solution is a "call-home" authorisation server - the second most hated authorisation and validation system out there(only PACE inspires more loathing) so its not right for me or my customers.

Well, I could advice you to try some software made to protect the software, you can find solutions on CodeProject Forum. You don't need to include that inside the plugin project. Just an exemple:
CodeProjectTopic

[Lindon]

@ossian1961 thank you for this pointer, however, developing a separate stand alone call-and-response based solution is again over kill in my view, plus it definitely does not fit with any of the major distributor networks - who require (at best) a set of pre-built "authorisation codes" to distribute with their sales receipts.

So what I'm trying to do here is find a way of storing IN the plug-in (or in a file I can access from the plug-in) a set of authorisation numbers.

This functionality has been available in Kontakt since at least version 4, so I'm a bit surprised frankly its not in HISE already.

[ossian1961]

@Lindon said in loadUserPreset - strange behaviour...:

@ossian1961 thank you for this pointer, however, developing a separate stand alone call-and-response based solution is again over kill in my view, plus it definitely does not fit with any of the major distributor networks - who require (at best) a set of pre-built "authorisation codes" to distribute with their sales receipts.

So what I'm trying to do here is find a way of storing IN the plug-in (or in a file I can access from the plug-in) a set of authorisation numbers.

This functionality has been available in Kontakt since at least version 4, so I'm a bit surprised frankly its not in HISE already.

You right. I partecipated for this theme on many forums and most of the best developers, at the end, noticed that a "good" cracker will be able to find the way to crack it.

[Lindon]

@ossian1961 then if you were on those forums you will know all sides of the argument.

[ossian1961]

@Lindon said in loadUserPreset - strange behaviour...:

@ossian1961 then if you were on those forums you will know all sides of the argument.

I just wrote those guys said, that's all. They have this problem every days about their work.

[d.healey]

@Lindon

This functionality has been available in Kontakt since at least version 4, so I'm a bit surprised frankly its not in HISE already.

I think the reason it's not in HISE is because until now there hasn't been a use case for it, everything so far can be done through the existing preset system.

[Lindon]

@d-healey Dave, yeah understood, and I'm happy (ish) to use the existing systems - especially if I can get it to work - but right now I cant get HISE to recall any values for any widget.

Lets hope Christoph can point at what I'm doing wrong.

[Dan Korneff]

Hey guys. I'm just starting to add user presets to my project. Having a little trouble getting them to load with a combo box.
I've created 2 user presets in the PresetBrowser, but the interface designer doesn't show any control changes.
Here's what I'm doing:

const var ComboBox1 = Content.getComponent("ComboBox1");

const var list = Engine.getUserPresetList();

inline function onComboBox1Control(component, value)
{
    switch (number)
	{
		case 1:
		Engine.loadUserPreset(list[0]);
		break;

		case 2:
		Engine.loadUserPreset(list[1]);
		break;
	}
};

Content.getComponent("ComboBox1").setControlCallback(onComboBox1Control);

[Lindon]

@dustbro have you checked that list elements contain the correct data? Bit obvious but still...

[d.healey]

@dustbro

    switch (number)
	{
		case 1:
		Engine.loadUserPreset(list[0]);
		break;

		case 2:
		Engine.loadUserPreset(list[1]);
		break;
	}

Use this instead : Engine.loadUserPreset(list[number-1]); it's not a fix to the issue it's just a much shorter way of writing the same thing. Where are you getting number from though?

[Dan Korneff]

@Lindon I believe so:

[Christoph Hart]

Protip: Rightclick on the row in the table to get a popup with the data for arrays and objects :)

[Dan Korneff]

@d-healey said in loadUserPreset - strange behaviour...:

Where are you getting number from though?

I thought the number was the position of the selected combo box?

[Christoph Hart]

@dustbro said in loadUserPreset - strange behaviour...:

I thought the number was the position of the selected combo box?

The combobox has a index starting with 1 because 0 marks "no selection".