return values from async calls

[Lindon]

It would be really nice (and something you could check) if the async calls had return values for success or failure (1 or 0), for example:

var myResult = Engine.loadUserPreset("bah/blah/blah");

It would be even nicer if you could define a function that got called on return but hey...small steps...

[Christoph Hart]

What you can already do is to attach a function that is executed when the preload state changes so you can implement custom sample preloading bars. If you just want to react on user preset changes, take a look at the solution posted in the other thread.

But its a good idea and every method that returns void can be changed to return a error code. However its a bit unclear what a "success" in this case is:

• Does the file exist?
• Is it a valid XML file?
• Does the version match or does it contain any controls that aren't part of the current instrument or have the wrong type?

The more you go down this list, the more stuff it has to do synchronously and at some point it looses the advantages of an async call (which is instant returning).

[Lindon]

@Christoph-Hart

Well async in my world isnt "instant returning" cause if they were they could be syncronous, there's obviously some indeterminate wait period, which is fine I get that.

We can define success (and their return codes as) in this way:

A file exists and got loaded = 1 (after that you are on your own)

Failure is:
file not exist or fail to load = 0

If I dont define and create a correct piece of XML or if its got some extra params or some missing = my problem not yours.

You are right you could end up down a rabbit hole - so just dont go there:

The nice outcome is:

var myReturn = -1;
myReturn = Engine.loadUserPreset(......);

While (myReturn = -1){
    wait(1000);
};

(Yes I know there is no simple wait statement - and yes I think there should be...but thats another request for another day)

[d.healey]

@Lindon You can achieve a while wait loop using a timer callback.

[Lindon]

@d-healey yes I know I can.... but that doesnt meet the criteria of "simple" I think...

[d.healey]

@Lindon

@d-healey yes I know I can.... but that doesnt meet the criteria of "simple" I think...

JavaScript, on which HISE script is based, doesn't have a wait/sleep type thing and I don't think it's a good idea to start tacking on bits of KSP to solve a problem that doesn't really exist. I agree that writing less lines of code = simpler but I'm not sure the difference in level of simplicity is as important as the functionality which is already there.

[Christoph Hart]

Yes, implementing a sleep functionality in a multithreaded environment is the worst. I have played around with this, but it involves stack unrolling and restoring the value of every local variable.