TAW is a cool outfit, but AFAIK they don’t do walk-in business. its a local stocking distributor for a very specific range of components (primarily capacitors.) there are a lot of these kinds of distributors and b2b shops in the valley.

yeah, it’s enjoyable to poke around. i’m sure there are other surplus spots. but it’s not a particularly efficient way to get going on a specific project… :slight_smile:

Ah, ok, good to know. Considering All Electronics is only doing online purchases at the moment I might be SOL for now.

To tie this back into the Fates discussion, after my build I was getting the “SUPERCOLLIDER FAIL” error and none of the scripts would load despite everything else seemingly working fine. After troubleshooting all of the potential software issues without coming across a fix, I went back and retouched all of the soldering, which also didn’t help. After looking over the board a few times with a loupe I finally noticed one of the voltage regulator legs was a little bent and hovering ever so slightly so it was not making a connection. While attempting to bend the leg back into place it just snapped off… so that’s where I’m at.

So yeah - the vreg not having good contact would certainly cause the “SUPERCOLLIDER FAIL” error since that vreg is powering the DAC.

Thus always good to check voltages and confirm you’re getting 3.3v up there.

@etc zap me a dm. :slight_smile:

I’m pretty sure economy shipping won’t pop up unless you’re logged into your Mouser account.

hello! :vulcan_salute:

anyone have any tips for software fixes for jumpy fates encoders? some arcologies users are experiencing what we think is an encoder issue.

It should be possible, I haven’t seen the source for button and encoder handling on norns but it should be fairly easy to add a gpio delay or modify the value if already present.

try playing with encoder acceleration/sensitivity values? https://monome.org/norns/classes/encoders.html

It’s possible there’s a mismatch in the Fates fork of the norns source code - Cheat Codes exposed this recently. I’ve been waiting on a new official norns update to get those small fixes distributed.

It might be good to have that user DM me and I can walk them thru an intermediate update.

thanks for the support @okyeron :slight_smile:

@Gerald_Stevens @thedaniel :point_up: i still think there is an arcologies bug in here somewhere, but it could be a “both/and” situation.

Dunno if this helps, but… I’ve run into weird (software) encoder stuff in the past but I’m not remembering specific details about it now months and months later. If I recall though - it might’ve been something with the main norns menu.lua conflicting with something happening in the active script.

thanks for the jumpy encoder capacitor fix. works great. i cant believe i finally got my encoder 2 working a little better.

*EDIT: ok this isn’t perfect, as i thought. spoke a little too soon. I used .68uF Ceramic 50v Capacitors on K2, which is the only one i had a problem with. It has been extremely jumpy since I first built it. If im scrolling the script menu, it will go from the next one down to 15 down in one turn, then have a very hard time scrolling back up.

Once I added the capacitors, it scrolls as it should. not quite as fast but it doesnt skip any values. Sometimes though, it seems to kind of get stuck or slightly freeze, In one particular script, Euclidigons, it hardly moves. This seems to be unique to this script. But as far as i can tell, the script handles button presses and other values in a unique way to allow for increased functions.

I don’t know much, if anything about electronics. Would a different value help? i was going to use .1uF but i found out i only had one left and got kind of impatient. I have more coming, but I cant remember if i ordered enough extra to build my ciat circuits and have one left over to put two on the Fates. I have some other ones like .33, .47, 1uf. I guess I just need to know which value would work best, if anyone could help me out there.

thanks

*EDIT: Wanted to state for the record that .1uF did work perfectly. might have something to do with the recent update too, but it has never worked this smoothly. 100% working as it should now.

I’d try more like 100nF because the 680nF seems a bit a high. I feel like most people were using 10-100nF. Based on the symptoms you described I’d say that there’s too much capacitance and it’s causing a longer amount of time to settle. Cleaner input to the Pi but not as responsive. Also, what’s up with this jumpy encoder thing? Initially my Fates worked great but the most recent update has had it doing this and I don’t think much has changed hardware wise since then. Suppose I’ll need to do this fix myself.

1 Like

It could be due to a fork sync mismatch on the last update. (Branch names changed in the primary norns source and a few lua files are out of sync)

