@Christoph-Hart Yea it has to learn which samples to keep which can often cause dropouts the first time you play. The only advantage I can think of would be that you don't have to unfreeze to make edits. So it allows you to work with live tracks a bit longer before running out of memory and start freezing tracks.

It is pretty much just a convenience thing until you run into CPU bottlenecks and are forced to freeze tracks anyway.

@d-healey Okay, I use that all the time

Do you mean the way kontakt can be purged and then only loads in the samples of the notes you play?

No problems in windows 10 - Reaper 64 bit and the CPU usage looked fine.

Released my experimental guitar library yesterday, available for Kontakt 5.8+ and HISE/VST

This is a small experimental library I have been working on for a while, the main idea was to sample real picked intervals.

Intro price 5$(until march 15th), normal price 9.99$.

30 day refund policy.

Size info:
497 Samples
Kontakt: 407 MB size on disk
VST: 170MB samples, 11.4MB VST

Click here for more information!

I'm looking forward to learn the correct way as well then

@Lindon that could be solved easily with Globals.subNote = 60;

and in Sampler 4 use:

Message.setNoteNumber(Globals.subNote);

@Lindon Well what i wanted was perfect control over which note ID got played by which sampler so I set a constant variable identifier in each sampler's midiprocessor:

const var identifier = 0;

And when I trigger a note I store it's ID in a multi dimensional array [sampler ID][noteID].
which then gets ignored or played in the sampler midiprocessor:

function onNoteOn()
{
    input_id = Message.getEventId();
    
    local i;
	for(i = 0; i < 8; i++){
	    if(Globals.SamplerNoteIds[identifier][i] === input_id){   
	        Globals.SamplerNoteIds[identifier][i] = -1;
	        return;
	    }
	}
	// if loop doesn't find id, ignore event
	Message.ignoreEvent(true);
}

This is indeed a bit messy as @d-healey said, but plain midimuters did not provide that amount of control.

You could store all required info for the samplers in global variables and act on that information in the specific samplers midiprocessors.

@Lindon Your opinion matters because we are talking about Christoph setting up a little niche store for HISE instruments, and I am assuming that he will not spend considerable amounts of time and money to market every single product on the store constantly and in perpetuity.

I just hope that we can be a little progressive here and not artificially inflate the prices of our products for no other reason than "they do it".

@orange I don't care about what most distrubutors do as that number is pure greed. And I personally don't care about licenses with my own libraries. I'm just wondering if @Lindon actually believes that revenue split is fair or not.

Why would 5-10% or less not be viable?

Do you really think it is okay to take up to 40% for what is almost passive income by the distributor?

Sure, in general, but I don't need 100% instant response and what I am doing works in all but this edge case so far. Maybe running this deferred has some potential downfall I'm not aware off.

I did encounter an issue :(

I was running most of my logic in a defered script, which seems to work great 99% of the time.
But I noticed today when I rendered an example at full speed offline, that the output wasn't exactly the same as live playback.

I rely a lot on the "Engine.getUptime()", is it possible that the result from this timer gets scaled somehow when used in the gui thread and playback is faster than realtime?
Maybe I should just make my own counter variable and increment in the timer callback?

If saving as Monolith means it is HLAC then yes.

I just finished porting my guitar library from Kontakt 5.8 to HISE and was positively surprised about the memory and CPU usage of HISE(compiled to 64 bit VST)

Memory usage Kontakt: 190MB
Memory usage HISE: 103MB

CPU difference while playing the exact same thing:

The timer in kontakt is set to 1ms resolution while the one in hise is 4ms, having them set at the same value results in about twice the cpu usage for kontakt instead of three times. but the HISE version has arrays of twice the size compared to the kontakt script, so it iterates over more data per timer tick.

Hopefully I don't encounter any issues because this really makes me want to go 100% HISE in the future.

I'm not sure if it is just me but I very much prefer the immediacy of live chatting compared to making forum posts when it comes to small issues, and I think it could benefit the community as a whole to have a more relaxed place to chat.

Maybe it already exists?

Anyway I'm rather tired of the bad developer workflow that kontakt 5 offers so I decided yesterday to make another attempt at HISE, currently porting a Fingerpicked Acoustic Guitar library over.