#1

Figured it was about a good time to start this thread :wink: (I know we ALL want to use that new mlr)

Before all the source is out (take your time guys), my rough plan was to use something like Electron to glue the web code from maiden to a desktop version of the matron environment (some sort of local server business Iā€™m guessing). Since I donā€™t think weā€™ve heard much about how matron runs (hopefully itā€™s not too low-level) I donā€™t know the specifics of how to get them to talk, but Electron has access to Node.js, and Node.js kind of does everything so I feel thereā€™s a good chance it could work. Thereā€™s already examples out there for integrading SuperCollider with Node.js, and Node.js with OSC.

Anyway, seem feasible? Iā€™m certainly going to be working on this, but is anyone else interested in contributing code/knowledge?

6 Likes
#2

My understanding is that you wonā€™t need such a thing if itā€™s all running on your laptop.

It appears that maiden/matron mainly exists to facilitate accessing code and files on norns, norns being the server and your computer being the client. Iā€™m guessing that the same could be done with an ftp application and a terminal. Running lua and supercollider on your laptop, you will probably just open up a directory and get to the stuff that way. Weā€™ll have to learn more about the stack of lua applications, crone, and supercollider.

(norns devs - please correct any of this if Iā€™m wrong)

1 Like
#3

Perhaps something like a norns docker image might be useful for prototyping.

2 Likes
#4

Yea, that might be the case, again we donā€™t know too much about matron yet. Iā€™m also kind of thinking about it in terms of not having to open up two applications & move files around in order to run one program. like, if one application could open up and run everything bundled together in one environment that would be more accessible for people. That doesnā€™t necessarily mean maiden needs to be involved, I was just trying to think of a solution that could keep the same interface that the real norns people would be using.

#5

Docker is a bit much overhead, but I can certainly imagine setting up a vagrant box for this. I think itā€™s a good idea to replicate the norns environment as closely as possible, including the operating system.

If we regard the OS + applications + data as the ā€œfirmwareā€ for norns, then forking this vagrant box would be a way of developing ā€œalt firmwareā€ (so to speak).

But all will be much clearer in about 16 days when the source is releasedā€¦

3 Likes
#6

I had totally forgotten about Vagrant! Must have been buried in the buzzword pile at work.

1 Like
#7

maiden is the editor, a web app and minimal server. yes, this is basically platform agnostic.

crone is the supercollider side, and is afamily of SC extension classes that also runs fine on many platforms. (it does include some custom ugens that require compilation - they work fine on macos but the default build scripts donā€™t take darwin-specific stuff into account.)

matron is the tricky part, a C program which hosts lua and has low level glue to hardware, via linux.

at the moment (and it is not yet finished):

  • on linux, it mostly works out of the box. but without the norn hardware there is no screen, no buttons, and no encoders. all of these are connected through i2c/spi/gpio and sysfs (screen is a framebuffer) - these points of access are provided by kernel overlays.

so its still debatable whether emulation layer would best be done at the system level or code level.

  • on macos, there are some libraries missing that matron requires, relating to peripheral connections and to scheduling. (ALSA for midi, libudev for HID, fully-featured posix clocks for timers.) so some adapter layers would need to be written for a fully-functional macos port.

maybe both could be addressed at once by using something like SDL or juce as a wrapper for desktop builds. this is a C/C++ job and itā€™s not trivial (which is why we havenā€™t done it just yet.)

once matron is running, there is not much to do. REPL input and output is via websockets; so yes, you shold be able talk to them with your hackable editor of choice. (switching to IPC sockets or a different transport layer is trivial too.)

and yes, all will be clearer when the source is released.

6 Likes
I2C questions / discussions
#8

Would an adapter be needed for OSC support in macOS? I wonder if we could just start out with a low-functioning MacOS version. Otherwise I wouldnā€™t mind starting off with a Linux-only environment. Mostly just interested in creating a pathway for less-code savvy people to get involved with new norns applications without owning one.

1 Like
#9

Would an adapter be needed for OSC support in macOS?

no. we use liblo and it works fine on macos

#10

Once somebody has set up a vagrant box and shared it to https://app.vagrantup.com/boxes/search users will be able to do something like this:

$ vagrant init monome/norns  
 
