#11

The baby was sick overnight, so apologies if my replies are incoherent.

I had to build SuperCollider from source to get it to run inside Docker, else it complained about a lack of X11 (need to disable QT), the following worked for me (pasted directly from the Dockerfile):

ENV SC_VERSION=3.9.3

RUN mkdir -p /tmp/sc && \
    cd /tmp/sc && \
    wget -q https://github.com/supercollider/supercollider/releases/download/Version-$SC_VERSION/SuperCollider-$SC_VERSION-Source-linux.tar.bz2 -O sc.tar.bz2 && \
    tar xvf sc.tar.bz2

RUN cd /tmp/sc/SuperCollider-Source && \
    mkdir -p build && \
    cd build && \
    cmake -DCMAKE_BUILD_TYPE="Release" \
          -DBUILD_TESTING=OFF \
          -DSUPERNOVA=OFF \
          -DNATIVE=OFF \
          -DSC_WII=OFF \
          -DSC_QT=OFF \
          -DSC_ED=OFF \
          -DSC_EL=OFF \
          -DSC_VIM=OFF \
          .. && \
    make -j && \
    make install

Most of that is more or less copied from the GitHub repo listed at the bottom of the second post in this topic.

Thanks for that, I think I might have known about it, I think…

I suspect my short term memory won’t be recording today, so can someone remind me of it’s existence when the time comes to package our investigations up into a useful product.

Now that is pretty cool. I’ve always been really frustrated by the lack of sensible tooling for building Raspberry Pi images, most of it seems to be “do it on the device, then image the SD card”.

It will be interesting to see where this goes. Convergence between development environments and final image building would be awesome.

Just summerising for myself, there is the potential for:

  • Docker dev env using NetJack2
  • Vagrant x64 VM
    • using NetJack2
    • using USB passthrough
    • using emulated audio
  • Vagrant ARM VM
    • using NetJack2 (crossplatform NetJack2?)
    • using USB passthrough
    • using emulated audio
  • ARM image building

For now, I’ll stick with the first, we don’t want to get too ahead of ourselves!

1 Like
#12

FWIW - (after compiling sc 3.9.3) I got norns running (kinda) tonight and got audio from the linux box to come out of my mac speakers, but ran into a few issues with the various norns services not getting started on boot. Probably will start with a fresh vagrant box install tomorrow to be sure I have all the steps documented.

Noticed this error on running slcang or crone

