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

actually just went ahead and made some conversion routines between screen, canvas, and pixel coordinates, basic and certainly not optimized, but seems to work fine. i can still drag the boxes around, hooray. no pixel coordinates anywhere except in paint and mouse handling routines. so i think theoretically should be able to save a canvas and all its components and have it look the same on all screens.

haven’t tried with 4k displays yet. will do so (i have a 4k windows/linux laptop, believe it or not, probably just about the nastiest test case for this.)

definitely not gonna be using any bitmap assets for this thing. just want to get as much usable functionality done as i have time for. nicer to do the widgets in code.

Madrona Labs has his common code on Github:
https://github.com/madronalabs/madronalib

that is very cool, thanks.

1 Like
#22

Found this thread after a day of aleph sound experiments. I spent some hours in Inkscape drawing operator panels with inputs and outputs and realized I’m doing prep work for a GUI.

What’s the shortest path to get started with all of your existing work?

3 Likes
#23

honestly i did not get very far beyond:

  • making sure bees can compile under c++
  • re-acquainting myself with some juce stuff like viewports and resolution scaling

so there is this “utils/beekeep” project which at some point was just a CLI program to convert between binary scene data and a json representation. then i added a ridiculous gtk frontend and it got into its present state which is maybe a little borked. when i have time i can just roll back the gtk stuff.

there is aleph/utils/avr32_sim which provides stubs for all the missing hardware stuff./

“utils/beekeep_juce” is probably not very useful but it is there.

rick made a PD wrapper for bees also which is maybe a better starting point

thing is that i don’t really care about a UI (not sure who does.) it would be just good to have some way of editing bees patches offline. my preference would actually be for a little scripting environment.

my current thinking of how to implement this would be to bind bees to a lua interpreter.

but there are many options, the point is that it should be reasonably straightforward to bind bees to whatever FFI. if you wanted to design a UI in python or what have you.

1 Like
#24

agree with this - once you have arbitrary op insertion/deletion, patching is quite fast! scripting could be good for sharing snippets of scenes.

3 Likes
#25

I agree that a realtime GUI bound to a running scene is silly. Here’s my context.

SuperCollider was my first modular computer synthesis platform. After poking through examples and doing n00b copy pasta, I put together some live performances and I’m still proud of them. But I got stuck because I couldn’t figure out how all the UGens and Classes and methods fit together. So I began drawing literal graphs on paper, like a modular synth and “patching” inputs to outputs. Then I could translate that into the code, debug and boom!

I noticed the same kind of metaphor is used in the 7 part Aleph tutorial, pencil on graph paper. Initially, I began doing the same thing, then realized this is something a computer is good for. So now I have a bunch of reusable operator “panels”. I’m gonna do the inputs and outputs today.

I’m down with Lua bindings. That could be fun.

1 Like
#26

You can already sketch out scenes in the aleph pd external (and run them to some extent!). But there’s no tool to convert pd patch containing BEES ops into a BEES scene.

EDIT:

The thing that makes this suck somewhat is presets! pd has no concept of a preset afaik… and it’s really a very interesting concept for musical instrument control

3 Likes
#27

sweet, I know PD well so I’ll start there. I know you mentioned it before, can you refresh my memory of the location of your repo with the external code?

#28

code for pd/bees is now in monome repo’s dev branch, under utils/pd.

the build target ‘make test’ fires up an example scene letting you run aleph grid apps in pd (requires seralOSC or compatible :wink: ) & a hairy graphical programming example that could be better accomplished in a few lines of C! (on the right there in the patch, that mess draws a bright square with a dim diagonal line)

#29

I agree

whatever comes out of this will be exciting!

#30

I got the external built and the example patches load. I think at this point I “get it” enough to close the loop. I made a PR for the dev branch that is my giant drawing of ops, hardware and mod params with a little README describing how to build the PD external on macOS.

I’m thinking an interesting “prototype a connection graph” kind of canvas could be built in PD, including some kind of DSP module parameter mapping…

I have this programmable guitar pedal called Mod Duo and it’s similar to Aleph because it is standalone hardware with a computer DSP system inside. It differs with a novel programming interface for making pedalboards through a web browser on a second computer then saves them to internal storage.

2 Likes
#31

I’m trying to clarify some of the above, and some other things as well…

Is there currently any way to create/edit aleph scenes from a computer, either directly connected to the aleph or via some importing exporting?

How does the beekeep program fit into this? I looked in the github repo and read the readme, does it have a rudimentary GUI? It seemed to be eluded to above that the current status is unknown…

What exactly does the pd external do? I’m am still unclear here, is it running something while emulates the aleph hardware, and then you can try out patches, which you would then have to recreate on the aleph itself?

Lastly, what is the serial communication to a computer used for, is it primarily for debugging?

#32

there isn’t any user-friendly host-side or offline editor, but there are bits of functionality in place that would allow you to develop one.

“beekeep” includes some functions for converting between bees binary scene files and a JSON representation. (it is also tied up with a terrible GTK UI that doesn’t work well. it should be stripped back to just the JSON utility, if that hasn’t been done already)

What exactly does the pd external do? I’m am still unclear here, is it running something while emulates the aleph hardware, and then you can try out patches, which you would then have to recreate on the aleph itself?

pretty much yes. i don’t know so much about the pd wrapper. looks like it is set up to link the json modules but it hasn’t quite been done. exporting bees scene binaries should be straightforward even without that (all the bees sources that perform binary scene serialization are already linked.)

this is low hanging fruit if it is a feature that interests you and you want to get into writing a bit of C.

what is the serial communication to a computer used for, is it primarily for debugging?

  • debugging, yes.
  • also allows the aleph to act as a serial controller for a host computer
  • there are C modules allowing you to set aleph input nodes and DSP parmeters from a host program (lisp bindings are included)
  • you can hot-load DSP modules (blackfin executables); this is very useful for module development workflow

it would be pretty straightforward to create serial bindings for other bees patching operations.

1 Like