#1270

Don’t do this :wink:
The dust repo is no longer used.
/home/we/dust is just a directory containing data, audio and code directories :slight_smile:

1 Like
#1271

Sorry if this is a noob question, but how is the perfect way to update scripts? Deleting the old one and uploading a new one via SFTP?
And how do I know which version of the script is already installed? This seems tricky…
thanks everyone!

1 Like
Norns 2.0.0
#1272

I just did the same, and would also love to know how to get back to a fresh Norns

1 Like
#1273

I am in a similar situation, since updating to 190405 my dust folders have come a mess. Not sure if there is a quick solution for this

22%20PM
Screen Shot 2019-04-19 at 10.14.22 PM.png1214×1038 193 KB

#1274

reset ~/dust manually

  • make backup copies of ~/dust, especially ~/dust/audio and ~/dust/data
  • delete the whole ~/dust folder
  • create ~/dust, ~/dust/audio, ~/dust/data, ~/dust/code
  • download we
  • move/copy we-master/ to ~/dust/code/we/ (<- rename important)
  • put other stuff (scripts) in ~/dust/code/THING
3 Likes
#1275

@Minimum @ptbarnum @riggar

Here’s what I do.

I keep 190405.tgz in my update folder on Norns and I don’t delete it. Because, I like to mess with stuff and I’ve been trying to teach myself Lua and it’s not an overnight thing at all haha. Also, I think the librarian script broke my Norns (duplicate engines? bad naming conventions? something…) so I stopped using it and things have been awesome again.

So since 190405 is already on my Norns, I actually use terminus on my iPad to login to norns via ssh, but you could also use terminal. Once you’ve logged in, simply navigate to the update folder by doing the following (I updated tehn’s comment):

(And if you’ve done this before, simply navigate to /update and just run the last line.)

…and don’t forget

sudo shutdown now

This update style makes a backup of your old dust and you can drag your audio back in for samples & tapes.

1 Like
#1276

I just followed @zebra instructions however my norns will no longer shut down on its own when I sleep and it appears that none of the scripts/engines are working although the WE master file is in code

01%20PM
Screen Shot 2019-04-19 at 10.55.01 PM.png1204×1032 135 KB

#1277

Should be lowercase ‘d’ in ‘dust’ and just ‘we’ not ‘we-master’. It’s important to match those paths exactly to zebra’s post.

1 Like
#1278

thank you that does appear to be the issue

2 Likes
#1279

So after updating to 2.0 and then uploading a few new scripts into the code folder over ssh, every single script became stuck on the ‘loading’ screen. After getting out of the frozen state and then deleting every newly added script I finally was able to load one of the pre-installed scripts. Is this just a case of a duplicated engine somewhere or did I install a script incorrectly?

#1280

Usually this is because of a duplicate engine. If it happens again, try to watch Maiden’s output (bottom-right, the “sc” tab) and that will help you identify the problem.

1 Like
#1281

Most of the time when scripts don’t work for me, I can fix them by either deleting the folder and re-adding it, or renaming the folder removing “master”.

3 Likes
#1282

And in this case, do I need to delete the duplicated engine out of the newly copied code?

#1283

yes i’m not sure on the ‘perfect’ way …:crazy_face:

#1284

You need to delete the engine (ending in .sc) which is not referenced by the script you want to use. It’s probably an engine that’s still present in /we/lib and is also contained in the /lib folder of the script you downloaded, if I understand correctly.

1 Like
#1285

Thank you! Much appreciated

#1287

There is a known situation where this can happen immediately after running the update.

The first thing to try is shutting down (sleep) and restarting your norns

If the problem persists, look for duplicate engines.

1 Like
#1288

Is there a general rule that script folders shouldn’t have ‘- master’ after the name? And if this is the case, why have 75% of those I’ve downloaded been named like that? Just wondering…

#1289

It’s likely a default with the way github creates the zip file when there’s more than one branch in the repo.

#1290

Aha. So I should re-name them all?