#21

super cool!

there’s been talk of this before, but seeing as how matron does all of the framebuffer/gpio/etc also in c, perhaps it’s a worthy endeavor to extract this functionality into a library?

1 Like
#22

it may be worth mentioning here… I re-worked the ssd1322 display driver to accept a 180 degree rotation command from an overlay. (my pi-norns has the display hardware flipped now)

Perhaps I should push that to the monome/linux source tree?

1 Like
#23

Maybe? I don’t really know. At the moment, I am very much enjoying my simple and stupid standalone programs. A matron library would allow people to give people a more robust starting point for larger more complicated (and perhaps more interesting) programs, but this to me steals some of the fun that comes from hacking on something like the norns.

I had a thought about building some really lightweight wrappers around some of the raw GPIO/framebuffer stuff. One of those things you could just drop into a codebase like those STB single-header libraries.

#24

my 2c: most components of matron are pretty tightly coupled around architectural assumptions like the event queue. abstracting away those couplings would be a pain (e.g. even the gpio module requires events.h) ; what’s left is light wrappers around libraries and other basically trivial stuff, but it does include e.g. some hardcoded paths to filesystem locations used by ioctl and so on.

IOW i agree that both approaches are useful. again, @ngwese already made a libmatron branch, probably worth upstreaming in case people are interested in replacing core “business logic” of matron without starting from scratch.

and lower-level bits, though simple, are probably worth putting together so all the hardcoded magic words are available if you want to make something totally different - like blasting the framebuffer yourself instead of using cairo, using a single-thread event model, doing audio stuff in the same process, i dunno.

at some level it does seem like duplication of effort and the really awsome thing to do would be refactoring matron itself to use a library for the really low-level things.

1 Like
#25

It is very much my intension to pull that branch in line with the current version of matron, do a bit of cleanup and open a PR for review. Doing all this is 2-3 deep on my TODO list at the moment (mostly behind finishing the maiden improvements currently in flight).

#26

Hey @PaulBatchelor, do I need a norns to try the button.c example, or will it work with just a breadboard, a Pi + a push button? If so, how would I set it up?

#27

You probably will need a norns or a norns configured device. I say this because the example is configured to read button events (button number + state) from “/dev/input/by-path/platform-keys-event”, rather than the GPIO pins. My guess is that there is some process that is polling the raw GPIO values, and converting them to linux input events. @zebra I think would know.

#28

we are the gpio-key dtoverlay which is a standard in the raspberry pi linux bundle

we also use the encoders overlay, though slightly modified if I recall.

(i can point at some resources in the norns-image repo later when I am not on my phone)

1 Like
#29

Thanks, I thought it would be something like that.

#30

Got some time this weekend to build something a little more functional. This little demo program uses the knobs to control the frequency and amplitude of a sine tone. Slider position is also being visualized as well. There’s a waveform display (oscilloscope?) to visualize the audio, just to try and push the limits of the screen.

Mind your ears. SHRILL sine waves. Sorry.

Up to this point, I was able to get away with using a generic arm cross compiler to build static binaries. With this program, I needed to link with the JACK libraries, and was only able to do it if I built the program on the device itself. Hoping to figure out how to go back to using a cross compiler, because compiling on the device is a bit of a drag. Has anyone managed to use buildroot to build software for the norns?

6 Likes
#31

There has been some experimentation with using buildroot to generate full images but I’m not sure anyone has explored trying to use it to build packages in a one off fashion and then transfer them over to the device for testing. Just looking at the structure of the buildroot output directory leads me to believe this might be possible to do something sort of hacky like:

  • define a buildroot package for a given project
  • go through a full buildroot build
  • jump into the <output_dir>/target-<project>/... directory and do rebuilds there (adding project specific build targets which create one off tarballs one could transfer to the device)

I’m certainly curious if it would be possible to use buildroot for more ad hoc development like this so I’ll likely experiment further after I have a stable image built.

1 Like
#32

Been spending a few days on this, and with the help of @simonvanderveldt, @tehn, and others, I managed to get some of this working!

As of now, I’m able to use a toolchain generated by build root to cross-compile AND link programs, and then copy the programs to the norns. The caveat here is that you probably will have to use the norns image built by buildroot. Main reason for this is glibc versioning issues. The shipped norns OS uses glibc 2.24, while buildroot uses glibc 2.28. I learned this the hard way.

It was a lot of trial and error for me, but the gist of it is to use @simonvanderveldt’s norns-image repo and buildroot repo to build a setup locally on your (presumably linux) computer. The output generated cross-compilation tools for me in output/host/bin, and all the libraries in output/host/arm-buildroot-linux-gnueabihf/sysroot.

