Ah, I’ll have a look for the driver patch.
Jackd 2 is available but doesn’t seem to like the SGTL5000 or it might be a dbus issue (jackd 2 also wants X). I left a full desktop build going earlier, I was going to try that to see if it fixed the problem to give me some pointers to where the issue might be. I will look at it tomorrow.
You seem to be able to run any of these X processes with a magic command as long as X is installed, I’ll post the details tomorrow…
Virtual x framebuffer ? Not very efficient on a low powered device with limited memory.
Could well be, I’ll do some tests, I’m guessing all it uses is the dbus. We can always have multiple versions, it does seem most of the apt stuff I have been looking at seems to be relying on X in some way…
Just booted the desktop version up, Jackd2 and SC worked first time, so the issue before must have been me trying to get a minimum set of X stuff installed and messing something up.
I will do some tests tomorrow with Jackd2 and SC to see what memory/cpu hit we would get from using these versions compared to the 3.1 organelle SC that you built…
I’m guessing the path is the “SMALL_POP” patch, I will get a new kernel built with it in.
Concerning running sclang without X all it seems we need is:
export DISPLAY=:0
sclang ... Been messing around a bit more with all this, I seem to have a running organelle now on the new kernel.
Interestingly I seem to have more memory available with this build:
PD:
orignal
[root@organelle ~]# free
total used free shared buff/cache available
Mem: 2063544 167900 1800940 25092 94704 1843836
Swap: 2097148 0 2097148
[root@organelle ~]#
new
root@organelle:~# free
total used free shared buff/cache available
Mem: 2064580 86444 1830640 6140 147496 1951192
Swap: 131068 0 131068SCLang:
old
[root@organelle ~]# free
total used free shared buff/cache available
Mem: 2063544 233816 1718156 33332 111572 1757284
Swap: 2097148 0 2097148
scsynth 24.3
jack 5.3
new
root@organelle:/usr/local/bin# free
total used free shared buff/cache available
Mem: 2064580 137260 1652780 23932 274540 1879616
Swap: 131068 0 131068These figures are with the X Desktop up and running on the new kernel but not on the old kernel.
The cpu figures I see with PD are basically exactly the same between the builds but sclang/jackd seem to be running 2-4 times faster on the old kernel compared to the new. I need to look into this some more to try to work out what is going on, I’m guessing it is jack causing the problem, maybe by using the plugin version. Need to look into it a bit more…
wheres you swap file residing? if think on arch linux is probably in ram on /tmpfs
(remember the rootfs/sdcard is RO on the arch linux build)
Ive not had any time to look at this over last week…
my plan, hopefully tomorrow, is to upload (to a repo) all the setup data and instruments for doing the build.
the idea being we can then both (and C&G if they want) use that as a baseline, and you can submit pull requests (or I can make you a contributor) - this way we will know we are both looking at the same thing…
(currently, I suspect we have similar, but not identical build)
Im pretty far along in terms of additional packages being installed etc, and things setup as required by mother host etc… hence i think my baseline is useful.
a small note my priority initially is to get a replacement to what all Organelle users get ‘out of the box’.
so that means mother host/pd/patches/minimal. anyway else I think is ‘phase two’ 
this means initially im not going to focus on jackd/sc
of course, you are free to focus on what you like… but its probably useful if we know what we are both trying to achieve.
ok, Ive got the starts of the user config repo here…
feel free to clone, and submit pull request for changes.
I need to perhaps rethink the kernel config settings, and I do need to test the build instructions 
Nice one Mark, thanks for that. I will clone and get it built tomorrow…
cool, its an early stab… so might be some missing things, and I need to clear up the documentation, but it would be great if we can get a common ‘build’ procedure working … that potentially anyone can pick up and try/customise.
Hi,
did a build but the kernel is not correct so I guess the following is not quite correct:
included is a kernel config file, i think this has to be moved manually to ./cache/sources/linux-mainline/linux-4.14.y/.configI have had difficulties before with getting the kernel config correctly loaded with it automated and was just loading my config file in the config and then saving it as “.config”, nothing else I tried seemed to work! I will do that now and do another build…
Ok I have it up and running sort of!
I cloned your debian Organelle_UI and built.
I had to change the makefile deploy to create /usbdrive and also alter the scripts from #!/bin/sh
to #!/bin/bash
Strangely though I am getting no audio from PD when using the default “throw~”, if I use “dac~” everything works fine. Any ideas?
hmm, we need to figure this out as its obviously important we use a common kernel config…
i’ll have a look later … the above was just a first guess 
I did build with your kernel.config by directly loading it into the configure app, so we are running on the same kernel. How to automate this though has confused me with armbian.
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/organelleand 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.cAlso 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.