#1563

I built my Fates a few months back and have been loving this thing!

One question I have (which has probably been answered already but I haven’t found it)- can the USB C jack on the rear panel be used to power the RPI 3b+, or is that only intended for use with the RPI 4? My RPI came with a kit including the USB power adaptor and that’s what I’ve been using, but I’d prefer to use the rear power connector if that’s possible.

#1565

yes it can…

#1566

The rear USB-C jack is only supplying 5v power.

So yes - I use a pi3b+ with a USB-micro-b to USB-C adapter on one of my test boxes. Works great.

1 Like
#1567

this is the kind of thing that should be “easy” to change.

pragmatically and conceptually, fates is a fork of norns. it seems to me that given that, it would be cleanest and easiest to maintain its software as a fork as well. that would also make it more feasible to integrate changes back to the upstream when desired. (at present, fates is in a sort of odd state: using norns upstream sources, but with alternate files being patched in and recompiled at install time. or something like that?)

1 Like
#1568

That’s already done

I could look into that, sure.

I’m not sure I understand the distinction. The fork changes 3-4 files for compatibility and updating.

(Please keep in mind that I’m not trained as a programmer at all - I’m a photographer by trade - so my coding skills are quite hackish)

1 Like
#1569

It should be easier than that again, all that needs to be done is to inject a encoder change handler into Norns before the script. Not sure if there’s a “safe” place for users to modify Norns this way?

#1570

the place i pointed out would probably be the appropriate place, assuming:

  • enc4 has an immutable function
  • scripts should not need updates or any additional new modules
  • enc4 function should be able to use other lua APIs

specifically i’d inject the new handler before line 60 where the dynamic encoder callback is fired. (that dynamic callback is changed by menu / script.)

so for example, a fates install would pull down an entirely different stack of lua system code with the modification suggested above. that way fates users / developers can easily see what their system is doing and maybe customize it, rather than having to extrapolate between two repos. you pull down the sources for your software and build/run it, full stop. certainly not a big deal, just a thought, only trying to help.

huh, i must be looking in the wrong place. couldn’t find any alternates for gpio.c in the fates repository. the only gpio-related thing i found was the overlay unmasking the enc4 pins. that is necessary of course, it makes orac work, but matron would also need modifications to use those pins. the only .c file i found is device_monitor.c.

emb@inkpad:~$ cd src/fates/
emb@inkpad:~/src/fates$ find . -name *.c
./install/norns/files/device/device_monitor.c
emb@inkpad:~/src/fates$ ack gpio
overlays/fates1.5-ssd1322-overlay.dts
38:    target = <&gpio>;
65:        reset-gpios = <&gpio 4 0>;
66:        dc-gpios = <&gpio 17 1>;

overlays/fates1.5-buttons-encoders-overlay.dts
8:        target-path = "/soc/gpio";
27:                gpios = <&gpio 26 1>, <&gpio 16 1>;
43:        target-path = "/soc/gpio";
62:                gpios = <&gpio 5 1>, <&gpio 6 1>;
78:        target-path = "/soc/gpio";
97:                gpios = <&gpio 13 1>, <&gpio 12 1>;
113:        target-path = "/soc/gpio";
132:                gpios = <&gpio 27 1>, <&gpio 22 1>;
151:             compatible = "gpio-keys";
156:                gpios = <&gpio 24 1>;
160:                gpios = <&gpio 25 1>;
164:                gpios = <&gpio 23 1>;

overlays/fates1.2-buttons-encoders-overlay.dts
8:        target-path = "/soc/gpio";
27:                gpios = <&gpio 5 1>, <&gpio 6 1>;
43:        target-path = "/soc/gpio";
62:                gpios = <&gpio 13 1>, <&gpio 12 1>;
78:        target-path = "/soc/gpio";
97:                gpios = <&gpio 26 1>, <&gpio 16 1>;
116:             compatible = "gpio-keys";
121:                gpios = <&gpio 24 1>;
125:                gpios = <&gpio 25 1>;
129:                gpios = <&gpio 23 1>;

overlays/fates1.7-ssd1322-overlay.dts
38:    target = <&gpio>;
65:        reset-gpios = <&gpio 4 0>;
66:        dc-gpios = <&gpio 17 1>;

overlays/fates1.7-buttons-encoders-overlay.dts
22:        target-path = "/soc/gpio";
41:                gpios = <&gpio 5 1>, <&gpio 6 1>;
57:        target-path = "/soc/gpio";
76:                gpios = <&gpio 13 1>, <&gpio 12 1>;
92:        target-path = "/soc/gpio";
111:                gpios = <&gpio 27 1>, <&gpio 22 1>;
130:             compatible = "gpio-keys";
135:                gpios = <&gpio 24 1>;
139:                gpios = <&gpio 25 1>;
143:                gpios = <&gpio 23 1>;

