@tsempire I'll give the solution to those who need it.

Copy this code:

// Get a reference to the MIDI processor as MIDI player
const MIDIplayer = Synth.getMidiProcessor("MIDI Player1").asMidiPlayer();

// Get a reference to the transport buttons
const grpTranportBtn = [Content.getComponent("btnPlay"),
Content.getComponent("btnStop")];
for(b in grpTranportBtn)
{
// Make sure the buttons are not saved with the presets
b.set("saveInPreset", false);

// Assign the control callback to the transport buttons b.setControlCallback(onTransportBtnControl);

}

// Also set the STOP button to be momentary
grpTranportBtn[1].set("isMomentary", true);

inline function onTransportBtnControl(component, value)
{
// get which button triggered the callback
local index = grpTranportBtn.indexOf(component);

// If it's the PLAY button if(index == 0) { // if the PLAY button is pressed if(value) { // start playing MIDIplayer.play(0); } else { // keep the button's value to 1 if it's still playing grpTranportBtn[0].setValue(1); } } // if it's the STOP button else { // only react if the mouse is clicked (not released) if(!value) return; // stop playing MIDIplayer.stop(0); // set the PLAY button's value to 0 grpTranportBtn[0].setValue(0); }

};

// on compilation, reset the playhead position to the beginning
// comment it out if not needed
MIDIplayer.setPlaybackPosition(0.0);

Create 2 buttons with the ID

btnPlay

btnStop

I've tried using the arp thinking I could save some development time however it does not seem fit for this use case. I will implement a custom midi player using tables and note on off events.

@Lindon yeah, this has been very annoying lately to me too. I would open a large project and if I try to navigate to one of the included external scripts, it would throw this killer.
If I reopen the project, then recompile the code again before doing anything, then switch to the external script, it would be fine.

It happens in weird places.

Glad you determined the most likely cause!

@DanH I thought that, at least the fixed band number can be set inside the FloatingTile.

It seems it is not possible without source code modification

@alfaholic I’ve found that it’s a good practice to wait until you’ve added in all your samplemaps before creating the presets…helps keep things in order…secondly I’ve found that you can go into the project folder where the samplemap xml files are and rename them as needed to keep your structure in tact…it’s saved me a few times when I put the cart before the horse

Got my mistake. Actually my other component name was "Settings". That was overriding the

Settings.setZoomLevel(value)

to work.

please dont think that I am doing this,

No worries, I'm not accusing you here, I just wanted to point out that there is nothing to discuss.

Myself and others warned him and told him about your policy

So you did already what I would have done too. What I can't and won't do is go in there and start making legal threats because I'm a self respecting person and I love myself :)

Samples should be released under a different license, the GNU GPL is not suitable.

Yes, the sample licensing is a bit of a grey area, but we're going for the most practical solution here which is as long as you license them permissively enough so that people can use your GPL licensed plugin / rhapsody library, you're fine.

however if you're using scriptnode networks or other things that include elements from the HISE codebase you have to follow the same rule

That's not 100% true. You can of course use scriptnode and anything in HISE in a Rhapsody player project, however you can't export them to a C++ module (because the Rhapsody player is already compiled so it can't load custom C++ stuff). So this is rather a technical limitation than a legal one.

@TNTHM Why are you changing it in the label callback and not the button callback?

@Christoph-Hart would it make sense to enable this for backgrounds only? i.e. have the ability to turn it on for a panel or whatever. If I have 5 background images in a vsti, 20MB each althrough the are never all shown at the same time but change depending on parameters, each VSTi load takes up 100MB of ram just for the backgrounds?

@bendurso Lottie is a good suggestion as well. thank you all!

@d-healey you’re a legend thank you.