14 errors when making on MAC about monome-rack

[antoniograzioli]

yes, after several attempt and a proper "git submodule update" I built successfully

[Dewb]

Did you clone and build VCVRack first, and clone this repo inside the plugins folder?

[metaphorz]

I just tried cloning the repo on a Mac, doing git submodule update --init --recursive, and then make. It made with only warnings, but when the modules are chosen, the graphics are wrong (no labels or user interaction possible). Rack crashes.

My Rack is 0.5.0 as tagged, not dev.

Process: Rack [6175]
Path: /Applications/Rack.app/Contents/MacOS/Rack
Identifier: com.vcvrack.rack
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Rack [6175]
User ID: 501

Date/Time: 2017-12-07 23:36:24.618 -0600
OS Version: Mac OS X 10.13.1 (17B48)
Report Version: 12
Anonymous UUID: D6D40B3C-0FAD-6B61-AE53-2A01468BB84E

Sleep/Wake UUID: E5CD7102-24CA-48F6-BC92-2A9E2B13C699

Time Awake Since Boot: 11000 seconds
Time Since Wake: 900 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007ffeeb6ca000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x7ffeeb6ca000:
Stack 00007ffeeaeca000-00007ffeeb6ca000 [ 8192K] rw-/rwx SM=PRV thread 0
-->
Submap 00007fff00000000-00007fff80000000 [ 2.0G] r--/rwx SM=SHM machine-wide VM submap

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 plugin.dylib 0x00000001058b4e00 base64_encode(unsigned char const*, unsigned int) + 80 (base64.cpp:53)
1 plugin.dylib 0x00000001058d067c WhiteWhale::toJson() + 60 (string:1213)
2 com.vcvrack.rack 0x000000010455ed1d rack::ModuleWidget::toJson() + 269
3 com.vcvrack.rack 0x000000010456642e rack::RackWidget::toJson() + 414
4 com.vcvrack.rack 0x0000000104566037 rack::RackWidget::savePatch(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) + 87
5 com.vcvrack.rack 0x0000000104567c78 rack::RackWidget::step() + 488
6 com.vcvrack.rack 0x00000001045996da rack::Widget::step() + 42
7 com.vcvrack.rack 0x00000001045996da rack::Widget::step() + 42
8 com.vcvrack.rack 0x00000001045996da rack::Widget::step() + 42
9 com.vcvrack.rack 0x00000001045996da rack::Widget::step() + 42
10 com.vcvrack.rack 0x0000000104564ac8 rack::RackScene::step() + 184
11 com.vcvrack.rack 0x000000010454d4f0 rack::guiRun() + 1040
12 com.vcvrack.rack 0x00000001045555aa main + 698
13 com.vcvrack.rack 0x00000001045373e4 start + 52

Thread 1:
0 libsystem_kernel.dylib 0x00007fff787f56da __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff7892f26f _pthread_wqthread + 1552
2 libsystem_pthread.dylib 0x00007fff7892ec4d start_wqthread + 13

Thread 2:
0 libsystem_kernel.dylib 0x00007fff787f56da __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff7892f06a _pthread_wqthread + 1035
2 libsystem_pthread.dylib 0x00007fff7892ec4d start_wqthread + 13

Thread 3:
0 libsystem_kernel.dylib 0x00007fff787f56da __workq_kernreturn + 10
1 libsystem_pthread.dylib 0x00007fff7892f06a _pthread_wqthread + 1035
2 libsystem_pthread.dylib 0x00007fff7892ec4d start_wqthread + 13

Thread 4:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x00007fff787ebe76 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff787eb390 mach_msg + 60
2 com.apple.CoreFoundation 0x00007fff51025dd5 __CFRunLoopServiceMachPort + 341
3 com.apple.CoreFoundation 0x00007fff51025127 __CFRunLoopRun + 1783
4 com.apple.CoreFoundation 0x00007fff51024797 CFRunLoopRunSpecific + 487
5 com.apple.AppKit 0x00007fff4e7742d1 _NSEventThread + 184
6 libsystem_pthread.dylib 0x00007fff7892f6c1 _pthread_body + 340
7 libsystem_pthread.dylib 0x00007fff7892f56d _pthread_start + 377
8 libsystem_pthread.dylib 0x00007fff7892ec5d thread_start + 13

