The relevant “catch~” object sits in mother.pd. Maybe this isn’t being reference properly?
ok, makefile deploy should not create /usbdrive, that should be done in the armbian build , since this will become a filesystem mount point, so needs an entry in fstab (?) … as will /sdcard too (for the internal partition)
#!/bin/bash - hmm, Id already changed a bunch of these, enough to get things running… which did you change? or perhaps I forgot to check in (I’ll double check… its possible ive got a few outstanding changes sitting on my organelle )
(my guess is on arch linux is /bin/sh was substituted for bash… since definitely the files contain bash constructs)
audio… did you switch the DTS using armbian config? im pretty sure last time I did a client build that was all I needed to do … and then mother host worked fine.
anyway, my next step is to make it so that mother host is installed as part of creating the image, so when I do that I’ll be able to test if the audio is working ok, if not, i’ll look into it.
Yeah on arch /bin/sh -> bash but on debian it is -> dash
I just changed them all with sed.
The issue with catch~ was that the organelles volume was turned down. A perfect example of me missing the bloody obvious!
The /usbdrive mount seems to work fine without an fstab entry but I agree having it created with the armenian build would be a better idea. How far did you get with the RO overlay thingy you mentioned before, or is the idea to have it all read only with a separate partition for /sdcard?
One useful thing about the armbian build system is you have all you need for cross-compiling as well.
You can mount the image file to get at the organelle filesystem:
sudo mount -o loop,offset=4194304 .../armbian/build/output/images/Armbian_5.41_Cubox-i_Debian_stretch_next_4.14.18.img /mnt/organelle
and then compile with:
.../armbian/build/cache/toolchains/gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc --sysroot=/mnt/organelle -I/mnt/organelle/usr/include/ -L/mnt/organelle/lib/ test.c
Also now we have Network Manager running I was thinking it would be a good idea to get rid of WIFI.txt as it seems to cause a fair amount of confusion.
So how about the idea of some code that interfaces with Network Manager and the organelle screen/knobs to list the wifi access points and allow the user to choose one and enter the password. Once the connection is made with Network Manager it will always connect at startup. We can add an Access Point option as well.
Shall I look at knocking this up?
this would be an awesome development. something I’ve been wanting to tackle but just haven’t had the time lately. the WiFi.txt is definitely clunky and not ideal. the current WiFi setup is a python script in /root/scripts/wifi_setup.py. you’ll probably want to start fresh, but you might want to use the og.py module which provides some UI functions for interfacing with screen and encoder and drawing a simple menu.
Ok, I will have a look at it.
I’m a C/C++ programmer so I will do it that way rather then using python. There is a lib wrapper around the dbus network manager interface that I can use: https://developer.gnome.org/libnm-glib/stable/
well yeah it is a cross compiling build system
actually, Im hoping we don’t have to mount the organelle filesystem…
you can extend the build process to ‘fix the image’ even before the final image is built.
from what ive seen, it not only mounts the filesystem but actually runs an arm emulation, such that you can run commands ‘on the image’ … this is how you can do things like set the root password.
(I checked this out for something else, so I need to go look for the details again)
but yeah, my general idea is to get the build process to download Organelle_UI (perhaps tagged build) , build it and install it… ideally the makefile will produce a debian package, that way future updates would be done properly via apt tools (albeit the user wont see this, but I’ll feel its nice and tidy )
Im trying to finish up something else at the moment (organelle related ) , once thats done im going to return to this.
yeah, netctl feels like the way forward… it’d also be cool to get the Access Point working.
(one thing… it will need to be optional to bring up the WiFi interface, given in a performance situation this is probably not wanted… though admittedly most are using wifi dongles, so perhaps not a real issue)
if you have changes you want, feel free to send me a pull request.
There is an issue with the WIFI and INFO screens on the build, this is to do with pyliblo not being installed.
I know nothing about python having steadfastly managed to have nothing to do with it for years but managed to get it working by installing crap loads of stuff. I’m guessing there is an easier way for someone that knows what they are doing but I had to install:
and then pip install:
yeah this is mostly part of the os 3 upgrade script , which I’ll migrate to Debian to be part of base install
Ah ok got you. When you get it migrated tell me and I will do a new build to test it out…
Hello folks. I hope you don’t mind me resurrecting this thread to mention something I hacked together today: a very basic custom Linux OS for Organelle built with Buildroot.
Again, interesting to very few people, but nice to know we can run anything we want on this cool open device
The Buildroot branch is here with a few notes in the README: https://gitlab.com/samthursfield/organelle-ports/-/tree/organelle-ports/. There’s nothing special going on - the
mx6cubox_defconfig works more or less as-is, just needs some different kernel arguments.
I also noticed that HDMI doesn’t work if the cable is connected when powering on the device. But it works if I connect the HDMI once device is powered on. I don’t know why.
edit: to clarify, it’s for the Organelle 1, that’s the only kind I have
Is this for the Organelle-1 or the M?
Edit: I read, hehe! Very cool! Will try it out on my OG
Nice, Have you added all the oled + input scripts + puredata?
I guess with a custom linux you could bring the latency of the organelle super low?. A colleague of mine also put together an Audio Os for raspi with a ridiculously low latency and other goodies for audio…
I echo @Servandob comment, about what status is this at?
as far as I could tell (by config, not installed it yet!) , it doesnt have puredata or mother installed or the various scipts.
also I should point out, this would very likely be incompatible with any packages that have been released for the Organelle-1, this is because they are based on a particular arch linux version, and install via apt.
thats not ‘bad’, as the nice thing about a fresh build (and why I did it with armbian, see above) is that many of this packages could be installed with newer versions.
however… note that buildroot system are NOT distributions, so you cannot ‘just’ install via apt/dpkg, you’ll have to build anything ‘extra’ (e.g. supercollider) yourself (or get it bundled into buildroot, and get a new release)
@Servandob - low latency, usually this is just things like ensuring the performance scheduler is used (already done on organelle) - this is the 90% win, other things like real time kernal and other tinkering of kernal parameters I found have marginal (if any) proveable benefits. (*)
of course, you can lower the latency on the Organelle-1 by lowing the audio buffer of pure data - but you’ll get performance issues.
(of course, the above all ignores hardware alterations that can give rPI better audio performance)
( * ) I did a ton of testing of this when playing with running Norns on a rPI… I found excluding the performance scheduler… the other recommended kernal parameters and real time kernal extensions made very little difference in real world scenarios (i.e running audio applications)
I’ll admit I was pretty surprised… but I guess, you could say that the kernel is pretty well optimised already for most use-cases.
the only real concesssion thats made is power management (incl heat), where they assume activity is ‘bursty’ … which is not true for music appllications, where constant throughput is the norm.
btw: above is not intended as critcism… or to invalidate buildroot.
in fact the opposite, I think having a buildroot is really cool.
it enables us to easily build images that are highly tailoured to our needs, removing things that WE do not require - this means potentially slightly lower cpu loads, less memory utilisation and quicker boot times.
the other advantage is as stated earlier in the thread (re armbian), the arch linux on the Organelle-1 is EOL, and it cannot easily be upgraded… this meant I was unable to install some software due to it being dependent on newer versions of other (already installer) libraries.
building a fresh image, be it armbian, build root… removes that issue!
BUT its the trade off of ‘general purpose’ vs specific focus.
if you start installing everything, adding networking/wifi … etc etc , you may be quickly back to where you started.
Here the link from the Os I mentioned before: GitHub - DatanoiseTV/AudioOSv2-buildroot
Hey, thanks for all the comments
As you noticed, it’s minimal and I don’t plan to try and re-create the stock Organelle 1 firmware, I will leave that in the capable hands of Critter and Guitari.
This was actually done on a whim, I had to test a few things on ARM and thought… this could be an excuse to dig deeper into the Organelle!
I am going to try and get the
mother program running. I have it built but so far it segfaults at
Connecting to serial... so something is missing somewhere. Beyond that, I will probably leave it. It’s a good base if you want to turn your Organelle into a completely different custom thing in an Organelle shaped box
As @thetechnobear points out, Buildroot is not a distro so while it’s good for ‘all in one’ appliance builds with your own custom software, it’s not a good ‘default’ OS as it requires some effort to build new software packages for the device. Armbian gives more flexibility there as you can pull binary packages straight from Debian.
the SOM connects to another MCU (stm32f4?) over a serial link, the MCU is talking to pots, endoder and lcd.
so you’d need something like mother, if you want to interface to the pots/encoder/lcd.
(unlike the Organelle-M where the CM3 is directly connected to pots/encoder/lcd)
I must admit its been a while, so Id have to look at the mother code to see why its not connecting… at a wild guess its something to do with uart/gpio setup.
( I dont remember doing anything specific for this on armbian !? then again, it was a couple of years ago, so perhaps I did )
btw: you do need to run mother as root… to ensure hardware access, but I guess, this is the norm on a buildroot system
totally agree, its fantastic for this!
… which I think is particularly enticing for those of us that perhaps added an Organelle-M , so the Organelle-1, could be used for a more ‘custom role’ … well thats my thinking at least !
I accidentally spent some more time on this, and started a new thread: Organelle 1 - custom OS using Buildroot
Changes since I last posted include…
- Fix the crash in
mother(it was this?!)
- Add some USB network drivers, and enough software for you to connect to Wifi and login via SSH.
- Add Python
- Add an