Critter&Guitari video synth Eyesy for Fates (updated)


The thing that made it for me was installing the packages (pip and psutil) @okyeron suggested above.

Following @lcchy suggestion, I also run this line.

cd ~/sidekick/patches/Eyesy; git pull

Also make sure that the path is correct. I got exited and miss-typed something on my first try hehe.

I just pushed a commit that may be a solution to the permissions bug :slight_smile:

You can try it out with cd ~/sidekick/patches/Eyesy; git pull; ./

Oook my bad. I expected it to work on internal screen but for me it works only on hdmi. It did run on hdmi and seemed running fine, then never managed to run it again. It hangs just after showing the first vector. Also you cannot exit at all after that.
A whole lot of things to be ironed oute but
This is amazing and thank tou.

@amgnowhere I’ve never seen the audio meter of the info display move either… but the input is definitly working (for me), do you see if the video reacts to the audio ?

Not really.
Trigger Source is selected to Audio and Input Gain to 301%
Should I check something else?

@lcchy I’m still poking at this, but one thing I am noticing is potential issues with eyesy-python.service. In its definition:

ExecStart=nohup python

for me, the ExecStart command is firing on service stop rather than on start. This is true whether I allow Sidekick to start/stop the service, or I start & stop it manually (via and

I’m still poking around, but posting that here in case that’s helpful.


doing some reading right now on systemd stuff… (python systemd tutorial here)

Is the nohup necessary in the exec start?

Also (not sure if this matters here) - I’m seeing examples that use full paths in the ExecStart like
ExecStart = /usr/bin/python /tmp/app1/folder1/

I’m also poking around with removing nohup, verbosing the service’s python -v, and turning on systemd debugging.

That said, I am new to systemd, python, all of this, so basically I’m a smart person with no experience with these specific domains who has turned on logging :slight_smile: Still, possibly finding some things.

One small thing that should definitely be done is this small modification to

pidof pd | xargs -r kill

The -r flag tells xargs to not run if no arguments are passed. Without this, if pidof pd returns nothing for whatever reason, the kill command fails and just hangs.

1 Like

I am also still trying to find out what is happening…
I have reflashed an old sd card and could reproduce the bug you’re describing (freezing after having it working once) in the vanilla setup!
This is pretty weird, but I am certainly no expert so please have no restrain in questioning my code :wink:

@xenus_dad, @okyeron I will remove the nohup and add the kill -r flag to the next commit, it didn’t resolve the bug for me but it’s definitely better.

I am not sure, if you get no errors via journalctl -e you could try to test it directly in the code where it is defined, if you feel like it, to see if python reads any input. Also make sure that there is no other process using alsa at the same time

edit: @xenus_dad I also get the weird behaviour where the engine seems to start when I stop it

1 Like

Experiment with removing the nohup before you commit that. It may in fact be necessary in the current configuration.

FWIW, I am able to occasionally get Eyesy to run on first boot, but it’s inconsistent. When it does load, audio input does not work, for me.

@lcchy, would it be helpful for us to compare hardware, OS, and installed packages? For me:

@xenus_dad here is my working set up:
I seem to have a higher debian version, this could be because I run sudo apt upgrade from time to time on my Fates. BUT, before running it is crucial to hold certain packages with apt in order to not upgrade them. I did it using (on one line):
sudo apt-mark hold raspberrypi-kernel supercollider-common supercollider-dev supercollider-language supercollider-server supercollider-supernova
The versions of these packages are relevant to Norns and break it if you upgrade them. I wouldn’t recommend this as it’s pretty bodgy (worked so far, but you never know).

I feel like we are getting closer to the problem, this could be due to a difference in packages:

When I run sudo python (in Eyesy/engines/python), I get the usual ugly frozen green. Then, when I kill it with ctrl-c, I get the python traceback of where the execution was at that point. Every single time it is there:

^CTraceback (most recent call last):
  File "", line 161, in <module>
  File "/home/we/sidekick/patches/Eyesy/engines/python/", line 34, in recv
    avg = audioop.getsample(data, 2, i * 3)

Maybe the code hangs at that audio sample collection ? Could that potentially explain the missing audio input when it works ?
I will look into the audio relevant packages


I’m trying the upgrade right now since I have a fates to spare for a few days.
Any idea of what it may be causing the udp port errors ?
Also you mentioned it worked in internal screen for you, does this happen with ur fresh install also ? Cause I never managed to make it display to the internal screen.

Let me know when this gets resolved , look forward to it :slight_smile:

1 Like

@lcchy, confirming that commenting out references to audioop allows Eyesy to run as normal. I just did this:

def recv() :
    global inp, etc, trig_this_time, trig_last_time, sin
    # get audio
    l,data =
    peak = 0
    while l:
        for i in range(0,100) :
            try :
                avg = 0
                #avg = audioop.getsample(data, 2, i * 3)
                #avg += audioop.getsample(data, 2, (i * 3) + 1)
                #avg += audioop.getsample(data, 2, (i * 3) + 2)
                #avg = avg / 3
                # scale it
                #avg = int(avg * etc.audio_scale)
                if (avg > 20000) :
                    trig_this_time = time.time()

It also allows ‘normal’ use of Sidekick for me, i.e. using the 3 buttons to invoke Sidekick and switch to say Norns (though, Norns tries to use the HDMI cable which, again, cute and hilarious!) But then I can switch back to Eyesy, and Eyesy loads as normal.

So, I would confirm you’re probably right, there is an issue somewhere with audioop

Update: set my 16n to send appropriate cc and messed around. Responding to audio is obviously the goal, but this is still fun :slight_smile: @lcchy thanks for your work on this!


not sure this is “right” or not, but I seem to have audio input working: modifications
def init (etc_object) :
    global card, inp, etc, trig_this_time, trig_last_time, sin
    etc = etc_object
    #setup alsa for sound in
    inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE,alsaaudio.PCM_NONBLOCK)
    inp.setrate(44100)       # Original value of 11025 was giving error..
    trig_last_time = time.time()
    trig_this_time = time.time()
    for i in range(0,100) :
        sin[i] = int(math.sin(2 * 3.1459 * i / 100) * 32700)

