The new M1 iPad and future of Reason

[Heater]

Some companies' AUv3's are not being made available that way to make us buy desktop versions.

I don't support companies that do that.

[integerpoet]

Some companies' AUv3's are not being made available that way…

Indeed.

…to make us buy desktop versions.

We don't have a way to know that. The number of other possible explanations is very large.

[avasopht]

Wow I had no idea about the LLVM stuff they do, that's pretty surprising and great design and also great news for us - users. Looks like they anticipated hardware platform changes, I mean, ARM is taking over the world currently. Microsoft just announced their developer ARM Mini PC too...

I have no inside information, but I bet at the time RS cared more about preventing REs from crashing the app.

That wouldn't prevent crashing, but it does provide a number of notable benefits:
1. Forward compatibility (without requiring access to source code, or involvement from developers): all REs can be rebuilt for any future OS supported by Reason without the input of the developer.
2. Platform and processor agnostic: it can be compiled to run on any compatible processor.

The LLVM bytecode is still compiled into the same executable code as programs and DLLs. The protection against crashing comes down to how Reason isolates the execution and exceptions of a RE.

[integerpoet]

I have no inside information, but I bet at the time RS cared more about preventing REs from crashing the app.

The LLVM bytecode is still compiled into the same executable code as programs and DLLs. The protection against crashing comes down to how Reason isolates the execution and exceptions of a RE.

But … um … I can't help but believe the latter is enabled by the former. I mean, if you give "foreign" truly native code access to your address space, all it takes is to write through a single uninitialized pointer — or for that matter something as simple as reading through NULL — to bring the whole process down. I don't know what kinds of relevant facilities might be available these days on Windows to combat that sort of thing, but on macOS crashy code gonna crash. I don't see how RS could not be getting a stability win via bytecode, but if I need to be schooled then I look forward to the experience.

[avasopht]

But … um … I can't help but believe the latter is enabled by the former. I mean, if you give "foreign" truly native code access to your address space, all it takes is to write through a single uninitialized pointer — or for that matter something as simple as reading through NULL — to bring the whole process down. I don't know what kinds of relevant facilities might be available these days on Windows to combat that sort of thing, but on macOS crashy code gonna crash. I don't see how RS could not be getting a stability win via bytecode, but if I need to be schooled then I look forward to the experience.

