@Christoph-Hart that would be super cool and flexible I think!

@Christoph-Hart will it also be possible to disable the crossfade after the transition and stay on the legato transition sample? I’m thinking about a scenario where the samples are edited so that the transition sample also contains the sustian portion to loop.

@d-healey maybe it works on some systems but not others, for whatever reason? Is there a way to get the final url of the call affected by the parameter property?

@d-healey none, but I suspect the problem is with the parameter part of the url called by HISE. The reason I suspect this is that the POST calls are made to a different server, and they work fine. The download callback works fine wherever I test it and - again, works for the vast majority of users - but I guess it's possible that the parameter part is not attached to the call properly, and the server rejects it because it doesn't pass the authorization.

HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution

Is there any way to print the final url with the parameter part? The docs https://docs.hise.dev/scripting/scripting-api/server/index.html#callwithget say tha...

Forum (forum.hise.audio)

@d-healey of course not ;-) But I also have one guy on Windows experiencing this now.

Is there any way to print the final url with the parameter part? The docs https://docs.hise.dev/scripting/scripting-api/server/index.html#callwithget say that "The parameters have to be a non-nested JSON object and will automatically change the URL to embed these parameters". What does the final url look like after the change?

@d-healey no, I have three different macs here, one is on intel, the other two are on m1. One is running the latest version of Sequoia, the other is on Monterey. I can't reproduce the issue on any of these, and it's literally 3 people out of almost 500 having the same problem. But the problem is there, apparently. It's either that macOS blocks traffic on GET / download callbacks, or that the parameter part is not passed correctly on their system for some reason. Here's my thread: https://forum.hise.audio/topic/12537/heads-up-server-downloadfile-issue-on-macos-sequoia-and-a-solution/22 but I thought learning how to send debug versions might be valuable to other people, if they'll end up searching for it at some point

@d-healey thank you!

@d-healey yeah, and tha't the problem for me. The hise part is good, it's just that the traffic appears to be blocked on some random macOS systems, and I'm trying to figure out what's up with that

@d-healey but this won't fire system errors, right, only the issues in hise script?

@d-healey that's what I thought. The 2nd true will mean that subfolders are supposed to be affected, too, right?

@d-healey thank you, but this doesn't seem to work when I test it. Shoud it be (false, false) or (fase, true)?

The p part is the authorization that’s getting passed to the server. I was having an issue using that with GET - again, very inconsistent and on some systems only, and I can’t reproduce it on any fo the 3 macs I have around - as though the parameter was not being passed to the server properly. So maybe it’s about that, but then I have no clue on how to troubleshoot this further.

Ok, a quick update on the subject - the XCode transport solution only works for some users. For others, the download callback returns this.data.finished = true && this.data.sucess = false even before anything can be downloaded. This is happening both on Windows now, and macOS, for about 0.5-1% of users, for everyone else things are working fine.

Here's a very simplified overview of my download logic:

At the beginning of the scrip, I call:

Server.setBaseURL("https://");

which is used for POST calls, and then this download callback, with the url aprt being the rest of the url, after the https part.

inline function startDownload()
{
	// Download samples and content
	for (i = 0; i < plugincontent.length; i++)
	{
		local files = workingFolder.getChildFile(plugincontent[i]);
		downloads[i] = Server.downloadFile(url + plugincontent[i], p, files, downloadCallback);
	}	

	// There's just one zip file and it's always the first in the plugincontent array
	zips[0] = workingFolder.getChildFile(plugincontent[0].replace(subfoldernamefull).replace(subfoldernamedemo));
	
	// Show update progress panel
}


function downloadCallback(obj)
{
	if (this.data.finished != true)
	{
		// Show and update download progress
	}

	// Connection lost
	if (this.data.finished && this.data.success == false)
	{
		// Show error message
	}

	if (this.data.finished && this.data.success == true)
	{
		// Update downloaded files count and extract zips
	}
}

As said, this works 100% for POST calls for all users. The problem is for 1% of users with the download callback. I remember having a similar issue with GET when I started this project.

Save me, please!

@Christoph-Hart from what I see, File.createDirectory() creates read-only folders, even if the parent folder is set to read & write. At least on Windows.

If I send a debug build of a standalone app on macOS, how can the person using it get me the log? I know it's displayed in XCode, but I can't ask people to install XCode just to troubleshoot something ;-) Thank you!

@Christoph-Hart is this a part of the latest develop branch commint?

@d-healey that would be cool, but actually just changing the check from http to https would make it more mac-friendly. @Christoph-Hart

There’s also a question of whether to base url is passing the https part properly, but that’s too complicated for me to check. As I mentioned, the download callback wasn’t working for some Sequoia users way before I added the online check, so there’s definitely something going on.

Anyway - changing the build settings in xcode is a way around it.

@d-healey maybe, but I added that check to the download callback as I was troubleshooting. Downloading was not working on Sequoia before that, and only adding the exceptions in XCode solves this. Maybe the https:// base is not passed to the download callback properly, I don't know.

I've had three customers report that the download fails immediately on Sequoia. Apparently, GET / POST calls work fine, but there was an issue with downloading stuff from my Cloudflare server. The issue was only present on macOS Sequoia, but not on every computer - seems random in a typically Apple way.

I call different servers throughout the installation process to get the license key validated (this works fine), and to get the files (which caused the issue). My logic starts with

Server.setBaseURL("https://");

And then the rest happens in the expected way.

I built a Debug version and checked the log. It turns out that the downloadFile callback periodically triggers a call to http://google.com

Now, why is it calling Google, I have no idea. But the problem is about the http part. Apparently, it triggers some safety nonsense in macOS that's blocking the entire download traffic! Https calls work fine, but pass something without 's' into the standalone app and you're up for trouble.

All this is happening on a standalone app build, I have not tested it with plugin exports because this is not the flow I offer with this app.

The solution is: start building the standalone app, and quit the process right after the XCode files are created. Then, open the XCode project in the Build folder, choose the Signing and capabilities tab, then click on the little + Capability text that doesn't even look like it can be clicked (awesome UX work here, Apple) and choose App Transport Security Exception. Add your main domains there, and google.com. Build and you will be fine.