Passing Large Data Objects into ScriptProcessors

[d.healey]

@aaronventure said in Passing Large Data Objects into ScriptProcessors:

How are they worse than latching onto a referenced parameter via setAttribute?

With Global both scripts must be aware of the global variables. Using set attribute is no different than interacting with any other HISE module. The module doesn't need to be aware of the place (or places) it is being controlled from. It is self contained and can operate independently of the UI script.

[d.healey]

@Lindon said in Passing Large Data Objects into ScriptProcessors:

I think this just doesnt scale....it will be nearly unmanageable

Given Christoph's lack of responsiveness lately I suspect he is busy with some project and you may have a wait for your feature request.

I would flip around the way you are doing things. Currently you have a GUI that you want to pass to a processing script. Instead I would build a standalone arp script and then figure out how to build a GUI that can communicate with it.

I don't know the details of what you are doing but the simplest solution to me seems like a few sliderpacks.

You say there would be 20 sets of controls, and I assume the scale issue would arise if you wanted to add more sets in the future. You obviously don't want to end up with 1000s of sliderpacks. So we need to find a solution to this.

I don't know what your 20 controls are, but assuming each can be represented with a single slider pack, we add 2 slider packs to our arp script. 1 is a visible sliderpack that we interact with and has 20 sliders, the other is hidden, and is used for data storage and can have as many sliders as necessary to store all the data we need, giving us unlimited "virtual" sets.

Then we have a knob to switch between our virtual sets. Pulling values from the big slider pack and displaying them on our smaller slider pack. I can write this for you if you like, it won't take very long at all.

Now on your main UI script you need to add a hidden 20 slider sliderpack, and a knob. You connect these up via processor/parameter ID to the ones in the arp script. You can continue to use your data blob as you currently do in the UI script, and forward that data to the arp script which will do the work. The arp script can also be used independently of the UI script, making it suitable for other projects with different requirements.

Edit: I just saw you said "128 steps, each step has around 20 attributes". So that definitely is more complex... maybe this is a time to use the global object and then take a shower.

[Christoph Hart]

Given Christoph's lack of responsiveness lately I suspect he is busy with some project and you may have a wait for your feature request.

Lol I haven't looked at the forum for 4 hours...

Without understanding exactly what you're trying to do, I would recommend using one of those:

HISE | Docs

(docs.hise.audio)

as a global variable in the Interface onInit array, then create a fixed size array of 128 elements with whatever data structure you need for your arp.

[d.healey]

@Christoph-Hart said in Passing Large Data Objects into ScriptProcessors:

Lol I haven't looked at the forum for 4 hours...

Lol I meant that we hadn't had an update in a week! That's practically glacial for HISE, also you're usually busy with theatre work around this time, no?

[Christoph Hart]

@d-healey ah yeah, no theatre this year, but I have been working on a new feature (a multipage dialog system that will be used inside HISE as well as a floating tile on compiled plugins).

[d.healey]

@Christoph-Hart said in Passing Large Data Objects into ScriptProcessors:

(a multipage dialog system that will be used inside HISE as well as a floating tile on compiled plugins).

Oh yes I saw the commits for the broadcaster wizard. Looks like it will be very helpful.

[Lindon]

@d-healey said in Passing Large Data Objects into ScriptProcessors:

Edit: I just saw you said "128 steps, each step has around 20 attributes". So that definitely is more complex... maybe this is a time to use the global object and then take a shower.

That seems to be the plan.....just using Christophs suggestion for fixedobject array.

[Lindon]

@Lindon said in Passing Large Data Objects into ScriptProcessors:

@d-healey said in Passing Large Data Objects into ScriptProcessors:

Edit: I just saw you said "128 steps, each step has around 20 attributes". So that definitely is more complex... maybe this is a time to use the global object and then take a shower.

That seems to be the plan.....just using Christophs suggestion for fixedobject array.

I predict that at some point in the future someone is going to ask for a way to pass a large data blob into a ScriptProcessor..... :-)

[Christoph Hart]

@Lindon said in Passing Large Data Objects into ScriptProcessors:

I predict that at some point in the future someone is going to ask for a way to pass a large data blob into a ScriptProcessor..... :-)

And I predict that I will respond to it in the same way. Some things can be changed, but this is not the case here, the API needs to be as fast as possible so I can't switch it to a var value.

[Lindon]

@Christoph-Hart said in Passing Large Data Objects into ScriptProcessors:

@Lindon said in Passing Large Data Objects into ScriptProcessors:

I predict that at some point in the future someone is going to ask for a way to pass a large data blob into a ScriptProcessor..... :-)

And I predict that I will respond to it in the same way. Some things can be changed, but this is not the case here, the API needs to be as fast as possible so I can't switch it to a var value.

So maybe an alternative, not using scriptProcessor.setAttribute but say scriptProcessor.setPanelData(PanelId, DataBlob)