fates should have its own norns fork. this is trivial, and should happen asap. there’s no reason that @okyeron needs to do this— anyone can do it.

given the existence of the norns shield, i question the general need for the continued production of fates as it’s a huge amount of overlapping work. if you want a norns experience with different knob positions go ahead and clone the norns-shield… it will work perfectly and have a unified codebase (and electronic similarity). this means all code contributions go to benefit everyone, and there aren’t factions.

this doesn’t mean fates dies. they work and will continue to work fine. all that needs to happen is an incredibly minor fork. and that is exactly what forking is for. this is DIY.

granted, i am concerned about CPU-intensive pi4 projects that may not be back-shareable to the larger community— though i’m not sure we’ve seen a many projects shared from the fates crowd yet.

we’ve put a incredible amount of energy into fostering a community-driven ecosystem in addition to releasing a DIY version. at this point having a clone represents a substantial distraction, where we could be putting energy directly into the core experience for everyone.

16 Likes

Fork created. Nothing has been changed yet. I’ll post update instructions in this thread when they are ready.

21 Likes

all of a sudden i’m experiencing some distortion coming out of my fates.

this is happening on a global level (when playing audio through scripts and tape) the compressor and reverb are both turned off…

has anyone experienced this before?

1 Like

Yes, used to happen to me quite a bit actually. It seemed to subside mildly - right around the time that I purchased and began using a higher quality 32 GB Micro SD card (urged by Tehn’s recommendation to everyone from a different thread, I believe).

Since I updated to the latest available norns version at that same time I can’t say for sure what it was that actually improved the condition.

Whatever the issue was, I was able to record it to tape and will post an example soon. Like I said before, it still happens to me - just not nearly as often as before.

1 Like

that’s curious, i’m using a 32 gb sandisk ultra which is the same sd that i use in my other fates that hasn’t been suffering from the distortion issue. i’m on the last update not the current so maybe i’ll try to update and see if that improves it. thanks for the info.

1 Like

I switched from SanDisk Ultra (which was installed when I was having the problem more frequently) over to SanDisk Extreme Pro (with seemingly less audio glitches now).

Edit: To be clear, I only noticed audio glitching with certain scripts. Meadowphysics was one of them. If I input many notes and cranked the BPM particularly. That was a different sounding audio glitch than the one I was originally speaking of, and seemed more related to clipping, though it didn’t really sound like usual digital or analog clipping. I have an exact audio capture of that. I don’t think what I heard in Meadowphysics can have anything to do with the SD card, since we’re not talking samples here, but synth, right? Maybe the audio issues are script/engine specific?

The original issue that I was speaking of, which your post reminded me more of - I experienced that issue with MLR originally. Not sure if I recorded that, but I’ll bet I can still get it to happen. That was more like a fuzzy sounding sample-rate issue, and once it occurred I could not get it to stop happening no matter what script I switched to. I needed to reboot to get things back to normal.

this is more so the general sound of the audio regardless of what script i’m using.

also regardless of rebooting it persists. i’ve updated to 200129 and it’s still present:/

i’ll grab a few sandisk extreme pro’s and see how that affects things…

Maybe just try re-imaging first, if you haven’t already done so.

What else is different between your two fates?

Both my norns and fates have ORAC and Sidekick going, but otherwise rather vanilla. Same versions installed and devices used with them both, and I’ve simply never encountered these audio issues with norns before.

You could try running audio tests and see if you get any issues when recording raw audio, or playing back. (at least potentially isolating if it’s likely hardware or software related)

There may be some crazy deep thing in the norns stack causing that particular issue. Might be worth recompiling the norns code. DM me and I can give you some instructions for that. Maybe also killing psets :thinking:

3 Likes

@claasp, @static, @okyeron; FWIW: I’ve had “weird audio” issues with “bad” power - like using a battery pack that can’t provide enough voltage (as it’s draining), or a wall wart which can’t sustain the necessary amps…

3 Likes

I completely understand this, but for what it’s worth - even though I’ve been lusting over monome gear for ages, it’s simply not an impulse buy.
I jumped on Fates, and that has allowed me to experience the “monome way” (or whatever you want to call it). I can safely say there will be more monome gear in my future, now that I know we’re compatible.

