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

I was not successful in building beekeep on parabola/arch linux. Here’s the std output/std error running make:

beekeep_make-output.txt (8.2 KB)

#34

the error says you are linking files built for the wrong architecture, namely avr32. ‘make clean’ first or delete the objects manually.

there may be other issues, sources missing or moved, i don’t know. nobody has maintained this particular tool in a long time. you might just have to work through the issues or simply adapt the project sources to your own needs.