Solved LinkOSX oddness

[M_Holloway]

I have a sample install package that allows users to select the sample location and, in a post install script, write that location to the LinkOSX file.

This all seems to work fine and when I open the LInkOSX in a text editor, it reads correctly.

In my plugin/standalone, on initialisation, it grabs the LinkOSX file text, sets this as the sample folder, reloads all samples and sets a label to the current sample location...

const var linkOSX = FileSystem.fromAbsolutePath("/Library/Application Support/myPlugin/LinkOSX");
const var linkTxt = linkOSX.loadAsString();
currentSampleLoc.set("text", linkTxt); //sets label text
Settings.setSampleFolder(linkTxt);
Engine.reloadAllSamples();

or at least it should but although the label shows the correct path, no samples play.

I have a button in my settings UI that allows users to select the sample location from within the plugin and when clicked it opens to the sample folder set in LinkOSX (located using FileSystem.Samples) and then after that is selected it works fine and the samples play as expected.

inline function oncurrentSampleBtnControl(component, value)
{
	if(value)
		FileSystem.browseForDirectory(startFolder, function(sampleDir)
		{
			if (isDefined(sampleDir) && sampleDir.isDirectory())
				{newLoc = sampleDir.toString(0);
				Settings.setSampleFolder(newLoc);
				Engine.reloadAllSamples();
				currentSampleLoc.set("text", newLoc);
				linkOSX.writeString(newLoc);}
		});
};

Content.getComponent("currentSampleBtn").setControlCallback(oncurrentSampleBtnControl);

Inspecting the LinkOSX file after this has run reveals a new modification timestamp but the text within is identical to before.

Any ideas anyone?

[d.healey]

@M_Holloway said in LinkOSX oddness:

Inspecting the LinkOSX file after this has run reveals a new modification timestamp but the text within is identical to before.

Do the permissions change?

[M_Holloway]

@d-healey Just tried it again to check this and no, the permissions stay the same.

I wondered if it was because the LinkOSX was getting overwritten in the manual sample folder location routine so added

linkOSX.writeString(linkTxt);

to the initialisation routine to see if that made a difference... it didn't

[d.healey]

@M_Holloway We can rewrite this, not sure it will help with the issue though. I've added a couple of comments

if (!value)
    return;

FileSystem.browseForDirectory(startFolder, function(sampleDir)
{
    if (!isDefined(sampleDir) || !sampleDir.isDirectory())
        return;

    newLoc = sampleDir.toString(0); // Don't use a magic number, use one of the constants - https://docs.hise.audio/scripting/scripting-api/file/index.html#tostring
    Settings.setSampleFolder(newLoc);
    Engine.reloadAllSamples();
    currentSampleLoc.set("text", newLoc);
    linkOSX.writeString(newLoc); // You don't need to do this, the setSampleFolder function takes care of it for you.
});

[M_Holloway]

@d-healey

Thanks for that; your suggestion doesn't break anything, but the problem still persists. It seems odd when the two routines are essentially performing the same operation.

[d.healey]

@M_Holloway There's a possibility that your script is adding an invisible character at the end of the line, like a carriage return or something. You'll need a text editor that can display hidden characters in order to check that.

[M_Holloway]

@d-healey

Is there anywhere else it could be looking at for the sample location? As an experiment, I deleted the LinkOSX file and all of the various locations I'd put samples while testing and on opening the standalone, the text label, - which in theory should have been blank - showed an old sample location.

[d.healey]

@M_Holloway I'm only aware of it looking in appdata. There are two app data folders on Mac though. One in the system Library and one in the user Library.

[M_Holloway]

@d-healey I already looked in the user Application Support folder and there's nothing there that should be affecting it.

[M_Holloway]

@d-healey Cracked it... it was, as you suggested a sneaky EOL return in the generated file. Some tweaks to the post install script and now it all works.