I’ve used electrical tape on the underside of modular panels before. Not sure how your case goes together and if you’re able to easily cover that section.

A piece of plastic would probably work (like from a plastic file folder or something?).

1 Like

Sorry I hadn’t seen the message:(
I try to send you a file recorded on the fates these days as soon as I return from vacation. thank you for your availability

Grazie

Hello, Just wondered if someone could assist me…

I have a new Fates that is a few months old, I just went to system > update to load the latest version and it seemed to update OK. Upon rebooting it seems to have failed. I am not sure what the previous version installed was. Maiden no longer accessable.

Any help on how to revive it would be greatly appreciated! Noob mistake I’m sure…

RPi 3 or 4?
I seem to remember someone having this issue before.

You might have been on one of the older releases.
I’d suggest reflashing your SD card, Might want to backup your dust directory first.

1 Like

snow/stars on the display is a bit odd, but ¯_(ツ)_/¯

If the previous system was prior to 200218 the on-device UPDATE will have bricked the OS entirely and would require a re-flash from disk image.

I’ve posted numerous warnings and details about this here in the Fates thread and on Github.

See the GitHub pages for details on installing from disk image

1 Like

Back in action, thanks for the help.

I did some other tests and I attached the samples:

Samples.zip (2.5 MB)

This is the sample’s list

  • ORIGINAL_SAMPLE_VOLUME_LOW

  • Recording_from_tape_Volume_OK

As you can see, the sample recorded by TAPE is much louder in volume. The Rec IN and MONITOR settings in FATES are set to full scale (0db). My question is: Shouldn’t the volume be the same?

The original file is played by FATES on ableton live with peaks of around -6db.
Comparing the same file re-produced by Ableton (and not by FATES) the peaks are 0db.

Therefore the same file if re-played by FATES loses about 6 db compared to the file recorded via TAPE.

thanks

Using unbalanced cables can cut gain by about 6db i think. Does fates have balanced outs? Are you using TRS cables?

1 Like

it worked flawlessly w/o enclosure and the bottom plate seemed to have a gap already

i think the top plate was touching the screen contact points and causing interference

i attached some standoffs to the top and it seems ok now…will keep an eye out for issues

you could also run a line of electrical tape across the tops of the display pins (just in case)

1 Like

i’m now quite confused. does “recording from TAPE” mean that:

  • you played from some other device, into the Fates inputs,
  • enabled monitoring through norns mixer (stereo mode, one hopes),
  • used TAPE record function,
  • and that Recording_from_tape_volume_OK.wav is the resulting file?

and just to be clear, ORIGINAL_SAMPLE_VOLUME_LOW.wav is what?

  • the actual original sample?
  • capture of playback from TAPE into some other device?
  • something else?

so, in fact, the TAPE playback mechanism is not used at all here? or am i missing something?

(on another reading, i think you are actually describing the second case, but i could be mistaken.)

in Recording_from_tape..., the waveform is clearly being clipped at some point in the chain; not at 0dB as it would be if the clipping took place at the end of TAPE capture, but at -1.6 dB :

recording_from_tape_clipped

[Parsed_volumedetect_0 @ 0x55fbd6fd30c0] n_samples: 512512
[Parsed_volumedetect_0 @ 0x55fbd6fd30c0] mean_volume: -10.3 dB
[Parsed_volumedetect_0 @ 0x55fbd6fd30c0] max_volume: -1.3 dB
[Parsed_volumedetect_0 @ 0x55fbd6fd30c0] histogram_1db: 33277

whereas ORIGINAL_SAMPLE... is normalized to 0dB, but overall quieter and no sign of clipping:

original_sample_noclip

[Parsed_volumedetect_0 @ 0x55f20a90f0c0] n_samples: 360000
[Parsed_volumedetect_0 @ 0x55f20a90f0c0] mean_volume: -17.5 dB
[Parsed_volumedetect_0 @ 0x55f20a90f0c0] max_volume: 0.0 dB
[Parsed_volumedetect_0 @ 0x55f20a90f0c0] histogram_0db: 225
[Parsed_volumedetect_0 @ 0x55f20a90f0c0] histogram_1db: 358

assuming my description of the capture chain for the test recording is correct, i’d suspect the clipping to be in the ADC driver, and the way to address it might be to use alsamixer to change the soundcard capture levels (you can search this thread for more info if you’re unfamiliar with ALSA configuration tools.) that’s assuming you can’t, or don’t wish to change the level of the analog signal coming in to Fates.


also, this is obviously not the same file as the last one. that had a lot of sub-bass components that would clearly demonstrate phase cancellation (and it sounded kind of like that - sub-bass being quiet and distorted, with noisy transients poking through - but it’s hard for me to say for sure by listening to soundcloud.)

both experiments make me wonder if you are perhaps doing something with a balanced output from some device, and something odd with the wiring between that and the (unbalanced) Fates inputs. (in the first case: something like connecting negative / positive to L/R, and then recording with mono monitor mode. in the second case… i’m not sure. isolating parts of the audio that are “bassy”, it seems that low fequencies are more prominent in the “tape” audiofile, but the clipping makes it hard to be scientific about this.)

but i really don’t know. it seems like you are expecting that a given signal coming in to Fates, captured by Tape, should produce a file identical to the original. but this is of course dependent on the signal path between the playback device and the Fates ADC. you should be able to find some setting where a given voltage coming into Fates, captured to TAPE, and played back from TAPE, should produce the same voltage (given that it is below the electrical limit of 0dbV or so). but “calibrating” this will probably require a little tweaking of the audio capture levels; i’m not sure if @okyeron explicitly designed ADC/DAC circuits to be 1:1 “out of the box.”

if you still believe there is a software problem with TAPE (which i doubt), we need a clearer reproduction case. if the problem is elsewhere i’m not going to be able to help any further, but maybe others on this thread will. if you do want to follow up with me about a possible software issue, let’s do it by DM so that we don’t clog this thread any further.

3 Likes

i am using precisely these

https://www.thonk.co.uk/shop/floating-ring-cable-14m/

i don’t know about precisely this situation but i do not think it is good to use these “floating ring” cables. this could (i think) lead to phase cancellation issues because the inverted “floating” part of the signal doesn’t go anywhere. try some different cables and see if the problem persists.

1 Like

@atlas
@zebra

Thank you so much for all the interest and availability. I found the problem.

I used these cables that I usually used to direct DC Coupled signals from the sound card to the modular one and in fact on Thonk there is also a note about it
https://www.thonk.co.uk/shop/floating-ring-cable-14m/

Note due to the floating ring on the 1/4″ connector, using these cables to take a signal out of your modular and into the 1/4″ input of an external device will work but is not ideal. It depends on how the input is balanced or whether it auto-detects a signal as being balanced or unbalanced. This is often not documented with consumer devices. The signal is likely to be clean and audible, but may have some unpredictable side effects (inversion or attenuation etc).

Now I’m using these Doepfer Adapter Cable 6.3 / 3.5 mm to record from Ableton to Fates and there is no more volume loss. Thank you very much Ezra :slight_smile: I’m sorry for the time you spent on me.

Ciao (:

3 Likes

glad you got it figured out! one more experience in my toolbox of diagnosing audio problems.

1 Like

I’m reading through posts related to power supply with fates, and from what I can tell, a raspberry pi consumes about 1000mA at full load. I’m curious, and tempted to try, if anyone has connected their Fates using the pi3 to a USB power on their modular? I have an Intellijel TPS80W PSU, and a USB power jack connected to the 5V rail. The TPS80w supplies 1500mA, and I have 1300mA to spare.

Edit: I also see on the Raspberry Pi website that recommended PSU current capacity is 2.5A (for the 3 B+). I should also note that I often, but not always, will have a grid connected, and a basic keyboard as well. If memory serves me correctly, a grid can consume up to ~600mA? I think a keyboard will be negligible? The newhaven display max current draw (according to the documentation) is 375mA (on 3.3V). I’m not exactly sure how these all fit into the equation though.

You could try, but you’ll likely get undervoltage warnings* from the pi (red led will go off and on again).

* If the power supply to the Raspberry Pi drops below 4.63V (+/-5%)

I have various “2.5A rated” PSUs and many of them throw undervoltage warnings.

I suggest just using a quality well rated PSU.

Thanks @okyeron, I didn’t even think about the voltage regulation part.

I do have the 3A usb-c power supply that came with a Pi4 which is what I’ve been using on my pi3 Fates build. That has worked without issue. I’m just looking for ways to unplug another wall wart if able.

If 5V from my current modular PSU isn’t stable, I won’t pursue this further. I might try logging some data on that tonight to see how stable that is.

If it is stable, I’m curious if my amp draw will be a concern. I’m not sure if the 2.5A recommended PSU for the Pi 3 is to account for all the peripherals attached to it that could draw power, or if there is something like a high current draw when the device is turned on. But my first guess is, if I had no peripherals attached, and only Fates connected via USB to my modular PSU, that my peak amp draw would probably be under 1A. I suppose I could just plug in my fates with the usb-c PSU that came with my pi and measure the amp draw to find out. I’ll give that a go too.

Edit:
Saw this in the DIY Norns Shield thread. I think I’m just not gunna worry about using my modular PSU as a power source.

I’ve been having this weird encoder issue. Enc1+2 are bouncy when I max out stuff quick(like mixer levels) they bounce between levels. Is this a hardware issue? It started occurring, as far as I know, with the latest update.

It is a hardware issue as there is no debouncing on the encoders . I guess you started noticing it now because you have your fates for sometime and a bit of dust has accumulated in the encoder, without debouncing this would result in a jumpy encoder . You can try modding to caps there, check example.

download

6 Likes