After reboot I can see a “missing Glut” error on the screen and in matron. I can still load mangl after that.
1 Like
fwiw, It happens with every script i’ve tried, not just the Glut based ones.
I’ve tried mapping a network drive every which way on windows 10 (using IP address, norns.local, etc) and can’t for the life of me get it working. SFTP and maiden still work, so I don’t think it’s a network issue.
Any troubleshooting tips for this webdav error?:
There was a problem connecting to the servcer “norns.local”
This file server will not allow any additional users to log on, Try to connect again later
I did the delete version.txt and re-update process once and no change.
Another possible issue - Maiden is sending the wifi network name and password in cleartext to the the REPL when you connect to the network. That’s less than ideal.
will look into it further, i’m sorry for the trouble
yep just reproduced. will get a fix.
haven’t seen that one. see ~/webdav/readme.md to dig in. i didn’t write the server.
it can probably be configured for ssl. not a huge worry if you’re on a private network. again, if you can look at the webdav guts and suggest a fix, i’d appreciate it
1 Like
I’ll check this. Doing a quick search, it could be a permissions thing (?).
be aware that you will need to allow www-data user to access that path by using linux permissions.
What’s dust permissions look like on norns hardware?
fixed the startup error. files updated. delete version.txt and re-update.
i apologize everyone for the quickfixes. it revealed some holes in my test procedure.
drwxr-xr-x 5 we we 4096 Nov 26 08:17 dust
4 Likes
Clarification - this is not webdav related. This is when adding a network on device via the wifi menu.
Probably could just remove the password txt here
After updating I am having this issue when looking at the status via maiden:
/home/we/norns/lua/core/midi.lua:405: attempt to call a nil value (field ‘menu_midi_event’)
stack traceback:
/home/we/norns/lua/core/midi.lua:405: in function </home/we/norns/lua/core/midi.lua:389>
Never saw that before. It keeps happening repeatedly.
this is a pretty minor vulnerability that would only present itself when changing from one network to another (which is pretty uncommon), i’ll comment it out anyway
can you clarify what you’re doing? how can i replicate this?
It occurred constantly (repeatedly) ever since I updated to 191126. I tried loading other scripts and disabling Wi-Fi but that didn’t seem to change anything. I decided to disconnect the powered USB hub, which finally made that message stop appearing.
Attached to that hub is a walnut 128 Grid, the latest Arc and a Mio MIDI interface. I’m assuming this has something to do with the MIDI interface, not the Grid or Arc.
Edit: Sorry, my hub isn’t very easy to get to - it is stored under the stand for my Grid & Arc, which is surrounded by others. Seriously limited desk space over here! I decided to check anyway (for science) and am able to confirm now that the error doesn’t appear after disconnecting the Mio. I don’t think the Mio is defective, so it may be something that changed with this update.
spotted to bug. fixing now.
2 Likes
That’s great!! I just wanted to add that I appreciate this update very much. These all appear to be some pretty exciting changes and I love seeing the wonderful progress being made all the time! 
Just wondering now, how do I change the overall grid intensity? Is it per script, or global? Is the option already available somewhere that I’m not seeing, or does it need to be coded into a given script?
Finally - the list of changes in the original post says “FIX wif menu indication”. That should read “wifi” I’m assuming?
1 Like
fixed. files updated again. thank you all for your patience and bug spotting.
grid intensity is per-grid, per-script. i’m planning to add a menu option for intensity and rotation.
in the meantime most scripts can have g:intensity(10) (or whatever brightness you prefer) added after g = grid.connect()
4 Likes
A bit more info after additional troubleshooting:
I am able to connect to the device using WebDAV via HTTP using Cyberduck, but the drive mapping in Windows file explorer still doesn’t work. In Cyberduck, it appears that both the IP address as well as using norns.local for the server name are functioning properly.
I am rolling through my network settings to see if anything else would be preventing me from mapping the drive.
FYI - my webdav problem was user error. 
Not enough 3’s! (was trying port 3333 instead of 33333)
1 Like
I wish it were that simple of a fix! 
1 Like
thanks for your patience— hoping i’ll figure this one out soon— it’s a little more fiddly then the norns software fixes up-thread (which were mostly typos on my part) 
does this help at all?
https://support.netdocuments.com/hc/en-us/articles/205212850-WebDAV-as-a-Mapped-Drive
1 Like
I did see this and tried a few things in regedit, and it doesn’t seem to make a difference. Are there others who have gotten WebDAV working on the Norns and Windows 10?