#1138

Just (hopefully!) a clarification here - This is pretty much what I meant, that is, I don’t think fates is meant for someone who is ONLY an end-user.

1 Like
#1139

Fundamentally Fates has different hardware than the official Norns and I think most of us on the Fates hardware have some understanding of this and have made a considered decision in buying it.

In my view the whole reason the update menu bricks fates, and is yet to be fixed, is actually the complete opposite of what you seem concerned about. Okyeron could easily have hacked out a solution but it would depend on him maintaining his own build, rather he is working with tehn to find a solution that would allow us to use the official Norns update process (or else something very close to it) This would mean we get releases at the same time as everyone else and are not dependent on okyeron for updates.

I’ve been hacking around with my fates for the last few weeks, submitted PRs to a few libraries, started on a drone in 3 worlds entry, and I have yet to see a single divergence is scripts due to fates/norns. And I don’t expect too at that level.

If anyone with a Fates board is having a hard time with the update process please post here and/or message me. I’m more than happy to walk you through it via FaceTime or Google Chat time zone and scheduling dependant.

Otherwise, I’d suggest, please be patient. :slight_smile:

10 Likes
#1140

“In my view the whole reason the update menu bricks fates, and is yet to be fixed, is actually the complete opposite of what you seem concerned about.”

Excellent - my concern (as stated above) was that the codebase may diverge.
If it were to diverge it would have been best to manage it and do it explicitly.

Glad to hear that the code is going to maintained in common and will be fully incorporated into the Norns repo. I wasnt aware of that. That really helps and is very encouraging.

(I thought I had seen that Tehn didnt want to support Fates and Raspberry Pi 4b+ kernel images in the norns repo - my apologies ! I must have misread that ! Oops! Again - really sorry for any confusion !)

1 Like
#1141

Not a problem. I’m not sure what tehn has in mind for how to prevent divergence, but I’m assuming like in many of these community based endeavors, the hopes was the community would do it themselves.

The two aspects of the FATES that were of explicit concern were two ways the hardware differed, the optional fourth encoder and the extra power of an optional Pi4.

The norns was never going to change in a way to take advantage of these. And thus, the concern was to find a way for them to (which having different occasional kernel needs) stay in line in terms of usability and community (which is to soothe one of your major concerns in developing scripts for the environment).

With the comment that the creator of the FATES is interacting with tehn to better align these two devices, we have even greater reason to feel encouraged in our choices to buy in to the norns environment, no matter what hardware we choose to run it on.

3 Likes
#1142

I thought I had seen that Tehn didnt want to support Fates and Raspberry Pi 4b+ kernel images in the norns repo

This is actually correct, Tehn, quite fairly, does not want any burden in maintaining fates, but, based on Okyeron’s comment discussions are still on-going.

All I know is rushing these things can only lead to the wrong answer.

#1143

Thanks - and that was exactly why I was concerned. I took that statement as definitive and explicit. I agree rushing decisions like this leads to crap code and infrastructure that you have to live with forever - that was why I started this discussion in the first place !!! (To try to understand the best way forward without rushing it and discussing the pros and cons…)
Maybe it’s best to stop speculaitng now if discussions are ongoing. I’ll happily shut up now :slight_smile: (but will reply to questions etc)

#1144

If it helps calm things even more; I’ve been a lurker here for a while, and I was surprised to find that @okyeron doesn’t work for monome (AFAICT) - I say that because he’s so deeply involved in so many things here on lines. Just one example - he’s designed a case for the norns DIY shield project, which is most definitely an official monome deal, and has no crossover whatsoever with fates.

Combine that with coding answers, script writing, etc., etc., and it’s clear that 1. He’s deeply invested in monome’s success 2. He at least seems (I wouldn’t dare to speak for e.g. tehn) to have a degree of respect and trust from the Power What Be :slight_smile:

tldr; the BDFL of fates isn’t some fly-by-night newcomer - he’s deeply invested in monome and the monome ecosystem

1 Like
#1145

Just to be clear - in no way or form did I say, imply or think he was "some fly-by-night newcomer”!

1 Like
#1146

