#21

Or: is this one of the weird cases where git remotes might be appropriate?

I’ve used braid in another project to manage versioned-but-frozen ‘vendored’ files, and that might be an option - or a similar system.

I will admit as a norns-outsider that the only way to install new things being either hacking your own things together or a full sync of the master, golden branch… feels a bit extreme. One person’s “totally fine, ready to use” is another person’s “experimental and semi-functioning”.

It’s fine to have your own clone of dust, running your own code in it, submitting PRs back to the main branch and rebasing against upstream. But it makes sharing with other users along the spokes without going through the hub challenging.

4 Likes
#22

Next…

Controller support

There’s no assumed interface, beyond that which ships with Norns hardware. Many scripts will require a monome grid, and many of those may require a newer varibright model. Presumably, someone whose grid doesn’t support that would be frustrated when nothing lights up on their grid. For example.

I’m designing something right now which might not make a lot of sense without a 256.

Someone else’s app may require RGB pads on some other controller.

I might build something for 1st gen arc, leveraging the pushbutton that hasn’t existed since.

I could build something specifically requiring Linnstrument. Or a specific TouchOSC template.

They’re all norns. None of it’s semi-functioning. And almost none of it works for you.

How do we want to handle that?

1 Like
#23

This seems relatively low friction. I could be convinced this would work.

1 Like
#24

(the other things this brings to mind is vim slowly moving from everybody’s huge, sprawling .vim folders to tools like Vundle and Pathogen.)

1 Like
#25

I agree that would work, but is undoubtedly more effort for the core developers (those with merge rights).

1 Like
#26

With a readme.md file?

#27

That gets at my concern. I want those folks to be frying bigger fish.

2 Likes
#28

Hmm. Are you pulling down individual scripts, or syncing the whole repository?

If it’s the former, cool. That makes sense.

If it’s the latter, am I not creating a mountain of annoying clutter for you to sift through with every update?

#29

I’m sorry, I’m not understanding what you mean by “mountain”. Yes you typically pull the entire repo.

Lua scripts are tiny. The readme.md file will tell me which ones I should be interested in.

#30

I guess my question is, is there a way to locally organize your files such that the scripts you are interested in are easy to find, remain up-to-date, and aren’t crowded by the scripts you’re not interested in? (Can you delete a file and have it stay gone? Or is it enough to re-evaluate your interest after every update?)

That’s probably more git ignorance than anything. And there may or may not ever be enough scripts for that to be a real problem. Just want to be sure it’s not an infrastructural landmine that has to be cleared up later, is all.

#31

Is the idea that user scripts will eventually end up in the main dust repository (where the four folders are currently)?

#32

That was my understanding.

For me, it is. But perhaps I’m overlooking something.

#33

There’s an open issue to look into this, some kind of tagging system definitely would make sense.

5 Likes
#34

i think the set up should encourage people sharing scripts. i would actually relax the rule that only finished scripts are added to the repo. we’re treating the inclusion as a way to filter, but i don’t think it’s the right mechanism for that.

what if at some point we have a 1000 “finished” scripts? certainly a good problem to have, however it’ll become unmanageable. some filtering capability would help with that so you could specify folders you’re only interested in.

we could introduce a tagging system (ha! synchronicity in action, as i’m typing this very sentence @markeats posts the above :))

tagging system could be used to mark WIP, scripts that are part of “official” distribution, scripts that use grids or specific engines. we could mark scripts that are ready but need testing, then people who are willing to help could search for those easily and tag them with “in testing”.

by default maiden could only show scripts tagged with “approved” or something like that, and then different tags could be shown as folders. same script could show up in multiple folders, like “uses grid” and “ready for testing”.

i do want to see people’s WIP. definitely i could just look at devs forks, but again, i think we should encourage making it easier. many devs, many forks, how would you find scripts that are ready for testing, for instance? also, this would facilitate collaborations. hit a problem? tag your scripts with “need help”.

this would require some system where certain “official” tags could only be added by the repo owners.

9 Likes
#35

Thank you. I have found those, the code. But where could I just download the specific files? And what if it had secondary files that need to be included? Is there an easy way to see?

#36

i should clarify. “semi-functioning” primarily means “broken” ie, doesn’t load, or crashes like crazy. i’m ok with WIP… there’s always more to do and change with scripts.

well you could create your own folder and move the stuff you want to use into that. git (and updates) won’t mess with folders it’s not tracking

3 Likes
#37

Currently dust is just a clone of https://github.com/monome/dust.
Since it’s git there’s nothing stopping anyone from screening/sshing into norns, adding your fork as a remote, checking out the branch they want to try and use that.

The obvious thing missing for this workflow is discoverability, though there’s always the overview of forks (https://github.com/monome/dust/network). One could also maybe post in this topic (I guess?) with a link to ones WIP scripts so others can try it out.
All of this is already possible and would be enough to at least get started using other people’s scripts without them being merged into dust.

Now I can image, especially for the less tech-savy users, that a more user friendly way of discovering and accessing other people’s WIP scripts might be helpful.
This also ties in with the fact that it might be useful to allow a more distributed means of sharing code compared to the single repo that we currently user.
For both of these points though there’s also a balance to be struck with regards to ease of use for the user, vs complexity of the code vs the quality of the scripts/ecosystem and the experience users have (random public code might breaking break stuff).
I guess we’ll just have to figure it out along the way :slight_smile:

1 Like
#38

Another nice example of lightweight package-management without putting everything into a distribution is the way the Arduino Library Manager - which essentially points at tagged releases on Github, and all the main team are merging is that specific repo/tag into a JSON file, to be published online, so your manager can pick them up.

As the list of scripts grows, surely choosing what’s on your Norns is a reasnoable part of ownership? It’s the gap between… I dunno, what in another language or platform I’d call the ‘standard library’ and something more extended including all community submissions ever… universe, to borrow a term from Linux.

Also: yes, I cannot believe I’m advocating package management this early.

5 Likes
#39

curious if anyone with experience could say a little about quarks?

#40

So I’ve been thinking about this a bit, and I think that it may be not too terribly crazy to pull in the latest state of dust (master) with maiden. An example user flow (with the technical details of what the api is doing thrown in)

  • User connects their norns to wifi
  • User accesses norns.local on their computer
  • (maiden makes a GET request to the API to find out if there are new commits to dust)
  • if there are new commits, something in the UI indicates “there are new updates to dust, click here to update”
  • user clicks causing POST request to be made to the API, which pulls in the latest changes, giving the user access to use these scripts in norns.

This api/git stuff could be some initial plumbing for publishing to dust within maiden which could be cool (but also a much bigger feature than the updating I’m proposing, as you’d have to manage user credentials and all that)

Note this is all about getting the latest stuff in dust. I think WIP stuff should be pull in through copy and paste/using gists as mentioned above. The path I’m thinking about here is making it easier to get access to is the stuff that is mostly working (which dust’s contrib guidelines ask for).

3 Likes