Engine.getPreloadProgress update interval

[ustk]

@d-healey does Engine.getPreloadProgress() connect to zip extraction?
I thought it was only for sample map loading purpose...

Because the progress can been seen in the object itself:

Interface: {
  "Status": 1,
  "Progress": 0.5,
  "TotalBytesWritten": 1143078934,
  "Cancel": false,
  "Target": "/Users/greg/Downloads",
  "CurrentFile": "__MACOSX/._LogicProTrial.dmg",
  "Error": ""
}

But I have no idea how to get it progressively...

[d.healey]

@ustk The obj.Progress is only for individual files, the callback is only triggered 3 times, once before extraction, once when extraction starts, and once when it completes.

HISE | Scripting | File

A object for accessing a file on disk

(docs.hise.audio)

The extraction process will be executed on the sample loading thread and you can assign a callback that is executed to track the extraction progress.

[ustk]

@d-healey Yeah I knew for the triggering happening only in this cases but I missed the part for extraction progress :)

And I imagine you're not in this case scenario, right?

the progress from 0.0 to 1.0. Be aware that this tracks only the number of files extracted vs. the total number of files, so if you have one big file inside the archive, it will not work.

I only have 1 big file I can test on my side...

[d.healey]

@ustk That only applies to obj.Progress object. But I tested with both scenarios.

[ustk]

@d-healey With a multi files zip, it works here with both solutions

zip.extractZipFile(d, true, function(obj)
{
	Console.print(obj.Progress); // Here it is called all along the extraction
});

and

zip.extractZipFile(d, true, function(obj)
{
	if (obj.Status == 1)
		t.startTimer(100);
		
	if (obj.Status == 2)
		t.stopTimer();
});

const t = Engine.createTimerObject();

t.setTimerCallback(function()
{
	Console.print(Engine.getPreloadProgress());
});

Both giving me the same result (it's not well distributed because of my test files)

Interface: 0.01705756929637527
Interface: 0.06823027718550106
Interface: 0.9232409381663113
Interface: 0.9360341151385928
Interface: 0.9360341151385928
Interface: 0.9402985074626866
Interface: 0.9445628997867804
Interface: 0.9466950959488273
Interface: 0.9488272921108742
Interface: 0.9552238805970149
Interface: 0.9594882729211087
Interface: 0.9616204690831557
Interface: 0.9616204690831557
Interface: 0.9616204690831557
Interface: 0.9616204690831557
Interface: 0.9658848614072495
Interface: 0.9658848614072495
Interface: 0.9701492537313433
Interface: 0.9744136460554371
Interface: 0.9786780383795309
Interface: 0.9786780383795309
Interface: 0.9786780383795309
Interface: 0.9786780383795309
Interface: 0.9829424307036247
Interface: 0.9829424307036247
Interface: 0.9829424307036247
Interface: 0.9872068230277186
Interface: 0.9872068230277186
Interface: 0.9914712153518124
Interface: 0.9914712153518124
Interface: 0.9957356076759062

[d.healey]

@ustk Interesting! Does it work with a single file in the zip? Are you using the develop branch?

[ustk]

@d-healey Always develop...
With a single file I get the same result as you.
This is probably meaning that Engine.getPreloadProgress() behaves exactly the same as obj.Progress,
so straight from 0 to 1 in the case of 1 big file...

[d.healey]

@ustk said in Engine.getPreloadProgress update interval:

This is probably meaning that Engine.getPreloadProgress() behaves exactly the same as obj.Progress,
so straight from 0 to 1 in the case of 1 big file...

Uh that's annoying. Most of my zips contain multiple files so it's not too big a deal for me, but it would be nice to get the progress on a single file archive too.

@Christoph-Hart What is the reason for this limitation?

[Christoph Hart]

@d-healey IIRC the extract function for a single file doesn't provide a progress, so we're stuck with counting what's left to extract.

JUCE: ZipFile Class Reference

(docs.juce.com)

[d.healey]

@christoph-hart Ah I see, it's a JUCE limitation. I think in that case I'll just use a generic spinner type progress indicator.