EDP Clone - A Raspberry Pi Project

[trafficjam]

Congrats, that looks awesome.
I've learned a couple things while trying to mimic the neopixel feedback.
RPI USB audio and neopixel controlled over pwm pin do not work together, at least for me so far. You can do one or the other but not both at the same time. I have 3-4 workarounds to try but just haven't gotten to doing it.
I was so close getting it working on a seperate pi zero talking over osc. I spent a couple days at least trying to do some updates to the pi to install some dependencies.
The updates kept failing, in conclusion I believe it was due to a corrupt sd card.
I'm not giving up on it I just need to dedicate more time to trying.
Thanks for your help Colin pointing me in the right directions.
Now its almost finished, hopefully you can take some time to play and enjoy it when its done.

[Snake Eyez]

Looks like it's coming along great! Have you seen Patchbox OS from Blokas? It's a custom distro for RPi audio projects;

https://blokas.io/patchbox-os

Also, a cv input for a clock signal for loop tempo input would be great to sync with eurorack gear or clock pedals such as EHX Clockworks.

I've got the Audio Injector Octo as well, but haven't tried it as yet so looking forward to test drive with your efforts.

Cheers

[alignwaivers]

I've had an issue with tracking loop position (on > 3 loops) : are you autoregistering the loop positions and lengths or sending the '/get' osc messages to update. I was using 15 ms autoregistered updates for position, etc.

[alignwaivers]

So I'm curious how many loops total are you running and how are you getting position? I'm running into a bottle neck with autoregistering loop_pos for more than 3 loops and having them all play simultaneously. Lookin forward to hearing an update from ya, best of luck!

[alignwaivers]

Hey did you migrate your code? getting a 404 now for the link that was working before on your github. was just going to look to see if you were autoregistering osc messages such as position to get the leds to align with the current postion (divided by length, assumably). Let me know, ran into a bottleneck issue and was curious if this came up for you. Thanks

[jesse]

alignwaivers, just for reference, the GUI app itself registers 100ms auto-updates, so see what happens if you try that instead of 15ms.

[colinbrogan]

Alignwaivers:

https://github.com/colinbrogan/broganheimer_edp4/

Make sure you are logged into to your username on Github, because it is private. It is still showing you as a collaborator, so you should be able to access it as long as you are logged in.

In test_buttons.py, see this line:

client.send( OSCMessage("/sl/0/register_auto_update", ["loop_pos", 5, "sooperlooperpi:5432", "/loop_pos" ] ) )

Then in osc_server.py, you can see the loopPos function which recieves this auto-update. I have yet to expand the code to do more than one loop. I also have noticed high CPU consumption with all these auto_update registrations, and all the looping I am doing to write the LED wheels. If I can just finish the hardware and get the bottom-lid bolted on, I will get back to the code. Will probably start from scratch to optimise CPU performance, while achieving everything I want to do. Just haven't gotten the chance to sit down and think it through.

[colinbrogan]

It's been a long time, but I am back to working on this project again.

If Jesse is around somewhere, I have a question for him which is stumping me.

I noticed when sending "eighth_per_cycle" numbers via OSC to sooperlooper, such as "5" or "4", that Sooperlooper will sometimes double these numbers. First, in my register auto_update callbacks, sooperlooper will report to me that the eighth_per_cycle has been changed to "5", for instance, when I plugged 5 in. However, after recording a loop, and hitting play, suddenly sooperlooper will register a change to "eighth_per_cycle" to "10", which I did not trigger.

Do you know what causes this behavior, and if it could be switched off? I've dug through all the documentation I could, and saw no explanation of this behavior, or a way to control it. I'd like for sooperlooper to stick to the exact eighth_per_cycle I plugged into it at all times.

[solaris76]

Hi Colin,

just want to say thanks for the inspiration, and Jesse for the software.

I'm about to embark on a very similar project. Good to know it's all do able.

Going to kick off with an Audio Injector Octo card running Patchbox OS on the Pi. I've created a fair few midi controllers in the past, but also hoping to incorporate a ILI9341 LCD display into this project. That said, I love the use of the neo pixels, which wasn't something i'd thought of before.

Currently struggling a bit with the limited Python OSC libraries though (Patchbox is Python2.7). Which one are you using?
Been messing with oscpy at https://pypi.org/project/oscpy/, but struggling to check whether the sooperlooper OSC service is receving anything? Does the engine version of Sopperlooper push anything out into the terminal when it recieves a request?

If not, any advice on a OSC monitor or similar for the Pi? Better still, a code snippet of your python code sending OSC to sooperlooper would be amazing

Cheers, Chris.

[jesse]

I noticed when sending "eighth_per_cycle" numbers via OSC to sooperlooper, such as "5" or "4", that Sooperlooper will sometimes double these numbers. First, in my register auto_update callbacks, sooperlooper will report to me that the eighth_per_cycle has been changed to "5", for instance, when I plugged 5 in. However, after recording a loop, and hitting play, suddenly sooperlooper will register a change to "eighth_per_cycle" to "10", which I did not trigger.

Do you know what causes this behavior, and if it could be switched off? I've dug through all the documentation I could, and saw no explanation of this behavior, or a way to control it. I'd like for sooperlooper to stick to the exact eighth_per_cycle I plugged into it at all times.

Yes, there is an option called Smart Eighths (which defaults to on) which will allow the engine to automatically adjust the 8ths per cycle if the tempo is changed to < 60 (when it will double the 8ths) or > 240 bpm (when it will halve them). To be honest the reason for the feature's existence has been lost to time. But just turn off the smart_eighths global option, and it will not do that.

[colinbrogan]

Jesse,
Thanks! Would I just do an OSC message as follows?:
/set smart_eighths 0

Or is this something when I do in the command line when I fire up sooperlooper.

Honestly, after thinking about it and messing around for a while, this may not be a bad feature, atleast, if one stick to the idea of quantizing to the eighth not. I am actually trying to hack it to quantize to quarter notes, which is my preference, and switching this off will help with that. However, my guitarist prefers quantizing to eighth notes, and probably will want the halving / doubling situation you've got going on.

[jesse]

That's the correct /set command, yes. Sorry it wasn't in the docs!

In the GUI it is called "auto 8th", just for reference if you ever use it for anything.