LAF + Sampler Functions

[trillbilly]

@d-healey it's all starting to make much more sense.

As @Lindon pointed out, the samples/maps dont load instantly, which in turn, makes it so the samplestart/end times dont load properly either. The idea is to have the SampleStart/End load AFTER the samplemap/preset is loaded so the correct location is placed.

[d.healey]

@trillbilly I'd have thought the loading callback would be the solution for this.

HISE | Docs

(docs.hise.audio)

[Lindon]

@d-healey said in LAF + Sampler Functions:

@trillbilly I'd have thought the loading callback would be the solution for this.

HISE | Docs

(docs.hise.audio)

@trillbilly - yep thats exactly what I do....

CirclePanel.setLoadingCallback(function(isPreloading)
{
	var postLoadZones;
	var postLoadStartPos;
	var postLoadEndPos;
	if(!isPreloading)
	{
		//OK so if we have just added a sound using the viewports then

		if (loadingFromViewport)
		{
			loadingFromViewport = false;			
			postLoadZones = theSamplers[SamplerSelector.getValue() -1].createSelection(".*");
			for (k = 0; k<postLoadZones.length; k++)
			{
				postLoadZones[k].set(theSamplers[SamplerSelector.getValue() -1].SampleStart,0);
                               // etc. etc.
			}

			
		};

    }else{
	    Console.print("Starting to load something.....");
	};
          
        
});```

[DanH]

@Lindon @d-healey I thought there was a loading callback :)

So one unintended consequence of changing the sample map data with ui controls is that (in HISE at least, not tested in exported) my sample maps will be overwritten at some point with the new data. I'm not resaving anything in the sample editor, it somehow does it by itself...

I can't help but feel this approach is a bit hacky

[trillbilly]

@Lindon @d-healey man, I'm all over the place with this lol. Thanks for the script snippet. So this is what is needed in conjunction WITH the presethandler, correct?

[trillbilly]

@DanH Uh oh, let's hope the compiled plugins have a touch of magic and just maybe don't have the issue lol

[d.healey]

@trillbilly No, the preset handler shouldn't be required in this case.

The loading callback is triggered when sample loading starts, and triggered again when sample loading ends.

The preset callback is triggered when a preset is loaded. This no longer seems to be relevant for what you're trying to do because the sample map is the thing we're interested in rather than the preset.

[Lindon]

@trillbilly said in LAF + Sampler Functions:

@Lindon @d-healey man, I'm all over the place with this lol. Thanks for the script snippet. So this is what is needed in conjunction WITH the presethandler, correct?

it depends....

If you are loading a sample and once its loaded you want to do something then yeah - just the loading callback,

but if you want to save the sample positions and reapply them in each preset ... then you might need to look at the preset post callback, ....

[trillbilly]

@Lindon Man oh man, ok.

If I'm not back in a few hours, send a search party...

[trillbilly]

@d-healey Thanks! I've been trying to comprehend everything all at once. I think I need to step back and focus on one part of this issue at a time. Yesterday still has my brain fried...

[Lindon]

@trillbilly said in LAF + Sampler Functions:

@Lindon Man oh man, ok.

If I'm not back in a few hours, send a search party...

Well its conceptually quite simple (well ish)

HISE and every other "windowing" system is event based, we have callbacks, so named because they get called back when something happens....

When a user clicks on or moves a control then its onControlCallback gets called, and does something.

So we have events - things that happen - and we have callbacks for them - so as well as the mouse click/drag etc. events there are system based events too...

like for instance the onTimer callbacks, all we are talking about here is two other callbacks, one when all the samples are finished loading, and one when the preset is finished loading...

The BIG problem is that we have to realise that more than one event can happen at (nearly) the same.... so as programmers we have to think about what's happening(or might be happening) when... and that can get a bit complicated...

[trillbilly]

@Lindon I understand what you're saying but I can't quite put it into script just yet lol.

I'll get there. It's beginning to make more and more sense, its just a slow process for an ape like me.

[d.healey]

@trillbilly Did you watch this one?

[trillbilly]

@d-healey That would definitely be the one to watch. How I missed this one, we'll never know.