#1117

Heh no worries! I just checked and it looks like there is continuity between GND and 5V :sob: I’ve uploaded two photos – disregard the awful state of the GPIO holes, I just desoldered them. PCB was purchased as part of the full kit.

I’m guessing I’ll need to replace that voltage regulator?

IMG_5887|666x500

#1119

Hi - I just want to make sure I can build the lastest software.

It looks like norns software and fates have now permanently diverged - is that correct?

If so, that’s a shame - the code bases will continue to diverge and I guess apps will be developed for fates (4b+ and more memory) that will no longer run on factory norns now… (I’ve been meaning to play with some ideas that are pretty computationally intensive…). Also code will be developed on fates and may not get propogated back to norns…

What changes do we need to build norns on fates going forward ? Is there any documentation as to what needs maintaining? (Presumably pull from the fates repo initially then manually merge norns repo each time norns is updated ??? Is that correct?). Is it worth being explicit and formally branching the code ?

(Apologies if I’ve missed the documentation - I scrolled through and searched this thread but there are >1000 posts so I may have missed it)

(Partially as a dumb user - I feel a little uneasy relying on just one person to sort out the builds and updates each time - no offence okyeron, but if you were hit by a bus, I wouldnt be able to update my fates currently :slight_smile: )

#1120

The only real divergences I’m aware of are

  1. The update process - generally speaking, up to this point, you can manually[1] update using the same tarball as norns - as long as you do NOT do any steps involving updating the kernel - that’s where the hardware differences live. i.e. there hasn’t realistically been much of a divergence at all, and none in the important bits (i.e. everything above the OS level)
  2. Users with a DIY grid/arc device will have to manually apply a patch - but then this is true on norns as well

EDIT: tldr; There are no differences which would impact script creators or users

[1] By which I mean open the update.sh in a text editor and copypasta the commands therein to a command line one-by-one

3 Likes
#1121

got some christmas return money dedicated for this, hoping the full kit is close to coming back up for order…

#1122

To be very explicit here - @okyeron is doing everyone a solid by making a nice “fates update”.

There’s no technical reason for him to do so, as I stated previously. He’s graciously putting in the time to automate what would otherwise be a much more manual (but certainly not onerous) process for all fates users.

10 Likes
#1123

Blockquote
To be very explicit here - @okyeron is doing everyone a solid by making a nice “fates update”.

I appreciate that and certainly not disputing it - I just dont know what to do myself and I dont know where they have diverged. Naively - I dont know what part of the norns update does not update the kernel and which does. (I have built linux kernels in the past)

Not sure I understand when you say "there hasn’t realistically been much of a divergence at all” when you can no longer use the big menu entry that say “Update” - naively that seems like a divergence to me. Especially when you have to then do a manual update from a different repository - maintained by a third party - again that naively seems like a divergence to me.

Personally, it would seem to make sense for Fates to remove the Update entry in the menu and accept that the code has diverged and just maintain them separately. Certainly, it’d be a lot safer for end users.

Having this what seems to be to be a divergence would just encourage me to develop on fates and not worry about backwards compatability with norns…

It seems a shame that Norns doesnt have two options - update os and update the Norns application…

#1124

So, another way to put this is the Norns system, or suite is built on top of the kernel. It is itself, a self contained system, interacting with jackd, crone and more underlying architecture. There has been a desire stated by the creators of the norns suite themselves to not have an actionable divergence, meaning a different experience using different scripts meaning that folks like you or I will have to deal with different branches of the software (say, a norns suite that has been updated and forked to remove the Update tab).

This is one of the great things about norns, it is simply a system for connecting Lua scripts to a SuperCollider engine and having all the pieces in place to allow sound to be generated and other hardware to be interacted with. The kernel difference is about backend tools being upgraded, that would interfere with how this suite interacts with the kernel. Thus, for now, when you see an update being done through a separate repository, it is @okyeron making sure all the right hooks are present (this is of course my naive, I don’t program speak, so forgive me if terms and specifics are incorrect).

Long story short, Norns is the same. On every piece of hardware that runs it. It is just Norns. Sometimes someone needs to make sure that when updates alter lower level communication to hardware, it is handled, but otherwise, it is still Norns. Its a software suite, or a simplified OS, and thus, it is unchanged between systems.