overlays/fates1.7-buttons-4encoders-overlay.dts
22:        target-path = "/soc/gpio";
41:                gpios = <&gpio 26 1>, <&gpio 16 1>;
57:        target-path = "/soc/gpio";
76:                gpios = <&gpio 5 1>, <&gpio 6 1>;
92:        target-path = "/soc/gpio";
111:                gpios = <&gpio 13 1>, <&gpio 12 1>;
127:        target-path = "/soc/gpio";
146:                gpios = <&gpio 27 1>, <&gpio 22 1>;
165:             compatible = "gpio-keys";
170:                gpios = <&gpio 24 1>;
174:                gpios = <&gpio 25 1>;
178:                gpios = <&gpio 23 1>;

overlays/fates1.2-ssd1322-overlay.dts
38:    target = <&gpio>;
65:        reset-gpios = <&gpio 15 0>;
66:        dc-gpios = <&gpio 14 1>;

install/norns/Norns_install_instructions_1.8.md
142:    sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=reset:4,dc:17 rotate=180

install/norns/files/init-norns.sh
1:#init gpio
emb@inkpad:~/src/fates$
#1571

Norns fork is here: https://github.com/fates-project/norns

I thought that’s what I’m doing here with the fork.

EDIT EDIT: The Enc4 question for me is really “is this (enc4 as volume) a good idea and should that feature get added to the code?”

2 Likes
#1572

yes apologies! it looks good, i’m glad i asked. (so fates project doesn’t need to do those patches anymore, right?)

#1573

That’s correct - they’re part of the fork

#1574

Late to the party. What’s current on parts & kits? I’m having trouble sourcing the display. Thanks!

#1575

Kits from me are all gone.

Displays can be purchased direct from the manufacturer:
https://www.newhavendisplay.com/nhd2712864wdw3-p-9547.html
or https://www.newhavendisplay.com/nhd2712864wdy3-p-9542.html

#1576

I guess that’s what I was trying to get at. This is something I think should be user customisable, many scripts already assign volume to encoder 1, and I’d rather be able to assign encoder 4 on a per script basis. Haven’t had time to hack on this idea yet.

#1577

enc(4,delta) should work right now for individual scripts.

But - this is really a custom thing for individuals - not something for released scripts (since it won’t work on other hardware)

1 Like
#1578

Alright, might be a slip overlap here, but does anyone here running Fates also have a MSW made 16n running a teensy LC?

I am having issues with communication dropouts with my teensy LC based 16n on fates. It will send slider data for about 30 seconds after being connected and then suddenly lose connection. It does this both with @infovore’s newest firmware and with the stock one compiled by MSW.

I have a second 16n board running on a teensy 3.2 that does not have these issue. Wondering if anyone else is running in to these issues. (again, user overlap may make this a small pool)

EDIT: also of note, I am posting this here because I have no issues with the LC based 16n in the web midi test or otherwise while connected to my laptop, only when connected to fates. I do not remember having this issue before the update to the parameters system but will have to check an old version of the fates firmware to confirm.

#1579

So yeah - I’m having a problem with 16n when it’s been flashed to Serial+MIDI (which is what the default hex firmwares are set to).

I’ll be working on debugging this later.

If you’re able to recompile the firmware yourself you can get back in action by reflashing with the USB Type set to MIDI.

1 Like
#1580

this isn’t a huge deal, because i’ve been dealing with it since i first built my fates, but every time i boot it up, i have to put it to sleep and reset usually twice before any midi devices are recognized. that process works every time, so it’s not awful, just irritating. is that normal?

#1581

So, I’m always late to the party. Any chance of another pcb run?

#1582

this is not normal for standard norns*, and i can’t reproduce it with the current of the norns software. (that is, assuming i am understanding your report correctly, which seems to indicate that you cannot access any MIDI functionality without rebooting after a device is plugged. it is always helpful to be specific about what actions you took, what you expected to happen, and what actually happened.)

what i’m seeing is:

  • hotplugged devices are immediately usable/mappable, are automatically assigned to open device slots in SYSTEM > DEVICES > MIDI, and are immediately available as selections when manually assigning those slots.

  • devices that are already plugged on boot are also immediately usable/mappable, and also immediately available as selections for slot assignment, but are not automatically assigned to empty slots. if you assigned them before, (or if they were assigned automatically from hotplugging,) those assignments are retained between SLEEP/boot cycles.

i did not design or implement the midi mapping subsystem, but i believe this is intended behavior and it basically makes sense to me, because otherwise you would not be able to manually clear a slot and have that decision be persistent. (though i agree it would be more intuitive if behavior at boot were more congruent with hotplugging behavior, somehow.)

i don’t know exactly what this means. did you use SLEEP, then power up, then use SYSTEM > RESET? (since v2.3, RESET will clear all system state and MIDI mappings and restart the software. it does not shut down the computer.)

in normal operation you should always just shut down with SLEEP, then pull power, then connect power again to boot up.

(* my one caveat is that the device monitoring source is one place where the fates fork has diverged, but i’m pretty confident that the midi device detection functionality is unchanged and unhindered.)

#1583

My fates works exactly as zebra described the “normal behaviour”

(The only difference I see on device monitor is on grid detection so the diy neotrelis can be recognized )