def recv() :
    global inp, etc, trig_this_time, trig_last_time, sin
    # get audio
    l,data =
    peak = 0
    if l > 0:
        #print l
        for i in range(0,100) :
            try :
                avg = audioop.getsample(data, 2, i * 3)
                avg += audioop.getsample(data, 2, (i * 3) + 1)
                avg += audioop.getsample(data, 2, (i * 3) + 2)
                avg = avg / 3
                # scale it
                avg = int(avg * etc.audio_scale)
                #print avg
                if (avg > 20000) :
                    trig_this_time = time.time()
                    if (trig_this_time - trig_last_time) > .05:
                        if etc.audio_trig_enable: etc.audio_trig = True
                        trig_last_time = trig_this_time
                if avg > peak :
                    etc.audio_peak = avg
                    peak = avg
                # if the trigger button is held
                if (etc.trig_button) :
                    etc.audio_in[i] = sin[i] 
                else :
                    etc.audio_in[i] = avg

            except :
        l,data =

Bonus commands - maybe to get setup on a switch somewhere:

amixer cset numid=11 on will monitor the audio inputs to the Fates outputs
amixer cset numid=11 off will turn it off.




Confirmed working :slight_smile:


I love this!
Now, the million dollar question:

Is it possible to get it to run alongside norns(or other sidekick stuffs) on a single fates?


Aah yes, this is so nice!! Thanks a lot @okyeron and @xenus_dad for the decisive help :slight_smile:
I am going to push all the modifications to the repo and update the opening post

Aah this would be pretty nice indeed, and maybe not that complicated as norns already uses Jack as a backend, we only would have to switch Eyesy to use it too and connect the dots. For Orac this would be possible in theory but personally I don’t want to share things that may break other projects :wink:

Update (Bugfix):

If you want to try out the updated version please see the first post of this thread where I put up the instructions


Imagine if there was a video engine running in parallel for all these wonderful norns patches! I just hope there are no technical blockers, and enough CPU/RAM…