Thread 5:
0 libsystem_kernel.dylib 0x00007fff787f51d2 __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff78770754 nanosleep + 199
2 libc++.1.dylib 0x00007fff76724934 std::__1::this_thread::sleep_for(std::__1::chrono::duration<long long, std::__1::ratio<1l, 1000000000l> > const&) + 73
3 com.vcvrack.rack 0x0000000104538246 rack::engineRun() + 1126
4 com.vcvrack.rack 0x0000000104538cfd void* std::__1::__thread_proxy<std::__1::tuple<void ()()> >(void) + 93
5 libsystem_pthread.dylib 0x00007fff7892f6c1 _pthread_body + 340
6 libsystem_pthread.dylib 0x00007fff7892f56d _pthread_start + 377
7 libsystem_pthread.dylib 0x00007fff7892ec5d thread_start + 13

[metaphorz]

In looking at the file structure on github, there is no [res] folder, hence no graphics.

[Dewb]

That’s correct, there are no graphic resources or jack labels yet.

You should build against the master branch of Rack, not 0.5. Apologies, that’s not specified in the instructions, I’ll add it.

EDIT: there are graphics and jack labels now, enjoy

[Dewb]

If anyone is still having trouble, I recommend trying the following:

• Clone VCVRack again to a new folder -- some APIs and dependencies have recently changed, and it's easier to start from scratch.
• make dep and make in the Rack folder.
• Clone monome-rack into the plugins folder.
• Make sure you run git submodule init --update --recursive in the monome-rack folder after you clone it.
• Run make in the monome-rack folder.
• Go back to the Rack folder and run make run.

If you still can't use the modules in Rack after that, tell me exactly what you did, and paste the full log output that Rack prints to the terminal. Thanks!

[metaphorz]

@Dewb: If I follow you, the latest dev build is needed to make your modules? If this is so, and one
requires the latest 0.5.X executable, will this cause issues for other plugins? Almost all plugins I know of, build on the 0.5.0 source tag on Rack

[Dewb]

@metaphorz Yep, that's correct, I was originally tracking master because I wasn't planning to release this until Rack 0.6. Now that people know about it, it would make more sense to target 0.5 until 0.6 comes out.

The backstory is that while this is a work in progress, I wanted to do it a little bit publicly so I could get feedback on the Lines forum from technical experts in the monome community about the emulation approach before I went too far down this rabbit hole.

I didn't anticipate the VCV Rack Facebook group getting wind of this and lots of people trying to actively use it in their workflows while I was still writing emulation code and fixing bugs!

But I do indeed want people who are willing to test it prior to the official release to have an easy time of things, so I will retarget monome-rack master back to the Rack v0.5 branch tonight. I am taking advantage of some post-0.5.0 changes, but nothing critical, I don't think.

[Dewb]

@metaphorz It turns out that monome-rack still builds fine with Rack v0.5. I've updated the recommendation in the documentation.

The crash you reported was also reported by someone on Lines. The root cause is that the firmware .dylib wasn't built correctly, but it still shouldn't crash; I believe the crash bug should be fixed by 6f97190. The other user's build issue was resolved by re-running git submodule update --init --recursive inside the monome-rack folder. If you do that, followed by a make clean and a make, and paste the output from those commands here, I can investigate why your firmware build is failing.

[metaphorz]

@Dewb: builds fine for tag 0.5.0. I agree with you on the difficulty of operating privately until the modules are ready for prime time. Is there a private option in github? It seems that the FB folks are just doing global searches and finding everything even if there are no releases.

[phdsg]

i think you can have private repos if you pay for github :)

[metaphorz]

Well, that sucks.

…

On Dec 15, 2017, at 12:56 PM, phdsg ***@***.***> wrote: i think you can have private repos if you pay for github :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Dewb]

It's okay. If I had wanted to develop completely privately, I have ways to do that. I did want to do it slightly publicly for some early feedback from specific groups, as I said earlier; I just didn't anticipate the broader interest.

I'm glad people are excited; I'm happy to have beta testers and I hope lots of music is made with these once they're released!

[Dewb]

@antoniograzioli Were you able to build successfully?