#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
#31

It’s a very neat setup with tmux too - I wouldn’t have thought of that as a way to run everything together and visibly.

1 Like
#32

Thanks for the feedback. I’m hoping to get sound output working on OS X eventually, partly because sometimes I’m on my laptop which runs OS X, and partly as I think that will be the best way to get more contributors.

Yeah, I wasn’t entirely sure what the best way was at first. I really didn’t want to have to go down the route of a service manager like runit.

I think I had installed tmux into the container and was manually starting each component when I was testing it out, and just thought there must be a way to automate this… (it was highly tedious).

I think my next plan of attack is to try to hack maiden into opening an X11 window for screen output and key/enc input. I’m not planning on it being pretty, really just a proof on concept at first. That should also give me enough first hand experience to start writing a dev workflow guide.

2 Likes
#33

The norns-image repo has the systemd unit files which are used on the actual device - that might be of use. There has been some talk of exposing the ability to restart crone and matron from within maiden so it might make sense to stay with systemd for compatibility reasons.

1 Like
#34

Alas, systemd does not work in Docker.

If you’re really bored:

#35

…ah yeah. I had forgotten that. The topic of packaging the norns software via snap or flatpak has come up on more than one occasion. The motivation is trying to improve the reliability of the update process and offer an easy way to fall back to an older version of the software if need be. Neither of those technologies play nice with docker unfortunately…

#36

AFAIK Flatpak uses the same kind of technology as Docker. I reckon you can make either of them emulate the other to a certain degree.

Is Flatpak a container technology?

It can be, but it doesn’t have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications. In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing.

Source

Arguably if you were going down this route, Docker or systemd-nspawn would be a better fit than Flatpak or Snap (and you could also argue the converse too).

I will say that Docker has a tendency to eat storage space if you’re not careful.

Why not just use dpkg for package management?

1 Like
#37

Anyone know what’s going on with this? Also I’d love some help getting it hooked up to alsa/jack on Arch. I’m gonna make a thread today but thought I’d mention it here, too. :stuck_out_tongue:

#38

It works. No display support yet.

I’ve been incredibly busy the last few weeks so I haven’t had much time to take it further (yet). Start with the top post and follow the links.

In particular hit up my GitHub repo: https://github.com/samdoshi/norns-dev

1 Like
#39

Many thanks! I just got my first grid so I wouldn’t mind just having something to play with while I save up for Norns!