#21

Yes it is correct. How to open sidekick logs ?

#22

tried that git pull but still no midi control with the fates buttons/knobs on rpi 4 fates shield

#23

systemctl status eyesy-python.service
to see if the eyesy service is running

journalctl | grep sidekick for

@lcchy perhaps you could start a new Eyesy thread and we could take troubleshooting over there?

5 Likes
#24

Ok yes I think it is better to move to another thread indeed!

I just created it here : Critter&Guitari video synth Eyesy for Fates

It would be nice if an admin could move the posts, sorry for the mess

ps: @Zifor if you could run journalctl | grep sidekick like okyeron said and post it on the new thread, maybe I can find whats going on
edit: @LT6J also :wink:

1 Like
#25

FYI - some posts got merged into this thread from the fates thread, so they are slightly out of order above.

2 Likes
#26

192.168.1.233 ~ $ journalctl | grep sidekick
Nov 10 10:48:00 norns systemd[1]: Configuration file /etc/systemd/system/sidekick-init.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Nov 10 10:48:00 norns sidekick[100]: starting sidekick
Nov 10 10:48:02 norns sidekick[100]: WARN opengpio GPIO ‘/dev/input/by-path/platform-keys-event’ required 38 open attempts & 0 ioctl attempts
Nov 10 10:48:02 norns sidekick[100]: using framebuffer /dev/fb0
Nov 10 10:48:03 norns sidekick[100]: button 1 during startup : force menu
Nov 10 10:48:03 norns sidekick[100]: Sidekick activated,stop processes
Nov 10 20:18:53 norns systemd[1]: Starting sidekick-init

Nov 10 20:18:53 norns systemd[1]: sidekick-init.service: Succeeded.
Nov 10 20:18:53 norns systemd[1]: Started sidekick-init.
Nov 10 20:18:53 norns systemd[1]: Reached target sidekick.
Nov 10 20:20:57 norns sidekick[100]: Sidekick launch
Nov 10 20:20:57 norns sidekick[100]: launch : Eyesy
Nov 10 20:20:57 norns sidekick[100]: exec : cd “./patches/Eyesy”; ./run.sh &
Nov 10 20:20:57 norns sidekick[100]: exec : “./post-patch.sh”
Nov 10 20:20:57 norns sidekick[100]: starting Eyesy
Nov 10 20:20:57 norns sidekick[100]: opened alsa client 129 in:1 out:1
Nov 10 20:20:58 norns sidekick[100]: using framebuffer /dev/fb0
Nov 10 20:20:58 norns sidekick[100]: setting up abl_link~
Nov 10 20:20:58 norns sidekick[100]: Created new Link instance with tempo 134.000000.
Nov 10 20:20:58 norns sidekick[100]: udpsend: connecting to port 4000
Nov 10 20:20:58 norns sidekick[100]: Connection failed (Invalid argument)
Nov 10 20:20:59 norns sidekick[100]: error: udpsend send: Connection refused (111)
Nov 10 20:20:59 norns sidekick[100]: verbose(4): 
 you might be able to track this down from the Find menu.
Nov 10 20:20:59 norns sidekick[100]: udpsend: connecting to port 4000
Nov 10 20:21:00 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:01 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:02 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:03 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:04 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:05 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:06 norns sidekick[100]: error: udpsend: already connected
Nov 10 20:21:07 norns sidekick[100]: error: udpsend: already connected

this is what i got.

#27

Yes I am also definitely not an expert with Linux but I would be happy to make it work for others!

It seems that there could be some permissions problems from the systemd log you posted @xenus_dad, I’m going to look into this and move the systemd unit to /etc/systemd/system/ as okyeron suggested.
By the way @xenus_dad, when you say that the initial screen is frozen, do you mean that it’s literally not moving or that you can’t control it using the knobs ?

ps: the error: udpsend: already connected is normal, I also get it while it runs without issues. This is the controller pd patch that is maintaining the connection to the engine (it is from the original code)

#28

Literally frozen. It’s like it loads that pattern (darkish green, angular symmetrical reddish lines) and then it stops doing anything.

#29

Thank you for sharing this tool!

I got it working on my fates running on RPI 3B+ , however the audio-in doesn’t seem to work.
I tried cranking the audio-in gain up but the ‘Input Level’ meter stays still.
Is there something I could do to get it to work?

Thank you again :pray:

1 Like
#30

@amgnowhere hoow did you get it to work ?

#31

Hi,

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.

#32

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; ./deploy.sh

#33

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.

#34

@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 ?

#35

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

#36

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

[Service]
Type=simple
WorkingDirectory=/home/we/sidekick/patches/Eyesy/engines/python
ExecStart=nohup python main.py

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 run.sh and stop.sh).

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

2 Likes
#37

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/file1.py

#38

I’m also poking around with removing nohup, verbosing the service’s python -v main.py, 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 stop.sh:

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 stop.sh just hangs.

1 Like
#39

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

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: https://gist.github.com/timcosgrove/df06b587a45f6d824d1eae7c6c84d802