
Show HN: MRuby-Zest – A Scriptable Audio GUI Framework - fundamental
http://log.fundamental-code.com/2018/06/16/mruby-zest.html
======
fundamental
Hello HN,

Two years back or so I was trying to build a new user interface for the
ZynAddSubFX synth and getting the level of customization I wanted while being
able to embed the interface cleanly into plugin hosts was difficult. I could
have gone the route of producing a series of raster based assets and providing
fixed locations for everything, but since I had different devices with rather
different resolutions I wanted something to be more flexible than that. After
starting with Qt prototypes I borrowed the ideas of Qt's QML and applied them
to a ruby based widget system (I would have gone with com mon-lisp + CLOS, but
that's not the best route to entice contributors), a nanovg/OpenGL rendering
system, and a open sound control based messaging layer between the GUI and
backend. Initially there was a GLPK based layout system, though that was
unfortunately scrapped due to the runtime cost.

The end result is MRuby-Zest and it's a system that's reasonably efficient,
embeddable, and in my opinion fast to iterate upon designs. The last note is
mostly due to the fact that the system can hotload code updating existing
widgets in a live GUI. That hotloading combined with the fact that widget code
is all ruby (rather than building off an existing C/C++ toolkit) has made
working with the framework pretty fun for myself. Overall the project is still
pretty young and somewhat tied to the Zyn GUI (named Zyn-Fusion), but I
thought some of the design choices and trade-offs might be interesting to the
broader HN community.

Outside of the technical choices this work is some of the first open source
work that I've seriously tried to get community funding for. After working on
the software for a few (~3) months fulltime I was able to put binaries up for
sale and I've managed to get ~200 sales for my efforts.

~~~
pjmlp
Nice overview, it looks quite good.

Have you thought about bringing in Crystal when it gets more mature?

Congratulations on the sale and good luck with the project.

~~~
fundamental
I've seen Crystal a few times in the past, though I haven't used it for a
project so far. Looking at their website and issue tracker it looks like it
would be rather difficult to be able to hotload code if Crystal was used
compared to MRuby (based upon the notes that a Crystal REPL isn't a primary
feature as a compiled language). Additionally I can't find too many details
(though I'm sure they're there) about the runtime requirements imposed by
Crystal applications. One of the nice things about the MRuby implementation is
that it makes it easier to combine all parts of your program (C extensions and
ruby compiled to VM instructions) into a single binary with minimal external
dependencies.

------
monetus
This looks pretty interesting. I'd like to play around with it. Kudos to you.

Aside: Did you know the FUDI protocol(0) used in the pure data language is
dead simple, if you wanted a faster bridge than OSC into/from that language.

(0) - [https://en.wikipedia.org/wiki/FUDI](https://en.wikipedia.org/wiki/FUDI)

~~~
fundamental
Neat. I have seen a few talks about pure data, but they tend to mention
transmission of data across the network, but not how they do it. In terms of
message communications for audio tools (beyond just MIDI) I've heard OSC
discussed a fair bit, LV2 atoms somewhat, and then a good variety of custom
protocols used by a single application.

I'm biased towards OSC however since the binary serialization is very easy to
manipulate in a realtime context (i.e. no locks, no dynamic memory). In fact I
was biased enough that I ended up giving a talk at the linux audio conference
about realtime safe OSC
[http://lac.linuxaudio.org/2018/pages/event/39/](http://lac.linuxaudio.org/2018/pages/event/39/)
(with some nice performance figures to boot). It's cool to know what puredata
is actually using under the hood.

~~~
monetus
Oh, thanks for the link. I'm about to read your paper.

I should clarify that when I said FUDI is faster, I was repeating the
grumblings I've heard on pd's email list, despite not having benchmarked
anything myself. With tcl's "everything is a string" (0) format, I could
imagine this being contextual. But I am really curious.

(0) - [https://wiki.tcl.tk/3018](https://wiki.tcl.tk/3018)

You might find this kinda funny, a piece of pd's documentation regarding the
osc objects:

"OSC is a complicated networking protocol (FUDI, as used in netsend/netreceive
is simpler and better but less widely used). oscparse and oscformat make no
attempt to deal with timetags or aggregates of packets, nor with streaming
OSC. Also, no attempt is made here to clearly distinguish between the OSC
address (symbols) and the following data, nor between blobs and lists of
numbers - it is assumed that you know what types the message should contain.
You can alternatively use the OSC objects from mrpeach which have more
features than these."

~~~
fundamental
I can't really blame them for their position. OSC has some really cool ideas,
but the standards organization that was shaping the protocol ended up
dissolving (somewhat) before all the rough edges could be sorted. I personally
find it to be a nice serialization format with enough complexity to do what
you need without it becoming all consuming.

------
zengid
If you went and watched the talk, here's the other talk Mark refers to on OSC:

[https://media.ccc.de/v/lac2018-39-rtosc_realtime_safe_open_s...](https://media.ccc.de/v/lac2018-39-rtosc_realtime_safe_open_sound_control_messaging#t=1)

------
ttoinou
Looks great but don't know how to use the UI. Would you add some examples in
the future, so that users can load and play with ?

~~~
fundamental
One of the plans down the line is to create a few views as essentially "widget
zoos". These will hopefully serve as illustrative examples as well as
locations where the automated screenshot mechanisms can be used to collect
pictures of common widget types.

Right now if you get the GUI running by building from the mruby-zest-build
repo, then you'll be able to start the interface and it will load up
MainWindow.qml as well as child widgets.

~~~
ttoinou
I meant music / tracks / synth examples ? I would be ok to follow a tutorial
about how to use the interface but having real life examples to tinker with is
more fun ;)

~~~
fundamental
At the bottom of [http://zynaddsubfx.sf.net/](http://zynaddsubfx.sf.net/)
you'll see some examples of the synth in action from the community. If you're
looking for particular walkthrough/tutorial video content there's a few videos
linked in a playlist at
[http://zynaddsubfx.sf.net/support.html](http://zynaddsubfx.sf.net/support.html)
. Some work is being done to the manual to both update it and make it more
user friendly (i.e. discuss what is available in the program and _why_ you'd
want to use it), though the linked pages only have the older docs at the
moment.

------
nopacience
F A N T A S T I C !

