#1482

maiden will report the exact filepath that’s having issues while loading a problematic script – do you have your output from that?

1 Like
#1483

Re-flashing the SD card is something of a “scorched earth” approach and should not be necessary.

You will need to restart/RESET after adding/removing any script with an engine. (supercollider compiles all these when it starts up, so the system needs a restart to get changes).

As dan mentions - Maiden is your friend and will tell you details about errors, duplicates, etc.

2 Likes
#1484

curious if anyone else is experiencing this… i’ve noticed this with the last 2 updates.

when powering down and booting back up again (mon and tp) are at their minimum regardless of their positions when powering down.

is there a solution to this?

hmm it’s also happening when switching from script to script

#1485

Would you please share what should be changed for the hp level to be working ?
For me the hp volume is not enough and most of the times I have to use the compressor to listen when I’m using my fates outdoors, so I’m thinking of creating a script and reapplying after every update.

#1486

I believe this is a norns issue introduced in the last update and has been addressed

Should be fixed in the next update

See the following from up thread, although I am not sure what the “max” value should be

So you can do the following from maiden to change the hp volume on fates (use at your own risk :grin:)

os.execute("i2cset -f -y 1 0x1a 0x05 0x0")

Will set it to zero - last parameter there is a hex value for volume. 0x70 is a good medium value.

0x7F might be the max value to try so os.execute("i2cset -f -y 1 0x1a 0x05 0x7F")

1 Like
#1487

is the docs page clear enough?

1 Like
#1488

I have tested this and it is working but where should I put the i2c id to have the actual hp control working ?

#1489

I don’t understand your question.

Would you clarify - Are you saying your headphone output is not working at all? Or that it’s working and the volume too low?

The headphone output level is controlled by the main “out” level on the MIX page. Turn that all the way up. (headphones and main outs are managed by the same control)

There is a Headphone Gain control in the Parameters (previously in the SYSTEM>AUDIO menu). This only works on norns hardware. This does nothing on Fates because it uses a different DAC.

If the main volume level is not enough you can manually change the headphone amplifcation level on the DAC with the command above - copy and paste that into the maiden REPL and run it.

#1490

Mix looks fine. All 6 levels at 100%, nothing on input shows in the VU when input is playing. Used the assembly youtube video (frame by frame) to check capacitor orientation, they’re all aligned to the correct polarity. Attached is a high res photo of the input area of the DAC after I spent this evening de-soldering, removing, reseating, and reflowing the connections for the input jacks.

IMG_9811
IMG_98113024×4032 1.73 MB

Another odd thing I just found: while there is still nothing when using arecord, when using aplay to play the blank file I’ve just recorded, if my source is still putting out sound, I can hear it (quietly) through my headphones. BUT the playback only lasts 15 seconds (as long as I recorded). To clarify, this 15 second chunk is definitely live sound, and the wav file is definitely empty.

Is there some audio firmware somewhere on my Pi4 that could be messed up?

#1491

My headphones work fine and I’ve also been using i2cset -f -y 1 0x1a 0x05 0x0 through ssh and works fine. I was asking about the menu volume control that once was on SYSTEM>AUDIO. I tried changing the address on matron/hardware/i2c.c and running ./waf but that didn’t work or I did something wrong. I couldn’t find any other place where hp volume is defined.

#1492

This won’t work on Fates. (Or I tired the same and never made it work so gave up). Different Codec chip - fates has an integrated hp driver and norns uses a separate hp driver.

#1493

No. This is likely a hardware issue.

In your picture the soldering could be better. Reflow. On the jacks add more solder to fill the holes. On those and the electrolytic caps, leave the iron in contact until the solder is obviously flowing then release. If the solder is not flowing well, your iron may be set too low.

I can’t look up up right now - was this an smd-assembled board or did you do the smd yourself? If the later, a pic of the codec chip would help to diagnose.

#1494

I understand that but I remember reading somewhere that a driver is not used in norns for controlling the hp driver just i2c. From the i2cset command you provided I get that the address is 5 on bus 26 so that would mean i2c-26 ?? I’ll research this more and make a small script if I find a solution, should be doable and would be really useful to me and I guess most of the people that feed the norns output to another machine while listening to fates headphones out.

1 Like
#1495

The current picture of my soldering is the third time. They’ve had much more significant connections before, to no avail. This was an SMD-assembled board.

What points should be in continuity? I can measure with a multimeter.

#1496

this is accurate. i dunno why changing the address wouldn’t just work (i don’t have a fates, do have norns and norns-shield.)

one thing i noticed:

the -f flag forces a write regardless of whether the device is busy or under kernel control. whereas in i2c.c we give up and print a warning. (do you get warnings in journalctl -u norns-matron? &c.)

2 Likes
#1497

Exactly as you said. Without the -f flag it reports the device is busy. So something should be unloaded or should be forced in i2c.c, slave_force wouldn’t work I guess since there is the check first. I will check journalctl after finishing work.

Update:

I2c is used by snd_soc_wm8731, if you blacklist this you can set the headphone volume without force flag. Obviously this is the dac’s driver so audio stops working when it’s unloaded . Possible solutions could be unloading driver and setting sound through i2c which is not optimal or rewriting i2c.c so it uses slave_force, then again 8731 driver may stop being able to control the chip. To me it seems that 8731 expects to be controlled through the driver and not through i2c when the driver is loaded.
I hope to figure this out but it’s much more complicated than originally expected.

#1498

Looking for a Fates user online right now to help with an update test/question.

Getting it sorted now

EDIT: update should get posted in a couple hours

2 Likes
#1499

@okyeron , what’s the process for updating a FATES now ?

I’ve not done it since the SYSTEM>UPDATE became broken,and I’d like to test on it before releasing a new version of sidekick.

(no rush for the actual update , as i see above, your working on it, more interested in the process)

#1500

The manual process is detailed here: https://github.com/fates-project/norns/releases/tag/2.3.1

Basically it’s getting the norns directory over to the fates-project repo. The manual update replaces the norns dirs so it’s pretty seamless from the update archive.

Looks like I had an error in my last update tho, so there’s going to be some extra steps for this new update (instructions coming below)

1 Like
#1501

ok, so once you have ‘manually updated it’ once - you then for future updates use system>update, since then that picks up your forked norns repo - k, that makes sense :slight_smile: