Yes, I were able to compile Plateau - unfortunately I had to do changes in source code so in order to publish it I will have to fork repository and publish my changes to github. I will probably publish Plateau by the end of this week as I’m also using it in my patches.
2 Likes
I was about to ask this question. So, all of the plugins you are distributing are based on unmodified source code with all distribution documentation pointing to the CORRECT GitHub repository and branch and is unforked?
Which is your VCV Rack V2 fork?
You didn’t include all the licensing for artwork, logos, names, fonts, attributions, etc.
@mikolajczyk.mikolajm - I built and tested your version on a Mac Mini M1. So far it works without issue. I’ve built and installed the Fundamental, Befaco, and Audible Instruments plugins but have not yet tested anything except the default patch. It worked fine.
I’ll have more time for tests tomorrow.
Best regards,
dp
If you’ve modified any code, you need to very careful with the graphics licenses. Even though many developers licenses allow modification and redistribution of the code, they forbid redistribution of logos, components, and panel images in derivative works.This also includes the panel layout. Modifying the code would be enough to constitute a derivative work.
Quick test on M1 Mini: The M1 build of Rack crashes on exit with just the default patch loaded:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libRack.dylib 0x0000000104457ab4 glnvg__renderDeleteTexture(void*, int) + 12
1 libRack.dylib 0x0000000104524290 std::__1::__shared_ptr_emplace<rack::window::Image, std::__1::allocator<rack::window::Image> >::__on_zero_shared() + 24
2 libRack.dylib 0x0000000104524290 std::__1::__shared_ptr_emplace<rack::window::Image, std::__1::allocator<rack::window::Image> >::__on_zero_shared() + 24
3 plugin.dylib 0x000000010a8ac65c CustomLightPanel::~CustomLightPanel() + 68
4 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
5 libRack.dylib 0x00000001044c62ac rack::app::ModuleWidget::~ModuleWidget() + 32
6 plugin.dylib 0x000000010a8ad748 CloudsWidget::~CloudsWidget() + 12
7 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
8 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
9 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
10 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
11 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
12 libRack.dylib 0x000000010451c9f4 rack::widget::FramebufferWidget::~FramebufferWidget() + 12
13 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
14 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
15 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
16 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
17 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
18 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
19 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
20 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
21 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
22 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
23 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
24 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
25 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
26 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
27 libRack.dylib 0x000000010451de54 rack::widget::Widget::~Widget() + 12
28 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
29 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
30 libRack.dylib 0x000000010451de54 rack::widget::Widget::~Widget() + 12
31 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
32 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
33 libRack.dylib 0x0000000104517690 rack::ui::ScrollWidget::~ScrollWidget() + 48
34 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
35 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
36 libRack.dylib 0x00000001044ab328 rack::app::browser::Browser::~Browser() + 12
37 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
38 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
39 libRack.dylib 0x00000001044aa62c rack::app::browser::ModelBox::~ModelBox() + 12
40 libRack.dylib 0x000000010451ddec rack::widget::Widget::clearChildren() + 116
41 libRack.dylib 0x000000010451dcc0 rack::widget::Widget::~Widget() + 48
42 libRack.dylib 0x00000001044e1b54 rack::app::Scene::~Scene() + 48
43 libRack.dylib 0x00000001044571a4 rack::Context::~Context() + 184
44 com.vcvrack.rack 0x000000010403ebf4 main + 2568
45 libdyld.dylib 0x000000018ef09430 start + 4
As far as Performance, it is quite a bit improved: At 30 Frames/sec, 48kHz samplerate, 256byte buffer M1 Build max was 6% Rosetta Rack2: 9.5 Max
also GPU looked around 1/3rd less on M1 build over the Rosetta one. So definitely worthwhile to do, so let’s hope an official Rack2 M1 build happens sooner rather than later 
1 Like
Yes, my Rack2 fork is located here: https://github.com/VCVRack/Rack/compare/v2…gerwazy102:arm-compatible-rack
For plugins I use unmodified source. All plugins have “plugin.json” file which contains information about license, author, version, etc. I also collected data about branches I used when building here: Arm plugin compatibility · gerwazy102/Rack Wiki · GitHub - this wiki contains info about which branch I used and for failed ones it also contains errors I got while building.
I also collected information about licensing for all plugins I succesfully built here: Built plugins licences · gerwazy102/Rack Wiki · GitHub . I have to modify my script to also collect artwork license data because as someone pointed out here it could be different from source code itself.
2 Likes
I run the build with
make run
with the default patch. No crash on exit here.
Just a quick note regarding plugin builds for the M1. I’ve built most of the plugins I use commonly here, with the notable exceptions of SquinkyVCV, Valley Audio, and Surge-Rack. Same as your results. However, I was able to build the Southpole and Wiqid Anomalies plugins. I use a different repo for the Southpole stuff, and the Wiqid stuff includes my own edits. Nothing has been tested yet here beyond the default patch, I don’t know yet if any of this stuff will work correctly. I’ll be testing throughout the day.
2 Likes
@mikolajczyk.mikolajm - The Monome plugin builds but crashes Rack on startup.
[1.327 info src/plugin.cpp:121 loadPlugin] Loading plugin from /Users/davephillips/src/Rack2-arm-compatible/plugins/monome-rack
Binding to port 13000.
Assertion failed: (sizeof(osc::int32) == 4), function OutboundPacketStream, file OscOutboundPacketStream.cpp, line 166.
make: *** [run] Abort trap: 6
Thank you for your reply to my questions. So, in this distribution of VCV Rack V2, are your modifications to Rack source code publicly available in your fork, along with the licensing requirements for distributing modified GPL open source code?
I’m looking at this strictly as the developer of an open source plugin for VCV Rack, for which I want to ensure that not only are the permissions of GPL v3+ respected, but also the license requirements, limitations and prohibitions as well as the VCV Rack ethics “guidelines”.
I read your posts as saying that you are following the licensing permissions and requirements for each plugin and its particular open source license model, up front rather than eventually. I am not certain regarding your intentions for VCV licenses, but that really is not my business.
Thanks again for your transparency and openness to discussing this.
Builds and runs great here. One thing that wasn’t immmediately obvious is that (I think) only your custom build has user dir as Rack2M1? I had to modify line 113 asset.cpp as follows to get the same:
userDir = system::join(pw->pw_dir, "Documents", "Rack" + APP_VERSION_MAJOR + "M1");
Having a similar experience, although the crash on exit is something i experience with the official version too, up till 2.1
(All this time I have not been able to reproduce this crash in a way to analyse it, it happens kinda random while using the red cross in the corner to exit.)
For this M1 build, performance is noticeably better then running in Rosetta! 
Strangely enough 60fps gives better cpu results then any lower fps setting.
testing:
1 engine thread, 48khz buffer@256 / gpu@60fps
I hope this becomes official soon
6 Likes
I still see it now and then on patches that load fine second try in every 2.x version of Rack2 Pro, never found a rhyme or reason to pin issue to. But happens rarely enough… Seems that there is often a stepModule() called likely before the module was fully instantiated and wired up resulting in the crash, so best guess is that it does not always start things in the same manner, and sometimes ends up calling step() method before it has loaded everything and gotten it ready. But that is just best guess in absence of anything sure thus far
1 Like
The trowaSoft plugin fails and crashes Rack with the same assertion error when I try to load any of its modules. The Str1ker module from the JW plugin will open but when I turn on OSC it crashes Rack. The oscpack OscTypes.h appears to be the problem source. Any suggestions to fix ?
No problem, I really appreciate your input in this matter as I’m not experienced in licensing of software at all. Thanks to your feedback I’m pretty sure I have to drop my binary release from github as it looks I’m not allowed to use graphics of core modules in my fork.
Sorry everyone - I have to remove my release from github because I don’t want and I never intended to violate any licenses. My enthusiasm made my actions too fast. Instead of distributing binaries I will just describe how everyone can test it on his M1 laptop. Sorry everyone for bringing your hopes up! 
5 Likes
All good, we all learned a few things so keep enthusiastic by all means It is a worthwhile exercise and may help VCV to release an official build rather sooner than later…
3 Likes
It was interesting and fun trying an actual working copy of it!
Thanks for the effort you put in it
1 Like
Distributing binaries is probably a bit premature. Btw, I’ll let you know if I resolve the oscpack issue.
2 Likes
I found a patch that allows oscpack to build and run correctly on the M1. I now have the trowaSoft and Monome plugins working here. JW’s Str1ker is also now functioning correctly.
At this time I’m missing only the SquinkyVCV plugin. I rely heavily on that one, hopefully I’ll find a way to build it.
4 Likes