Aleph bees UI help? (JUCE)

Tech
#1

hiya,

just wondering if there are any aleph users with node.js chops who might be into pitching in to help build a graphical BEES editor? details and background follow.

the BEES editing interface, we can all agree, leaves a lot to be desired. one of the design goals of BEES is that it be possible edit all patch parameters from the device itself, without busting out a laptop. but it was never intended to be the only way to edit.

i made some tools to facilitate offline editing, namely a converter between the BEES binary scene data and a JSON representation. (i also made a GTK editor that, frankly, sucked, and never managed to get it running reliably on macs anyway.)

now, two years on, i would like to get this going again. a while ago there was someone intending to make a graphical editor in javascript, but it never happened. we do have the JSON tool and a schema, which i just now, finally, fixed up and validated in my fork: https://github.com/catfact/aleph/blob/dev/utils/beekeep/bees_schema.json

i’m seeing this tool called Node-RED ( http://nodered.org/ ) which seems like a pretty easy way to get something like this going. (an example of site using it: http://www.pjrc.com/teensy/gui/?info=AudioInputI2SQuad )

(there are tricky details, of course. the preset system in BEES adds another dimension to this kind of graph…)

this seems like a weekend project. i’d be happy to do it myself but would rather spend weekend hacking time on the DSP side. and i figured there might be aleph users who are more proficient in building and distributing node.js apps.

another reason to get this going now is that thanks to @rick_monster we have a basically-working serial protocol for live editing a running scene on the aleph. (in the dev branch.) his host-side environment is pretty hardcore though (no dis!) and i think it would be super useful to have an accessible front-end to that protocol.

let me know your thoughts!

2 Likes
#2

i’m not a javascript hacker but i had been staring at electron several months back as a way to built a cross platform editor for bees… electron seemed like a quick way to get self contained application with direct access to disk and serial ports.

1 Like
#3

hm, cool thanks. so if i read it right, this is a way to easily package a node.js app with chromium in a cross-platform way? (man, i feel old and lame looking at this site.)

lately i’ve been doing some c++ hacking on the chromium framework for job stuff. it already has javascript bindings… so this really seems like a minimal glue layer between that and node. still, cuts out some tedious management.

#4

i guess what i’m really wondering is, where is a good library for drawing boxes and patchcords? don’t care what language it’s in. word is that max/msp uses JUCE (which i like) but haven’t found anything like that in the OSS world. rolling one’s own (a la PD, in tcl/tk) seems like it should be unnecessary (and more than a weekend.)

#5

Will at least document the protocol properly, heck I’ll even quickly port my test-harness api to node if someone wants to get busy with the editor.

My aleph priority now serial comms are mostly working is better tooling for DSP dev so am similarly reluctant to take on a GUI app…

1 Like
#6

jointjs and jsplumb also seem worth considering. I’ll give some more thought to this tomorrow.

Edit: & GoJS

#7

The first two seem to do more heavy lifting for you:

Draw2D

  • Docs
  • Data Binding: Watch.JS, Backbone.js, Backbone.ModelBinder, JavaScript, RivetsJS
  • Read: JSON
  • Write: JSON, SVG, PNG
  • Undo
  • Zoom
  • Touch Events

JointJS/RAPPID

  • Docs
  • Data Binding: JavaScript
  • Read: JSON, LocalStorage
  • Write: JSON, LocalStorage, PNG, JPG, SVG
  • Undo
  • Zoom
  • Touch Events

jsplumb

  • Docs
  • Data Binding: JavaScript
  • Read: JSON, LocalStorage
  • Write: JSON, LocalStorage
  • Zoom

Node-RED

  • Docs
  • Data Binding: JavaScript
  • Read: JSON
  • Write: JSON

GoJS

  • Docs
  • Data Binding: JavaScript
  • Read: JSON
  • Write: JSON
1 Like
#8

I’d love a better understanding of the environment this will be running in.

What operating systems need to be supported? Is this environment running on a user’s computer, or from a webserver on the device itself or… ?

How about phones or tablets?

What’s the user like? Do they need to be able to understand how to install software from the command line on their chosen platform to use this? Or is this more of a tidy installer/works out of the box situation?

#9

Not a Javascript guy myself, but we recently tackled a visual cable-based modular patching system for one of our plug-ins. JUCE has an example modular plug-in host in its repo. It might be tough to read if you’re not familiar with JUCE, but it at least provides an example design pattern for visual modular systems. In particular, take a look at PinComponent and ConnectorComponent:
https://github.com/julianstorer/JUCE/blob/master/examples/audio%20plugin%20host/Source/GraphEditorPanel.cpp

1 Like
#10

running on desktop, probably don’t care about phones, assume the user is technically sophisticated enough to use the command line.

this could certainly be a hosted app using chrome.serial and chrome.fileSystem for starters.

electron looks like a good solution for subsequent packaging to desktop.

thanks a ton for the graph library roundup.

2 Likes
#11

thanks, that is very helpful. i have used JUCE a bunch, it’s a good solution; maybe a bit lower-level than i’d prefer for this. had seen that demo before but somehow pushed it to the back of my mind.

i would probably take that route myself. but i kinda thought maybe someone else might enjoy doing this, and thought that perhaps JS was a more familiar tool for people and could get the job done with minimal fuss. (maybe i’m totally wrong about that.)

#12

If you decide to go the JavaScript route, I’m happy to help.

JUCE seems very interesting as well, but I imagine there are others around here more qualified to help with that than I am.

#13

I wish I could help, but at the moment my dissertation is eating up any remaining free time.

I was thinking about it, and an even more relevant open-source example would be the Fish environment for Shbobo’s Shnth: http://www.shbobo.net/ The Shnth is typically programmed using Shlisp, which has Lisp-based syntax. There’s also a frontend graphical interface (Fish), which is programmed in JUCE. It doesn’t have the clean, cable-based interface that the JUCE plug-in host does, but it works in the way that Aleph does. The patching environment is used to generate text, which is then compiled for Shnth use.

Two more open-source modulars:
Axoloti: https://github.com/axoloti/axoloti
WREN: http://bluehell.electro-music.com/modules/

As far as Javascript goes, there’s a JS implementation of VVVV, which has visual patching:
http://www.vvvvjs.com/

I suppose that mashing up the VVVV patching code with the text generation of the Fish environment would work quite well.

EDIT: Here’s the relevant VVVV patcher JS code: https://github.com/zauner/vvvv.js/blob/master/editors/vvvv.editors.browser_editor.js

1 Like
#14

funny - i was the one who recommended juce to peter for the frontend, back when. ( not sure why it didn’t occur to me for beekeep frontend in the first place… I was hung up on just using pure c for some reason? wanted to try gtk anyways? who knows. sorry. )

( off topic: someday still want to port the shnth opcodes to c. shlisp is fun. don’t think the port would be as hard as it seems at first glance. )

I was hoping someone with a preferred toolset for this kinda thing would just volunteer. I’ll let this rest until next weekend or something, then if it’s still up to me ill just start in on a nicer frontend for beekeep. Probably with juce so it can just link bees sources and json<->scn converter directly.

@jasonw22 , do you have an aleph? Would be hard to work on this without one.

1 Like
#15

No, I wish I did. If anybody knows where to find one…

They come up for sale occasionally but the timing hasn’t lined up with my finances just yet.

#16

i’ll just chime in and say I LOVE the design and functionality of fish

i dont need faux cables
even tho UI elements like lumen and aalto’s are pretty cool

#17

well i got antsy and went ahead and started building a JUCE frontend.

not much functionality yet, but i did make it through the not-insignificant drudgery of linking bees source in a c++ program (oh yeah, that’s why i didn’t do this in the first place.)

so now there’s a thing where it initializes the control network and can create operators (right-click for creation popup.) each operator gets a JUCE component that can be dragged around on a canvas.

lots more work of course, still open for volunteers.

on my fork for the moment, until i add stuff that actually does things:

i think it’s helpful to actually have the bees code running in the editor. using JS would require more glue.

4 Likes
#18

Nice! Since you’re on JUCE, I’ll try to help here and there. I don’t have an Aleph, so I can’t really help with the guts, but I’d be happy to help out with graphics/skinning and general JUCE arcana. We do vectorized interfaces for our plug-ins (http://unfilteredaudio.com/images/sandman/sandmanretina.png). It ends up being really useful with the current trend of high resolution and high pixel density displays.

#19

i see, that makes sense. (plugin UI looks lovely by the way.)

so far: storing all node positions as double, relative to a big canvas, seen through a viewport. but at some point pixels come into it.

obvs it would be a good idea to be disciplined and only specify drawing dimensions as proportions of real screen size, some utlities using Desktop::getMainMonitorArea() or something. ( ed: yikes, really, Desktop::getInstance().getDisplays().getMainDisplay().totalArea now?)

would be curious if you can point at any OSS projects that already employ such a toolkit.

of course, doing all this stuff is kind of why i would have liked to just use a library made for drawing graphs… oh well…

2 Likes
#20

I’ll look around to see if there’s a great OSS JUCE app that employs decent interface standards.

Madrona Labs has his common code on Github:

Of particular interest: https://github.com/madronalabs/madronalib/tree/master/source/LookAndFeel

In general, as long as you draw your knobs/visual components via code (and not through pre-rendered images), the scaling for various pixel densities happens automatically (Retina screens, for example, are treated as 2x pixel density displays with standard resolutions. We didn’t have to write special code for our plug-ins to appear the same size on various densities. It’s more problematic, though, when you need to scale for overall area, which it sounds like you’re doing).

The Introjucer is a great tool for doing layout on more static interfaces (toolbars, frames, etc.). There, you can set positions and sizes of components as relative values instead of absolutes.

I’ll take a look at the code this weekend.

2 Likes