Think of it this way: When you install windows on your computer, someone out there makes sure that you have the proper drivers for you tools to then interact with windows. While the hardware of your computer might be different than the person next to you, a vanilla install of window essentially is the exact same for everyone (well, exceptions, of course, but you know what I’m getting at).

Think of Norns the same way. Same suite of software, just occasionally (you might be able to use the Update function on future updates, like we have on prior ones!) you’ll need to do a little extra footwork to get the same result.

2 Likes
#1125

I appreciate all that - I really do understand the architecture (I think I do - or at least I understand how linux works and divides kernel from application).

My point is that, if you treat norns and fates as appliances they behave differently to an end user - one you can press ‘update’ and the other you cant - if you press the big button that is prominent on the menu you brick the device. That seems like they are different and have diverged to me.
To update one you press the button ‘update’; to update the other you have to pull files from different repos and update them manually and potentially manually merge them.
Your analogy breaks down a little - the ui facing part of norns can affect the kernel - when you use the nice ui entry ‘update’ it pulls kernel patches and compiles as root. This is sort of my point - the two should be separated. If you want the norns applications to sit separate from the kernel - then that is great! But if they can affect the kernel then it isnt separate - you have to consider the kernel + norns + maiden etc as a package.

Think of it this way: if you have two windows computers - on one you use Windows update and it works fine. On the other if you do that the computer is locked up and the operating system is corrupt - you then have to reinstall windows. To update that computer you have to get files from several places, merge them and compile them. For every update. Also you need to remember to never press the big red button marked “update”. It is hard to argue those two windows computers are the same and the software hasn’t diverged.

#1126

My suggestions/options (in the spirit of positive feedback, rather than whinging :slight_smile: ) are:

  1. Truly separate kernel updates from norns and accomodate the fates changes in the norns repo. This obviously requires work from Monome/Tehn and I completely understand any reluctance !!!

  2. Accept they have diverged and branch the code properly. Point the Update on Fates to a repo that does the update.

  3. Accept that it is not for use as a serious tool/appliance and that pressing the ui button ‘Update’ bricks the device and for every update you need to do a manual update.

I cant see any other good options…

#1127

Since we have two analogies which are actually pretty interchangeable, let’s go with it:

A) Average end user - “Windows updates automatically and notifies me to reboot” i.e. norns UI “Update”
B) Power user/admin - “Notify me when updates are available, and I’ll decide what to do” in a rather granular way, at a fairly low level

Yes, I’m saying that fates user should not have ANY expectation that they can be a “my grandmother” type of user. They’ve built this thing; they need to understand the software side at least as well as the hardware side.

3 Likes
#1128

So, there are two issues raised here now. One is that you’re worried which to develop for. You’re talking high level architecture. That is and will remain unchanged between the two. That has been an expressed by both the creator of the FATES and the creator of the norns.

So, you want to design a script? You’re in luck! There is no difference and will be the exact same experience between all machines that are running norns.

If you want a system that works exactly as a factory machine? Well, the only answer to that is a factory norns. The structure of the norns software suite isn’t being changed. The creator of the norns has expressed that he doesn’t want there to be any divergences between the way the software structure works. And again, this is specifically so that any developer of a Lua script would know it works the same on everything.

So, the answer to your two questions are, yes, develop scripts! We’d love to see your script on the norns/FATES/ norns shield! But if you’re looking for the UPDATE tab to go away, you’re sort of out of luck.

2 Likes
#1129

Yes, this. It’s like complaining about developing Python scripts on OSX vs. Windows - 99% of the time scripts will be exactly the same.

#1130

I dont really have an issue with having to have a decent software understanding.
My point is that there’s no good reason not to make it easy. Especially when you have
that great big, easy to accidentally press, button that instantly brick the device sitting in a high level menu !!!

To amend your analogy (B) above - it’s like having a button that only says “Update Windows” but when presssed it really corrupts the OS. There is no “dont press this button whatever you do - you are a power user and pressing this button is a stupid idea - go and learn how to do it yourself - you built this PC you shouldnt trust the software” :slight_smile:

