nmtui did not work from my work computer but I just got it all working at home. thanks @tehn (and everyone else who offered solutions)!
swapped out to a stronger wifi dongle and that still wasn’t working via norns wifi menu so it appears the serial connection + nmtui is the way to fix if anyone has that issue in the meantime.
I updated my script for 2.0 and tested. now called uhf.
Upgraded my unit. Required an audio reset after the initial reboot. Played some noodly piano improv into MLR and then Awake for a few hours. All is good. I’ll port FM7 to new API this weekend.
i’m still seeing pretty consistent noise on encoders 2 & 3
does tape record the inputs in 2.0?
I was testing other wifi dongles today and noticed this behavior as well. Hopefully it is simply a bug in the UI and not something deeper. In my case restarting matron fixed it as well so it is likely not a system level problem.
…on the TODO pile it goes.
What do you mean with noise?
For my personal use I have adapted Kayan by @burn (here) and Rebound by @enneff (here) for Norns 2.0 but since I don’t know how’s the correct way to share them I have put them in temporary gists if someone on the beta wants to try them.
I’ve noticed some timing hiccups while I was running Awake and it was connecting to wifi (not sure it’s related). CPU use was between 7 and 19%.
Anyone else noticed anything similar?
the anti-noise algorithm is in this build, but some encoders still might need replacing. email info@monome.org
Yeah I noticed this too. Have not checked it out again since wifi issues were fixed
But as soon as you move away from the WiFi connect page timing returns to normal.
Same exact thing–assuming this is due to hotspot being broken in the beta? It wasn’t entirely clear what I was supposed to do, so I am restarting with fingers crossed heh
EDIT: seems I’m on 190303 now after restart!
Yes - that would be expected. The menu UI and the running script are in the same lua interpreter. UI like the WIFI page which periodically runs system commands to update status and signal strength will cause timing jitter. Simply navigating away from the WIFI UI and timing should be okay.
Running into some odd things with the recordings created with tape.
First off, my usual FTP gui client, Fetch, did not seem to have an easy time getting the recordings. They were named 0000.aiff and 0001.aiff. In Fetch, they showed as 18-11-17_05-05.aif and 18-11-22_05-39.aif.
I switched to Filezilla and was able to get to them with the expected filename.
Once I downloaded them, I tried playing them and they don’t seem to open in using quicktime player, but will sort of play with mac finder preview. Quicktime says ‘The movie could not be opened. The end of the file was reached’. It opens in Audacity and seems to be read as a 48k project, 32-bit float, so maybe that’s part of the problem?
Here’s what the waveform looks like - you can see it completely go into white noise around 40 seconds:
The second, later recording is only white noise.
If needed, I can provide the files themselves. I was using the compressor and the reverb while recording the output of MLR. I see also that @AlessandroBonino and @rdfm ran into a similar similar issue.
Anybody else not getting any sound out of Awake?
If this happens to anyone else before the next update - just change the file extension to .wav
Looks like the file extension is being set wrong and this will get fixed.
pushed a fix to norns for the TAPE file extension, though that won’t fix the noise problem.
connecting to wifi (even going into the menu) will hiccup the lua environment, yes. any metros in a user script will pile up and get delayed. we need to look into doing os-level interaction in a coroutine (or something) to prevent this.
fixed this, you’ll need to pull the update
Confirming that it is fixed for me and both channels work for recording.
when you say pull the update, do you mean build or download from github? (trying to figure out if keeping up with the “latest” beta will be put on the first post in this thread, or on there)