$ vagrant up 
Bringing machine 'default' up with 'virtualbox' provider... 
==> default: Importing base box 'monome/norns'... 
==> default: Forwarding ports... 
default: 22 (guest) => 2222 (host) (adapter 1) 
==> default: Waiting for machine to boot...   

$ vagrant ssh 
vagrant@norns:~$

and thatā€™s that. good to go. thatā€™s the idea, anyway.

(edit: of course, this assumes the user has previously installed vagrant)

#11

in general (and i know there are a lot of variables) does vagrant play well with linux I/O layers like libudev/libevdev? what about ALSA+jack?

how doe it stack up to, say, parallels? (in which iā€™ve had trouble with both of the above)

iā€™ve usually turned to dual-booting whenever i actually need mac hardware to run linux stuff in a realtime context.

#12

Iā€™ve generally had bad experience with even basic audio output from VMs running under VirtualBox or VMWareā€¦

#13

Does matron maintain itā€™s own internal framebuffer of the screen? And if so, could it make it available to maiden via some newfangled web technology? Likewise, could maiden send simulated encoder and button messages to matron.

That way itā€™s one less piece of technology to add to the mix.

Iā€™m not sure what the performance overhead of sending out a framebuffer at xFPS will be, maybe it only pushes out if the frame has changed, for the desktop itā€™s unlikely to be that bad. If the overhead is minimal it might even be a useful feature to use with the hardware when your norns is not within arms distance (e.g. your norns is on a pedal board).

#14

This was my motivation for putting maiden into Electron instead of running it on the web like normal, because theoretically that lets web code access things at the hardware level. Potentially that could eventually get to knobs emulation and screen rendering without going through crazy network web loopholes (not sure how it would play out in practice though, since everything with that is node.js). But as others have mentioned we technically donā€™t need maiden on desktop, and can just use any editor, which a rendering screen could be hacked onto eventually. I just wanted to use the actual web code from maiden for consistency.

#15

i agree, that would be useful. matronā€™s drawing system is a thin wrapper for cairo. it maintains a cairo surface, pointed at a linux framebuffer device attached to the hardware screen. iā€™d guess that there is some relatively painless way to get the pixels out of the surface and/or mirror it to an output image, just havenā€™t explored it.

[ed] yeah looks pretty straightforward
https://cairographics.org/manual/cairo-Image-Surfaces.html

#16

Oh nice. I was thinking that was gonna be more custom. Seems like thereā€™s a good chance a renderer could be worked into whatever the desktop editor ends up being then.

#17

Iā€™ve done a bit of work with cairo before, I have a bit more experience with Quartz from back in the day. Theyā€™re conceptually pretty similar.

Anyway, should be easy enough to grab a PNG from a surface:

cairo_status_t
cairo_surface_write_to_png_stream (cairo_surface_t *surface,
                                   cairo_write_func_t write_func,
                                   void *closure);

https://www.cairographics.org/manual/cairo-PNG-Support.html#cairo-surface-write-to-png-stream

There is a function to write directly to a file too, but thatā€™s probably not needed.

1 Like
#18

Vagrant is just a bit of plumbing around VM engines such as virtualbox and I wouldnā€™t anticipate that it behaves significantly differently from any other VM system.

Hard to comment further without more info about the specific problem you are anticipating. Agree that dual booting sounds wiser but itā€™s going to reduce the potential audience by an order of magnitude or more. Perhaps thatā€™s as it must be.

1 Like
#19

well this is why my preference would be for a native macos layer. which should not be an enormous issue.

problems anticipated are just the general failure of linux realtime and audio stuff to basically work at all under VMs - - certainly not well enough for a music performance system. iā€™ve never had this be very functional regardless of the software, distro, &c. massive latency and underruns at best. (i donā€™t know about HID-level events but imagine it could be rocky.)

but you knowā€¦ macs are really sucking these days for music performance, at the hardware level. i have a recent MBP that is basically useless in this regard because of dropouts in usb-c connections. old MBA running debian works just fine. maybe it is just time to let goā€¦

8 Likes
#20

Iā€™m also very ready for a linux future of music, I think that should be a goal eventually. For now though, I feel like part of the advantage of a desktop version of the norns environment would be the ability to integrate it with other music applicationsā€¦ which are all pretty much on macOS at this point. Someday. It doesnā€™t seem like maintaining two platforms would be too much work though, I think we could target both.