At this point, you’ll want to setup your PATH to look for binaries in output/host/bin, then it’s just a matter of telling your C project compiler to use that compiler. This is how I explicitly set it in the Makefile found in low-level norns examples repo: https://github.com/PaulBatchelor/norns-lowlevel/blob/2be02f38c8a5c67ba30691f3a5bfe13881a337b8/Makefile#L7

I didn’t need to set any additional LDFLAGS or CFLAGS, it just seemed to know where to find them.

As an added bonus, I also managed to get use the buildroot environment to drivers for the griffin powermate for the norns, without needing to recompile + reflash the norns device. Luckily, I had figured how to do this before. I followed similar set of steps, only using buildroot instead of the linux kernel sources.

2 Likes
#33

Yes this is most definitely true and something we will collectively need to make some decisions about if buildroot images become more of a standard thing in the future. We can either try to maintain parity in a buildroot environment which tracks the versions used in whatever raspbian base image we have or allow them to drift with the understanding that changes (at least to the norns stack) need to be tested on more than one image.

For low(er) level stuff like this the possibility of using custom base OS images is I think a very powerful and welcome option.

Ideally where I’d hope to see the buildroot stuff evolve to is a place where we can maintain more than one base OS image on the device and switch between them during “firmware” upgrades or to switch between a standard norns image and some alternative. Whether or not the value of such a change warrants the effort is debatable but it is an interesting option I’d like to explore.

Slightly off topic but yes! This totally reminded me that I had kernel mods to add that driver which I’ve not pushed up for inclusion into a norns release yet (shame on me as it would have saved you some time)

image
image.jpg600×800 158 KB

…I had started a little helper library in the spirit of other norns APIs. It is super trivial but makes interacting with the powermate similar other devices:

5 Likes
#34

Getting back into some of my small low level norns experiments. Today, I implemented some simple bitmap text rendering on the framebuffer.

oneart_norns_small
oneart_norns_small.jpg1040×780 231 KB

Code can be found here.

I am using one of the 8x8 fonts found here:
http://uzebox.org/wiki/Font_Bitmaps#8x8

There are lots of interesting 8x8 font sheets that can also be found at the this C64 font resources page, but they may still be subject to copyright.

For the font I chose, I had to tweak it a bit so the glyph order matched up with the ASCII order.

I converted it to a good ol’ fashioned XBM file via imagemagick. Since an XBM is just C code, it can easly be baked into the program.

Since the tile sheet used lines up with ASCII, printing a string is a matter of iterating through each character, converting each character to a position on the tile map, and then writing the bit values of the tile to the framebuffer using some bitwise ANDing.

6 Likes
#35

Those bitmap font pages are a nice find. In a previous life I designed some fonts for embedded devices, but I’m still always impressed by the range of styles that were squeezed out of 64 pixels or less.

2 Likes
#36

Nice job on the Powermate support! If you could PR that driver support sometime I would love to use it—I have a Powermate sitting on the lab table right now ready to start down that same path, so I’m glad I saw this.

1 Like
#37

Some more updates in my low-level norns experiments. I have managed to get an initial port of my composition environment running on the Norns. This includes writing a little menu interface that enables me to do things like power the thing on and off and select things I call “pages”, which are little grid/arc programs I’ve written to control sound.

Here’s a crudely shot video demo:

It showcases a little toy sequencer I wrote for the grid, and a slider interface for the grid + arc, and using the page selector to flip between them.

The menu + graphics are all based on the small low-level examples I wrote prior. The DSP engine is my own, currently run as a JACK client.

10 Likes
Index of norns-related resources
#38

This is just amazing. You are obviously not just an incredibly clever programmer, but incredibly good at demo videos too

2 Likes
#39

Thank you kindly :slight_smile:

I’m sharing this stuff mainly in the hopes that this inspires others to try stuff like this out. In particular, those who are musically inclined but may be hesitant about jumping in because they don’t feel “smart” enough or don’t have the right degree. This is all more attainable than you think! Seriously. To do this stuff, all you really need to be is patient, stubborn, and weird. As I’ve mentioned before in other threads, there’s great power in rolling your own music software. It is something I will always recommend to anyone who will listen. It takes a bit more time, but there is great payoff at the end. Inevitably (and usually quite quickly), you’ll end doing something that no other piece of software has done before, and it will be super awesome. And it will elevate your music/art.

13 Likes
#40

What a great message. Screenshotted for inspiration!

1 Like