I thought it only affected things using controlspec, but there’s been a few reports of other glitches.

I’ll post instructions here on manually pulling the more recent sources. (When I am not on my phone)

1 Like

Yeah, totally not complaining there just more like baffled. Pulled fates out over the weekend and I noticed it, left me scratching the noodle a bit.

To add credence to the potential system filing name difference, I had altered that file a while ago so as to run through the Cheat Codes beta. As a result, I haven’t noticed the jumpy encoder issue. Obviously my tale is anecdotal, but it might be worth checking out. I might try and find the link to the post so that someone with jumpy encoders can give it a shot and see if it fixes anything for them.

Here’s the post that @dan_derks sent me in the Cheat Codes beta thread to get my encoders in line with the current norns/shield build. This might answer some encoder issues for folks.

1 Like

Hello!

I built my fates about 3 months ago. I was very interested, but very unexperienced with raspberry pi audio projects and just kind of jumped at this project when the circuit boards became available without really knowing what I wanted or needed out of a raspberry-pi based device. I would like to eventually make a pi-top with gpio based audio and midi ports mostly to run pure data and atari st emulation, but just bought another pi and want to hold off for a bit possibly update the functionality of the norns(hardware midi) test if this next project is something I fully want to invest in.
So I just have a couple of questions if anyone would mind answering them please.

Would the fates support a hardware modification for midi in and out using the gpio pins while having the fates pi-hat installed? like a hardware modification that connects to the pins on the fates dac that would go to 3.5mm jacks. Would the norns software even support hardware midi without modifying the code? I would rather not have to buy another pi-hat interface that includes midi) If not, no big deal see next question.

Could I flash something like Patchbox OS to another micro sd and use it to edit pure data patches with a hdmi monitor and mouse/keyboard from the fates dac hardware(Can this even be done on the fates currently with sidekick or norns mother)? Would patchbox OS support the fates pi-hat and be able to utilize the audio interface?

Thanks!

Yes - you can actually use the UART header on the bottom to get the RX/TX connections. I’ve not actually tried this, but it should work.

No. Not without some changes in the code. There are some recent developments here, but I would not expect that to be fully integrated for awhile if at all (will need to wait and see)

FWIW - a < $10 USB to DIN MIDI interface is a super easy and cheap solution here that is supported by norns.

Yes. Patchbox should work. I tested it before, but it’s been a year+ and I don’t remember details. The main thing is that the OLED display won’t work on the patchbox image. You will just need to do some audio device configuration (which is likely in config files rather than directly in patchbox helper apps)

You can use PD on Fates right now with sidekick and norns-mother. Editing is a question - I’ve only done that over VNC but not tried editing PD patches directly with keyboard/mouse/HDMI monitor - but I think that’s doable.

Okay I’ll give it a try running from norns to see what happens and report back.
Yeah that would be the ideal solution.

The atari st and amiga emulators have very good midi support through gpio, but less good with usb.
I use a usb interface with the norns now and am happy with it and will keep the norns software installed on the pi fates after I get this project ironed out.
I just want to test if I can get pure data and the atari and amiga emulator to run well using the hardware midi and audio ports.

Thanks for the help!

1 Like

Update 201001 now available

NOTE: This is a Fates-only fork maintenance release that is NOT synced with the main norns release schedule. The previous release had a couple issues with regards to encoders acting badly so I wanted to push this out to fix. The issues are due to some github repo changes that I missed in the Fates fork. Apologies for any unwanted glitchyness.


If you are on 200218 or later
use SYSTEM > UPDATE while connected to the internet.
(please report back if you have problems with this)

If you are running a version prior to 200218, DO NOT USE SYSTEM > UPDATE .
You must update manually via SSH. Instructions are on the release page: https://github.com/fates-project/norns/releases/tag/2.4.2.5

16 Likes

Great work on this @okyeron, great layout and breezy build

Still working on the panel finish (ran out of paint :clown_face: )

Aluminum top panel, Delrin bottom, glass screen protector
Tried to conjure some Aleph and Grid 128 DIY kit vibes

25 Likes