#41

with @okyeron’s link i did just get it to work on win10. you need to specify the IP and port ie http://192.168.0.111:33333 and check the extra boxes for “other credentials”

but doing regedit etc is not a great requirement for people. windows users i’d suggest continuing to use SFTP until there’s a solution worked out (though the regedit method works.)

2 Likes
#42

If I understand your question, this isn’t a per-LED compatibility fix. I think it’s just adding support for the global brightness value, which was all we had for variable brightness back in the day.

I leveraged that here:
https://vimeo.com/12192331
…but can’t think of other examples which made use of it dynamically.

(Which is weird. Bumping it as a metronome seems such an obvious use case.)

4 Likes
#43

this would be a handy to have I think I’ll look into it & PR : )

something like lvl = lvl < 8 ? 0 : 15 ?

2 Likes
#44

Yah! That would be awesome!

It would be a nice way to put my legacy grid to use if my vari-bright is in use with something else. If that function could be added to the norns functionality, like a simple way to globally account for a legacy grid, that would rock.

#45

there’s no way to account for all variations in how brightness is used in scripts but there might be something that’s better than the current situation

a better option could be easier tools for script authors to design for legacy rather than a global toggle

any particular script / use pattern that’s not useable on non-varibright rn ?

1 Like
#46

Hmm, that’s actually a good question. I think something like mlr would be one that comes to mind, since there isn’t a ton of layering with that one. But I don’t have anything else really in mind. I haven’t done too much with this legacy grid, just was thinking about it. I’ll give the other scripts a look.

#48

Also for maximum hardcore, I can confirm that Tramp Mode in Emacs works fine to edit Norns files transparently over SSH. WebDAV is welcome, but is there a reason to prefer it over SMB?

1 Like
#49

honestly I thought WebDAV was the new easy modern thing, but windows somewhat thwarted that initial optimism. so perhaps we will switch.

#50

Options are good. What works well on one platform might not on another. And sometimes it just amounts to preferences.

#51

why not both?

easy enough to install SAMBA.

sudo apt-get install samba samba-common-bin
sudo nano /etc/samba/smb.conf

ADD at bottom

wins support = yes

[norns]
 path=/home/we/dust
 browseable=Yes
 writeable=Yes
 only guest=no
 create mask=0777
 directory mask=0777
 public=no

then do

sudo smbpasswd -a we
sudo systemctl restart smbd

Then smbob’s yer uncle

4 Likes
#52

update (not going to start a new thread): just posted some fixes and nice vu improvement

191201

norns 2.2.4

  • FIX vu meters hugely improved @catfact
  • FIX clear screen before entering play mode
  • FIX several small typos that broke big things
14 Likes
#54

Everyone + dog seems to be doing SMB these days, and it seems pretty painless for *NIX machines and any number of NAS products, although I prefer AFP for historical reasons. WebDAV seems a bit out of favour, though I would guess it’s better for long-distance or transient connections. WebDAV is transactional at the file level, which might be an issue (pro or con).

#55

Diving into the library manager workflow (which is amazing!). A ton of the scripts that I try to update within that manager throw an error saying that they can’t be found in the catalog. Is this user error on my part?

1 Like
#56

I might be wrong, but I believe that the scripts that have been installed through SFTP prior to this update don’t have the necessary git files (since this system uses git files). If you’re cool with it, I’ve found the best way for me to correct this issues is to delete the script and then reinstalling using this web based client in maiden.

1 Like
#57

Ah, makes sense! Yep, that will work for me. Thanks!

#58

I might have found a bug with norns.enc.sens()

If you run a script that contains encoder sensitivity changes, then run another that does not. Rather than the default sensitivity, as I’d expect, the first scripts encoder sensitivity settings carry over to the second. @tehn, is this working as intended?

#59

bug. imo we should (re-)set sensitivity on script load.

2 Likes
#60

thanks for spotting this. absolutely sensitivity should get reset on new script init. i’ll throw in a fix now.

(working on the last bits for a new update)

4 Likes