LLVM was created by AppleClang was developed by Apple to build on LLVM (while hiring LLVM creator to work on it to fit Apple's needs). Every OSX program is complied to LLVM bytecode first, and then that bytecode is compiled to executable code.

The only difference is that RE developers only perform the first step, which allows Reason Studios to perform the second step for any CPU.

Any NULL pointer bug in an RE will executed exactly the same.

Pretty much any exception can be captured, so a misbehaving RE won't necessarily bring down a whole process. Reason also gets to control memory allocation of REs, which might offer some fringe benefits for memory protection.

[integerpoet]

But … um … I can't help but believe the latter is enabled by the former. I mean, if you give "foreign" truly native code access to your address space, all it takes is to write through a single uninitialized pointer — or for that matter something as simple as reading through NULL — to bring the whole process down. I don't know what kinds of relevant facilities might be available these days on Windows to combat that sort of thing, but on macOS crashy code gonna crash. I don't see how RS could not be getting a stability win via bytecode, but if I need to be schooled then I look forward to the experience.

LLVM was created by Apple. Every OSX program is complied to LLVM bytecode first, and then that bytecode is compiled to executable code. The only difference is that RE developers only perform the first step, which allows Reason Studios to perform the second step for any CPU. Any NULL pointer bug in an RE will executed exactly the same. Pretty much any exception can be captured, so a misbehaving RE won't necessarily bring down a whole process. Reason also gets to control memory allocation of REs, which might offer some fringe benefits for memory protection.

That's really all I meant, which makes me wonder why it ever seemed we disagreed.

I was just saying I bet that at the time they decided to base REs on llvm their top priority was stability.

This is not to say they didn't care about cross-platform support at all.

But, y'know, VST had done that already. And the few times I have seen Reason crash, guess which kind of plug-in was in the backtrace.

[avasopht]

That's really all I meant, which makes me wonder why it ever seemed we disagreed.

I was just saying I bet that at the time they decided to base REs on llvm their top priority was stability.

What I was saying is that compiling to LLVM bytecode itself doesn't give any greater stability whatsoever.

I tend to use clang as my compiler (which first compiles to LLVM bytecode). I can assure you that it doesn't make the slightest bit of difference to stability. When I write buggy code it blows up the same.

The main reason for LLVM is just that it gives them platform independence and forward compatibility without requiring any input from the developer.

[integerpoet]

That's really all I meant, which makes me wonder why it ever seemed we disagreed.

I was just saying I bet that at the time they decided to base REs on llvm their top priority was stability.

What I was saying is that compiling to LLVM bytecode itself doesn't give any greater stability whatsoever.

Right. But it does give you hooks which native code does not. And it finally occurs to me there's at least one video presentation they made about this which explains what the design process was and it probably eliminates all doubt. I saw it a thousand years ago and can barely remember its existence. We could probably find it on YouTube if we cared enough.

[avasopht]

Right. But it does give you hooks which native code does not. And it finally occurs to me there's at least one video presentation they made about this which explains what the design process was and it probably eliminates all doubt. I saw it a thousand years ago and can barely remember its existence. We could probably find it on YouTube if we cared enough.

REs run natively.

LLVM hooks are available to natively run code.

If it's a Propellerhead video, it could have been the use of LLVM hooks to limit access to C functions that access the system as well as a few language features like static variables (which they do have ... along with replacements for some of the C maths routines ... though not necessarily a hook).

Basically, every Apple program (and Windows or Linux program compiled with Clang) is first compiled to LLVM bytecode where the LLVM hooks are available.

So everything that can be done hooks-wise with REs can be done with any VST if a developer wants.

LLVM hooks are available to any VST or application developer compiling with clang or llvmgcc. No hook will stop a device or program from crashing. You can't automate stability. When a program is going to crash, it means its internal state is wrong. No hook can fix that.

Since REs don't access system resources directly, their crashes will be caused by stack overflows, null pointer exceptions, and memory access violations.

Those are easy exceptions to catch.

Stack corruption could be a problem, I suppose, and could potentially bring down the host (or at least the thread).

They could make use of hooks to inject additional memory protection in the RE's rendering method to isolate the stack (which would be a brilliant idea).

See if you can find that video. Maybe there's something I'm missing.

[kuhliloach]

Some companies' AUv3's are not being made available that way…

Indeed.

…to make us buy desktop versions.

We don't have a way to know that. The number of other possible explanations is very large.

The AUv3 plug-in code should be no different regarding audio from the desktop version, but they'd have to enable it for download from the App store. Since many companies charge so much more for the same code in desktop-version it would make no sense for them to make the iOS versions available for use on desktop, even though Apple has made it so they work just fine.

[integerpoet]

The AUv3 plug-in code should be no different regarding audio from the desktop version…

The code is only the first issue. They'd have to be prepared to [1] test it and [2] provide support for it on macOS as well. They may not have the staff or other resources for that.

Since many companies charge so much more for the same code in desktop-version it would make no sense for them to make the iOS versions available for use on desktop…

That's not it either. They could set a different price on macOS if they wanted — even if it meant a (slightly) different product.

…even though Apple has made it so they work just fine.

We know Apple has tried to do that. We don't know that it succeeded in every case.

In general, there's a lot we don't know. Software development is difficult.

[Yonatan]

If RS released a strong enough companion app on ipad, that, if not fully replication, but enough to make you do some crosswork, I would buy an ipad pro. Would love to see Reason on ipad. But first they will need make Reason work native with Silicon/M1/2 chip.

[mimidancer]

The sign that you are over 40 when someone mentions M1 ipad:

http://www.vintagesynth.com/korg/m1.php

I was born in 1990 and I went straight to Korg as well.