Fates was an entry drug, if you will :slight_smile:

1 Like

Wow, this thread blew up since I was last here!

As with all DIY opensource projects like this, there are a lot of newbies kicking around. Perhaps it’s worth giving thanks, sharing experience, and throwing out some advice relating to how to view these types of open source projects evolve?

Supporting opensource projects is a thankless job and I seriously appreciate all of the work being done by @okyeron, @tehn, and the rest of the community to move forward the fundamental ideas found in this ecosystem.

Both norns and Fates are substantial pieces of work on their own at this point. Putting the Fates cat back into the bag isn’t gonna happen at this point. The biggest win anyone can wish for is towards identifying and taking actions that support the continued growth of the ecosystem.

There is real wisdom behind whatever decisions lead Fates to staying close to norns’ mainline for all this time. Forks can devastate communities if they are not well tended. That said, well tended forks also lower the barrier for other developers to support the subtle differences between the two projects. They also help explain behaviors that are generally “supportive” as well as those that lead towards “you’re on your own, kid”.

As the fork spins up, it might be worth suggesting some of those behaviors. Something like:

  • For developers building new software for use by the norns community, it is suggested that Fates be assembled with Raspberry Pi 3b+ and without the 4th encoder.
  • Fates is not norns and 100% compatibility should not be expected.
  • Fates is fundamentally a DIY clone of a complex ecosystem. While small amounts of support can be provided close to the “happy path” suggestions provided in this list, deviate from this path will reduce the amount of support you will be able to find. Fully supporting yourself while working outside of the happy path of Fates will likely require a strong understanding of soldering, hardware debugging, kernel modification and compiling, device trees,the Linux boot process, jackd and linux audio configuration, hardware interfacing APIs (i2s, gpio, etc.), web technologies, and more.
  • The happy path is happy! You’ll get better support, the community will benefit from your efforts, and you’ll make more music!

:man_shrugging: I’m no copywriter though…

Thanks again for all the help! I’ll take a look at the fork soon!

p.s. I tested my 3d printed case changes and they still need some work before I share them.

8 Likes

If your power supply isn’t powerful enough the resulting brown out causes some patches to distort.

you can check dmesg for undervoltage warnings to confirm this

1 Like

For the bleeding edge types:

initial changes are in a branch here: https://github.com/fates-project/norns/tree/fates-changes

Changes:

  • disables the update menu item (it now does nothing)
  • fix for crone wscript (adds libatomic)
  • adds teensy based diy device compatibility (neotrellis grid)
  • enables 4th encoder in norns*

* script warning - please do not release scripts with enc(4, delta) without explicit warning/documentation that this is a Fates Only Feature. Ideally make any enc(4) item completely optional and more like a bonus feature. (This could probably use some more testing)

Wanna try?
(Warning - Proceed at your own risk. May void your warranty. Prohibited in some states. May contain nuts/traces of nuts. )

cd ~
sudo rm -r norns
git clone https://github.com/fates-project/norns.git
cd norns
git checkout fates-changes 
./waf configure
./waf

Then restart with SYSTEM>RESET or reboot

31 Likes

@okyeron thanks a ton for doing that.

gotta say this makes it way easier on the psyche for norns maintenance. even for tiny changes that could well be merged upstream, it feels way more efficient to see the changes in their own space. we may well decide to merge little things like -latomic. and we may implement a more customizable device detection scheme that you would want to pull.

but this way you can make sure that fates users always have something working that is customized to their solution, and we don’t have to have a stress-fest every time there is an upstream change.

so thanks for that, and for your patience and enthusiasm as a whole.

26 Likes

Works for me. No allergic reactions so far. Thanks a lot.

1 Like

Thanks for this. Nice to know that the neotrellis support is built in on this fork!

2 Likes

@okyeron thanks for this update. It’s working well for me with a neotrellis grid and a crow.

Thanks for adding support for the 4th encoder. Any suggestions on the best way to programmatically detect if a script is running on Fates vs. norns? I want to only display a value on a screen if the 4th encoder is present. At the moment I set a flag the first time the encoder is turned and that works fine, just wondering is there is something more elegant.

3 Likes