script and engine sources live in the dust git repository. on update, norns gets the latest dust but in the meantime a bunch of exciting work is happening on personal forks of that repo. exploring experiments or works in progress involves cloning someone’s fork or manually adding required files (minimally a lua script but if there are supporting libraries or a new .sc engine it could be more; if changes have been made to shared libraries, it’s even trickier; in extreme cases, scripts and engines may depend on changes to norns itself).
over time, some scripts will make their way into the upstream dust repository and everyone will enjoy them on norns update but some likely won’t or will remain in a state of experimentation or flux.
the future
the current model of a centralized repo has the advantage of being simple and encouraging collaboration on a shared set of resources. the ecosystem is very young though and there’s lots to fill out.
My ideas were a subsection of the dust github or a category of lines similar to the patches section of the Critter and Guitari forum. (Github might make more sense).
I don’t know how scripts are added and organized on the device itself yet, so this may not be a real concern, but…
It may be wise to create separate folders for scripts that are performance-ready vs those still in active development, seeking collaborative input before they can be completed, etc.
(a user seeking one might not be interested in wading through the other)
My method for this stuff has, historically, been “post random bits of code to the various forums, and hope I can still find them later.” So, I’ve obviously got a learning curve ahead. =)
And, hey! Look what just materialized before me! That’ll be useful.
I see the pull request section and that there is one there, but I feel like a complete beginner because I can’t even find the lua file. I just see the raw script. Is this how pull requests work? Please forgive my naïveté with Github!
I saw this and thought… how does someone distribute their semi-functioning works-in-progress then?
I think I would like to see some sort of ‘channels’ system, for people to subscribe to my WIP scripts (or if one doesn’t particularly feel like contributing to dust).
I can’t recall the UI for maiden, but maybe each channel can show up as a separate entity on the left hand side.
As for distributing a channel, just use git? Maybe with a directory repo like Supercollider’s Quarks. Maiden would need some UI for updating channels (via git pull -f).
Now, the actually mechanism of how the Lua and SC code in these channels interacts with the code in the dust repo is a more complex issue. The simplest idea I have is that the channels act like a filesystem overlay over the dust repo. My ideal solution would be something more ambitious whereby the dust repo is just another channel, but that would require some serious thought about how libraries are dealt with.
Yes, I noticed that. But those are also the main folders that shipped with Norns. There have been several user scripts shared/created since. I see the one that’s on a pull request, but don’t see the actual file.
Is there anything wrong with, say, a WIP branch of dust? If a branch is too confusing, perhaps a “WIP” folder?
That way, people who are using their Norns in non-critical situations (me!) can pull that branch (or open that folder) and provide feedback + contribute code to works-in-progress?
So (and apols if this is teaching you to suck eggs!) the pull request is a request to merge a set of changes from one repository to another. The request will contain a set of changes, not necessarily entire files. So for example, if you go to the dust repositry:
you can click on the “Pull Requests” link to get to a list of the pull requests.
Right now, there’s just one. Clicking on that takes you to the discussion:
And on that page you can see a link to see the files changed:
In this instance, there are two new files, so all of the lines are indicated as additions by the “+” at the start of the line. But if it was a set of changes, you might see lines removed “-”, these lines are highlighted in red rather than green.
You can always improve a thing, but there is a point at which it works to a degree that expectations of some specific functions can be set, and those expectations are largely met by the implementation without frequent errors.