#42

@xenus_dad here is my working set up: https://gist.github.com/Lcchy/29687a6231175411c2dbbd223b5af207
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 main.py (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 "main.py", line 161, in <module>
    sound.recv()
  File "/home/we/sidekick/patches/Eyesy/engines/python/sound.py", line 34, in recv
    avg = audioop.getsample(data, 2, i * 3)
KeyboardInterrupt

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

2 Likes
#43

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.

#44

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

1 Like
#45

@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 = inp.read()
    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!

5 Likes
#47

not sure this is “right” or not, but I seem to have audio input working:

sound.py 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.setchannels(1)
    inp.setrate(44100)       # Original value of 11025 was giving error..
    inp.setformat(alsaaudio.PCM_FORMAT_S16_LE)
    inp.setperiodsize(1024)
    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 = inp.read()
    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 :
                pass
        l,data = inp.read()

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.

4 Likes
#48

Working!
https://www.instagram.com/p/CHejofLBWGA/

7 Likes
#49

Confirmed working :slight_smile:

4 Likes
#50

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?

4 Likes
#51

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

3 Likes
#52

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


2 Likes
#53

You are giving me big expectations. But is it tecnically possible to have an instance of eyesy tynning together with another piece of software? And it would need some smart interaction/switching as far as how to control both softwares.
This would make the fates a pretty bonkers performance machine.

2 Likes
#54

Yes i think that in that case it would preferable to use a midi controller to control Eyesy via a defined midi channel and let norns take over the hardware.

Can you confirm that the Eyesy update works on Fates? You never know :upside_down_face:

2 Likes
#55

I was wondering if it was possible to use the HDMI or composite out of the RPi for graphics alongside norns!
Has anyone tried this on a Shield or is it only running on Fates?

2 Likes
#56

MIDI Device tip:

If you want MIDI devices to automatically get routed to PD without having to muck around in aconnect, you can run the amidiauto service. (won’t work on norns shield without installing amidiauto first)

systemctl start amidiauto.service

FYI - you can see the MIDI device routings using: aconnect -l

1 Like
#57

Is it raspi3 only? Or would it compile also on a rpi4 based Fates?

#58

I’m testing on a pi4 (2GB). Should be fine on either I think.

#59

Thank you all for this thing. Amazing. Anyone got the web interface working ? It would add a lot of functionality .
Also does anyone have it working on internal screen ? No use just would be fun.

#60

Is there an easy way to get this running on a vanilla raspberry pi with an audio interface and a midi controller?

1 Like
#61

I also use it on a rpi4 and it worked on a friends rpi3

For me it does this when I boot without any hdmi cable plugged in, but maybe this is specific to the rpi4 as it handles the framebuffers differently than the rpi3

This is would be doable I think, you would need to:

  • mkdir -p ~/sidekick/patches
  • follow the installation instructions on the repo but before running ./deploy.sh, replace we with your username in Eyesy/systemd/eyesy-python.service
  • make alsa work with your sound card and engine/sound.py, this could work by default, but I’m not sure
  • if needed do the midi configuration that @okyeron described above
1 Like
#62

Best I can tell
 the default norns shield image has the HDMI port disabled. So at the moment - no, it won’t work on norns shield.

Tested just now on pi3b+ and no, it will not display on the internal screen at the moment.

It does work on the internal screen with a pi4, although the menu text is gigantic and hard/impossible to navigate.

2 Likes