Also! It might be worth snagging one of the DIY Norns Shields is you want to be a part of the ecosystem, but the FATES issue nags at you. This way, you’ll know (As well as anybody can with a product like this), that you’re going to be supported over the long term. Added plus will be that all of us with FATES will get to enjoy any work you contribute!

#1147

Absolutely! :slight_smile: I was planning to build a Norns Shield as I was assuming that Fates would not be fully supported in the Norns repo. But if Fates is fully incorporated in the Norns repositories, as has been said above, then I wont need to :slight_smile:

1 Like
#1148

Luckily for all of us, they are both pretty affordable options all things considered. We are all excited to see what you come up with!

1 Like
#1149

@forestcaver your concerns make perfect sense to me and to the monome maintainers as a whole, and fwiw i think the defensiveness here is a little misguided.

we’ve been pretty explicit about preferring your option 2 over option 1:

1 Like
#1150

These are not quite right.

Fates is NOT incorporated into the Norns repos at all. Monome wants to keep the codebase free of any third party dependencies.

The important thing to remember here is that I’m trying to make it so Fates runs the norns codebase* without any modifications if possible. Currently that means the UPDATE mechanism is broken on Fates

* in this case, I’m talking specifically about norns (crone, matron) and maiden.

So to be clear - the norns codebase is not diverged at all on Fates. You can go do a git pull in the norns directory and you will get the current code same as on norns/shield hardware (* there are a couple caveats here - see below)

The OS or kernel for Fates is different from norns/shield. It’s built on the standard Raspbian install. Norns/shield have a custom built kernel.

* Caveats: there are in fact a couple of “patches” that I need to apply to make sure things work on the Fates kernel setup. This is inconsequential for most people as it applies to recompiling norns. Yes - I do need to document those changes.

2 Likes
#1151

Thanks - from where you guys are coming from it makes complete sense. I’d do exactly the same if it was my design !

#1152

FWIW - I’ve not really had a chance to reply today and this is not really helping.

I’m trying to find a way to NOT fork the entire codebase to change 2 lines of code.

2 Likes
#1153

(A bit frustrated right now)

THIS IS A DIY PROJECT.

If you want something different. Make it happen.

21 Likes
#1155

Thanks - I understand and that was absolutely my understanding initially, which is why I posted initially - the points you’ve quoted from me are where I was restating and emphasising what I was told would be happening after being told that my understanding was wrong.

I absolutely appreciate that the kernel has to be different. I understand that kernel patches to norns will likely break fates.

My initial post was also asking what the “patches” were that needed to be applied so that anyone could build it - making gross assumptions I am guessing it is likely to do with codec drivers and support.

Thanks for clarifying.

I was just concerned that code could drift apart without an explicit decision to fork - if that happened everyone would end up with their own forks and patches. Eventually scripts would end up diverging and may start supporting individual hardware. I just wanted to start a conversation about managing the differences and forks.

With it all being open source, it would be so easy to start modifying the hardware that is on github (already) eg the shield - I’ve been looking at adding a headphone amp and thinking about video etc etc. Without some care, the code base may fragment…

As you said - if discussions are taking place and decisions are being made, I’ll happily shut up and wait to see what happens…

Blockquote
(A bit frustrated right now)
THIS IS A DIY PROJECT.
If you want something different. Make it happen.

Not sure if that is meant at me or not. But I thought I was discussing how to make stuff happen. Apologies…

#1156

Noob here, I think this discussion is a valid one, but it derails the intent of this particular thread and is making it difficult to parse for the individual behind Fates. I suggest creating a new topic.

okyeron, no worries, man. I would see this conversation as proof that people really care about your stuff. What you’re doing is awesome and ambitious. Nice work.

8 Likes
#1157

err, sorry to be unhelpful. just wanted to clarify the position and put it in context, since there was a lot of speculation up there.

i hear you on not wanting to fork the whole codebase for small changes. but it does seem like there has to be a fork somewhere. maybe we can make norns-update a separate module or something.

the idea of making a totally separate path for kernel updates is also interesting so i’m glad it was brought up

5 Likes
#1158

just updated to fates200129 over ssh it worked seamlessly, even for a noob. If this is the only price I must pay for wonderful fates then I am underpaying.

11 Likes