#1

norns: ecosystem

(a thread to discuss the present and future of script / engine sharing and co-development)

related topics:

today

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.

discuss!

13 Likes
#2

I think this is a great idea

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).

1 Like
#3

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)

3 Likes
Approaching: norns
#4

I thought the idea was to do pull requests against https://github.com/monome/dust/tree/master/scripts

Active dev should happen in your own local branch. When it’s performance ready, do a PR against dust.

2 Likes
#5

That makes more sense.

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.

1 Like
#6

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!

#7

From the dust readme:

do not submit semi-functioning works-in-progress.

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.

3 Likes
#8

That folder I linked to contains folders named after users. Each user folder contains Lua scripts.

The git tutorials linked earlier in the GitHub Basics thread are a great place to start.

#9

Please don’t. Or do it out of band if you must.

#10

i actually came into this thinking it was really important to be able to do just this. curious why you think otherwise?

2 Likes
#11

That feels a bit brusque to me.

What low friction out of band method do you suggest?

2 Likes
#12

Gist is really nice. Post a link to a gist.

2 Likes
#13

Beat me to it!! https://gist.github.com/ is the perfect tool for snippets of code, or partially worked examples etc.

2 Likes
#14

But then I’d have to ask users to constantly paste in a main Lua script, an SC engine, and X many library files.

I can understand why you wouldn’t want WIP code in the dust repo, but why not another method as I suggested?

1 Like
#15

If there is sufficient motivation to invest the dev time to enable this, by all means.

#16

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.

#17

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?

Besides, when is a script ever “finished”?

1 Like
#18

A pull request can contain changes to multiple files:

#19

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.

hope this helps?

1 Like
#20

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.