Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER for macOS

Reply
 
Thread Tools Display Modes
Old 10-24-2021, 04:35 PM   #1
Goofball Jones
Human being with feelings
 
Goofball Jones's Avatar
 
Join Date: Jun 2021
Location: Chicago
Posts: 48
Default Are the developers working on the Arm-64 version?

Not sure where else to post this, as it's not a specific "bug", but it's an overall thing to Arm_64.

While overall the "beta" is stable to run, it's still a pain to use with x86 plug-ins. They don't crash, but they exhibit strange behavior sometimes...and having to have a "reaper_host_x86_64" separate window slows down workflows.

For instance, if I fire up a Jupiter-8 VST3 in REAPER Arm_64, it has to launch under a different program in the background, and as such it's treated as another program. If you have the VST in the forefront to tweak and adjust aspects of it, then you hit "space" to play, nothing happens. You have to THEN click back on REAPER for it to play.

Also, if you bring in a VST3 instrument like above, you have to then arm the recording on the track for it to play. Under Rosetta with the x86 version of REAPER, as soon as you load in a VST instrument, it's ready to go, without having to arm anything.

It's little things like this that make it cumbersome to work in. Now, I know there has to be a solution to where x86 VST plays well inside the ARM_64 version...just like it's seemless that Bitwig 4.0 does it. It's a native (Universal) M1 application, but can load x86 and Arm_64 VSTs with no problem and no separate programs.
Goofball Jones is offline   Reply With Quote
Old 10-25-2021, 02:01 PM   #2
sockmonkey72
Human being with feelings
 
sockmonkey72's Avatar
 
Join Date: Sep 2021
Location: Berlin
Posts: 170
Default

Quote:
Originally Posted by Goofball Jones View Post
Not sure where else to post this, as it's not a specific "bug", but it's an overall thing to Arm_64.

While overall the "beta" is stable to run, it's still a pain to use with x86 plug-ins. They don't crash, but they exhibit strange behavior sometimes...and having to have a "reaper_host_x86_64" separate window slows down workflows.

For instance, if I fire up a Jupiter-8 VST3 in REAPER Arm_64, it has to launch under a different program in the background, and as such it's treated as another program. If you have the VST in the forefront to tweak and adjust aspects of it, then you hit "space" to play, nothing happens. You have to THEN click back on REAPER for it to play.

Also, if you bring in a VST3 instrument like above, you have to then arm the recording on the track for it to play. Under Rosetta with the x86 version of REAPER, as soon as you load in a VST instrument, it's ready to go, without having to arm anything.

It's little things like this that make it cumbersome to work in. Now, I know there has to be a solution to where x86 VST plays well inside the ARM_64 version...just like it's seemless that Bitwig 4.0 does it. It's a native (Universal) M1 application, but can load x86 and Arm_64 VSTs with no problem and no separate programs.
It's not possible without an external process. That's not REAPER's limitation, that's an underlying architecture limitation. REAPER could do something like pass keystrokes from its child processes back to the mothership to improve workflow, but the fundamental situation remains the same.
sockmonkey72 is offline   Reply With Quote
Old 10-29-2021, 12:39 PM   #3
Goofball Jones
Human being with feelings
 
Goofball Jones's Avatar
 
Join Date: Jun 2021
Location: Chicago
Posts: 48
Default

Quote:
Originally Posted by sockmonkey72 View Post
It's not possible without an external process. That's not REAPER's limitation, that's an underlying architecture limitation. REAPER could do something like pass keystrokes from its child processes back to the mothership to improve workflow, but the fundamental situation remains the same.
Ok, then I wonder how Bitwig 4.0 does it. Because it loads both x86 and ARM64 vsts both, while running natively on M1s and it does it seamlessly. The user doesn't even see any difference. Maybe it's doing it in the background without the users seeing it, I don't know.

But you say there's no way around this as it's not really REAPER's fault. I can understand that. Then the ARM64 version is kind of unworkable if you rely on a bunch of x86 plug-ins. I suppose we should put more pressure on developers of those plug-ins to upgrade them. I mean, it's been over a year now and we're already on the second wave of releases of M1 Macs.

But in the meantime, the x86 version runs just fine under Rosetta. At least Cockos is working on it, and not just resting on their laurels like other developers out there.

Last edited by Goofball Jones; 10-29-2021 at 01:22 PM.
Goofball Jones is offline   Reply With Quote
Old 10-29-2021, 02:05 PM   #4
sockmonkey72
Human being with feelings
 
sockmonkey72's Avatar
 
Join Date: Sep 2021
Location: Berlin
Posts: 170
Default

Quote:
Originally Posted by Goofball Jones View Post
Ok, then I wonder how Bitwig 4.0 does it. Because it loads both x86 and ARM64 vsts both, while running natively on M1s and it does it seamlessly. The user doesn't even see any difference. Maybe it's doing it in the background without the users seeing it, I don't know.

But you say there's no way around this as it's not really REAPER's fault. I can understand that. Then the ARM64 version is kind of unworkable if you rely on a bunch of x86 plug-ins. I suppose we should put more pressure on developers of those plug-ins to upgrade them. I mean, it's been over a year now and we're already on the second wave of releases of M1 Macs.

But in the meantime, the x86 version runs just fine under Rosetta. At least Cockos is working on it, and not just resting on their laurels like other developers out there.
AUs are handled by the OS transparently and automatically -- I can load Intel-x64 AUs in any M1-native DAW and they will more or less work. I don't know how Bitwig is managing VST2/3, though. I haven't checked out their latest update yet. I'd be really impressed (and surprised) if they went to the trouble to write a plugin wrapper to handle the Rosetta2 translation in-process-ish -- it's not possible to do it directly, but you can write a plugin which spawns a process of a different architecture, which itself is loading the plugin you want. Then your native plugin just passes everything, including keystrokes and mouse events, to the child process and returns the results as fast as it can. For the host, it looks seamless, but it's ultimately the same idea as the REAPER separate process hosting, just more integrated.
sockmonkey72 is offline   Reply With Quote
Old 11-26-2021, 10:51 AM   #5
Berg
Human being with feelings
 
Join Date: Jul 2014
Location: Rennes, FR
Posts: 108
Default

And, as M1 users now deal with Rosetta 2 plug-ins process (we're happy that it works quite well thanks to Reaper developers !), isn't it possible to let the play space key work normally without having to click back to Reaper ? It could be nice to have this option because we may have to deal a quite long time with this Reaper Host x86 application...
Berg is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:54 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.