#1131

Ok, the entire system is open source. If you feel like code diving, you can absolutely hide “update” from the system menu on your personal machine.

At a future point, this MAY be a feature that works on fates again if someone does the work to make it happen.

A fates costs a quarter the price of an og norns, this is one of the trade offs.

1 Like
#1132

Granted. I agree. OTOH, my point is that there shouldn’t be anything such as a “fates end user” (i.e. only). If you built one of these, you should be actively watching (at a minimum) this forum to see what’s going on, in which case you would know to never touch that button.

Fates does not compete with norns. norns is an appliance (-ish :stuck_out_tongue: ). fates is a kit. I’m not sure how one would even learn about fates without coming to lines.

I would probably have no disagreement with you at all if @okyeron were trying to sell pre-built fates as a norns competitor - that’s EXPLCITLY NOT what he’s doing.

1 Like
#1133

Partly right - but I am also unsure whether to invest any time in learning to code for it as it is not a stable platform!

Part of my dilemma is that maybe I’m in the wrong place with the wrong tools. My problem is that it seems axiomatic to me that you separate machine level (OS) things from user-level things in eg linux and make the tools stable and safe to use.

Having the ability to brick the machine from a menu ui and other developers/users being very happy with it and thinking it is a good design decision seems a little scary to me! Especially when there seem to be alternative solutions. I’m really happy coding at the os level or eg stm32; but if I made a diy mutable clone and if when I clicked a button the module bricked itself, I’d branch the code and fix it…

It’s easy to say “well go and make the changes yourself” which is fair enough, but my point was to try to reach a consensus on branching the code or find a better solution so that the number of branches was reduced and to try to see if it was possible to keep the codebases in sync.

If I am irritating people or annoying them with these suggestions then apologies and I’ll shut up !!

#1134

Not sure I agree about the Fates end user - I think you should be able to build it, set it up and actually use it! I often have two hats - hack/diy builder and then user… when I use it as a user I want it to be as painless as possible - which seems very doable… (and, to be fair, it’s an absolutely trivial build from pcb - all the hard work is done by the Raspberry Pi foundation!)

#1135

No no, you’re not irritating people. I think you’re misunderstanding the difference and similarities between the systems. If you’re worried about writing scripts, don’t be! They’re going to work for norns and if the FATES dies (which I don’t see happening), don’t worry, it’ll forever work on the norns. They’re par for parcel. You would risk having more issues of dying platforms if we began to diverge FATES and norns.

#1136

I dont think I am misunderstanding the differences between them :slight_smile:
I’m pretty sure I understand where the differences are in the kernel and I’m pretty sure I understand a lot of the lower lever daemons (but I’m also sure that I dont understand the fates/maiden etc parts which should be pretty identical - that is my assumption). Which means I dont understand the update process and what is different between fates and norns!

My point is that the codebase is now different and becoming more so. My suggestion was to acknowledge this and manage it in the best way possible.

I do think if they continue to diverge and that is not managed then there may develope incompatabilities in scripts and at that point you may as well write scripts that take advatage of the increased performance of fates. If you manage the divergence properly that probably wont happen !

Part of my concern is that I have some ideas for scripts that I could do in other systems. I’d like to do it in Norns (Fates) but at the moment, I’m not sure it’s stable enough to commit to the platform enough to learn it well enough to do what I want :-). Because of this I am close to getting a diy norns shields fabbed (currently $2 for five pcbs at jlcpcb + $8 delivery !) but I am really unsure whether to abandon the idea of developing on norns altogether… (I was about to buy a Grid but am holding off on that as well…) Not trying to be dramatic but I have limited time and it’s a question of where I want to expend my efforts :slight_smile:

I’ve probably said too much and been too vocal !!! I’ll shut up for a bit !!! Thanks for bearing with me…

#1137

FYI - I was going to reply earlier but I’ve got things to do for awhile and now there’s like 10 more posts to digest.

For the moment, please be patient. I can post a bunch of detail later.

In the meantime, I’ve pitched an idea to brian about how to make the update process easier on Fates.

13 Likes