sc3> ERROR: API version mismatch: /home/vagrant/.local/share/SuperCollider/Extensions/norns/BufWrPre.so
    This plugin is not compatible with SuperCollider >=3.9.0
    The plugin has not been loaded; please find or compile a newer version.
    (Plugin's API version: 2. Expected: 3)
2 Likes
#13

Probably best to make a ticket for that issue on the Norns bug tracker. There has been much talk about info like that getting lost.

The source for the UGen is here.

Looking forward to seeing the Vagrantfile when you’re ready!

#14

You’ve always been able to cross-compile images, it’s just a bit of a pain to setup. So often laziness rather than tooling.

But these days there’s easier solutions, as many things like buildroot support it out of the box. I particularly like Armbian, higher level than some, but still a complete environment you just install and run.

I’ve actually been looking at armbian for the Organelle, so that C&G can just ‘click a button’ to build a completely fresh os image - as they created the original by hand then seem to have ‘lost’ how it was created :wink:

(It would be pretty simple to do for Norns too)

#15

What jackdrc settings are working for you?

I finally got norns making sound, but it’s all crunchy/distorted.

#16

Is vagrant the way to go on macs instead of docker? I don’t think it can access the native soundcards…

#17

Sorry for the delays folks. The baby’s sick turned out to be a stomach bug which spread around the house…

The summer holidays have just started in the UK too, so no idea when or what time I will have for a few weeks.

No you can’t access native sound cards from Docker for Mac as far as I know. You can do it on Linux, but I believe it means exclusively using that soundcard inside the container.

It’s possible that the same Jack network code that I’m using with Docker might also be able to send audio from the Docker for Mac1 guest to the OSX host and that it might have better audio performance than an emulated soundcard.

I think I mentioned it earlier, but we should be easy enough to translate a working Dockerfile into a Vagrantfile (and vice-versa) once we know what we’re doing. So any knowledge towards that goal is useful.

1 Also the same technique could be used with Vagrant

#18

FWIW - I have built norns and got sound working in Vagrant with Virtualbox on MacOS (with Mac native/built-in audio), but I’ve not created a Vagrantfile as that’s a little outside of my skill set so far.

However, the sound is glitchy as hell and pretty much unusable so I kinda gave up on this.

EDIT: I can post my install notes if someone else wants to make a Vagrantfile

2 Likes
#19

I will try to make a working Dockerfile for norns and try this audio approach. Will report once I’ve gotten somewhere :slight_smile:

2 Likes
#20

Here’s a Dockerfile where things appear to compile but portaudio is not setup yet. You can ssh interactively and start crone.sh but complains about audio as well as other stuff. May be easier to use NetJack2 for the time being but hopefully this is a good start:

1 Like
#21

Here is my Gist talking through how to use NetJack2 to forward audio from SuperCollider inside a container to Jack running on the host.

I’m hoping that the README.md is sufficiently detailed. Any Linux users that want to try it out and let me know how it goes?

I’ve also had a weird intermittent XRUN issue. Sometimes when I start the NetJack2 session I get constant XRUNs at a rate of about 1 or 2 a second, other times it’s perfect. I’ve tried fiddling with the size of period and nperiod in Jack, but with intermittent issues like this it’s a complete pain to diagnose.

Anyway, feedback is appreciated, seeing as it works on my computer (most of the time), it would be good to know if it works elsewhere too.

1 Like
#22

I really meant it when I said I worked slowly.

Anyway, an updated method, this time using ALSA passthrough to the container. Essentially due to the way that containers work, the kernel is shared, including /dev/snd (i.e. ALSA).

It’s was a bit of a pain trying to figure the correct set of incantations to get it to work inside Docker (especially dealing with group ownership), but it does work, and it it gives native performance. The downside is that you have to dedicate a soundcard to it, and there is no hope for it working on OSX or in a VM.

This Gist gives a worked example of getting SuperCollider running inside a container with native performance, along with some technical info as to how it works.

I’ve also updated the first post with a summary.

Now that I have decent audio performance it’s time to actually get Norns running, plus the school holidays are about to finish so I might have some time!

5 Likes
#23

Well, I’m making surprisingly good progress on getting Norns installed into a Docker container…

…apart from https://registry.yarnpkg.com/ being down, even though it’s up https://status.yarnpkg.com/

Why Javascript, why!

(need to vent!)

edit:

1 Like
#24

Success! Awake plays!

I had to patch the yarn.lock file to deal with the DNS issues. It also looks like registry.yarnpkg.com is going away in the long run (yarnpkg/yarn#5891), but I’m not sure what we’re supposed to do about it.

All is not completely perfect as I’m getting seg faults in matron with some of the scripts, but on the plus side it will be very easy to gdb!

I’ll try to get a repo up this week (hopefully once Yarn have sorted their DNS issues), and then it will be time to start thinking about what direction to go in.

Some ideas to get everyone thinking:

  • reproducible dev environment, and what’s a good workflow
  • OSX support (via NetJack2)
  • Windows support (via NetJack2)
  • CI support for the dust repo
  • screen/keys/enc support via X11 (or otherwise…)
  • grid / arc support

And just to re-emphasises what I stated earlier:

4 Likes
#25

This is great. Following it closely. Do you have your latest Dockerfile?

#26

It’s not online yet.

I’m going to try and put it up in a GitHub repo this week along with a proper README.md.

If I haven’t done it by next weekend feel free to harass me and I’ll get it in a Gist just to make sure that the info is out there.

edit: Got the grid working too! That was a little tricky, but essentially udev is a bit wonky inside the container, so I had to build libmonome to use sysfs instead.

edit 2: Added some notes to the first post with results from experimentation on OS X (i.e. couldn’t get NetJack2 in the Docker container to see the host)

edit 3: Added some notes about running gdb inside the container… now I just need to figure out this backtrace…

Matron backtrace 
Thread 1 "matron" received signal SIGSEGV, Segmentation fault.
_screen_extents (l=0x563220a44638) at ../matron/src/weaver.c:737
737	  lua_pushinteger(l, xy[0]);
(gdb) bt
#0  _screen_extents (l=0x563220a44638) at ../matron/src/weaver.c:737
#1  0x00007fd19d92c77e in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#2  0x00007fd19d939565 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#3  0x00007fd19d92cb6f in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#4  0x00007fd19d92cbc1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#5  0x00007fd19d92bf92 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#6  0x00007fd19d92ce4d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#7  0x00007fd19d9285c1 in lua_pcallk () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#8  0x000056321f87d0eb in docall (nres=0, narg=0, L=0x563220a44638) at ../matron/src/lua_eval.c:140
#9  l_docall (L=0x563220a44638, narg=narg@entry=0, nres=nres@entry=0) at ../matron/src/lua_eval.c:149
#10 0x000056321f883eb2 in w_handle_engine_loaded () at ../matron/src/weaver.c:1515
#11 0x000056321f87c673 in handle_event (ev=0x7fd1880062e0) at ../matron/src/events.c:236
#12 event_loop () at ../matron/src/events.c:158
#13 0x000056321f878fe9 in main (argc=<optimized out>, argv=<optimized out>) at ../matron/src/main.c:90
3 Likes
#27

Here we go…

Still lots to be done. Expect some force pushes until things are stable. I’ll update the top post once we’re a little further along.

Also, the automated Docker hub builds are borked. I think it may be too much RAM usage from sc3-plugins, will try to get it to build -j1 and see if that fixes it.

I also found this rather interesting repo:

Could be useful for automating the building of images.

Anyway… more to come this week hopefully.

6 Likes
#28

This is now working (with audio / grid on Linux)!

If you have Docker installed (Linux / OS X / Windows?):

docker run --rm -it \
    --ulimit rtprio=95 --ulimit memlock=-1 --shm-size=256m \
    -p 5000:5000 -p 5555:5555 -p 5556:5556 \
    samdoshi/norns-test-dummy

(Type ctrl-b d to exit, it’s tmux.)

(FYI: it will download 500MB-1GB of data)

and visit http://127.0.0.1:5000/maiden/ in your browser. There is no audio.

For working audio and grid on Linux see norns-test-dummy.

Top post updated with this info too.

2 Likes
#29

Great. Look forward to trying this later.

1 Like
#30

Very smooth working on OSX here. Will also try on a Linux VM for sound.

1 Like