#89

The one and only time I will update (for the time being) is when I see an official release here. There are too many moving parts otherwise, and I do not have the time to become expert at judging how they all play together.

Thank you to all of you who make this platform all it can be.

2 Likes
#90

I can relate to this. But I’m getting the feeling from what @zebra said that PRs aren’t getting merged unless they’re non-breaking, so I’m feeling like I can play on the bleeding edge without obsessively tracking everything, because it sounds as though efforts are being made to keep the edge from getting too bloody. So, I’ll live dangerously until I regret it. And then I’ll roll back to an official release and adopt your strategy, which is totally valid and understandable.

1 Like
#91

i first want to apologize that project management has been one of my failures since release— the workload has been impressive and i was unsuccessful at quick assessment and delegation. i aim to remedy this immediately and delegate where i can’t keep up.

on the structural things as of now: master should always be stable. perhaps after some discussion we’ll consider using a dev branch, making pushes to master less often.

what’s most important is that the process is easy and encourages collaboration. (and of course, not seeing a mess encourages collaboration as well).

re: multiple repos. maiden should be able to stay on its own repo as there shouldn’t be breaking changes with norns.

dust however is not an ideal situation. we put together some proposals for having dust be libraries fundamentally (in which case these should possibly be just rolled into norns) and establishing a different method for sharing/updating user scripts (such as those currently in dust). i’ll type up this proposal in a git issue— it basically is a “project” structure where a script also can include data files (text/audio) and have a standard folder arrangement for presets/etc.

thanks for all of your patience while we gather momentum

15 Likes
#92

This sounds like a great idea for managing scripts/projects. One model that has worked well for me is how Node.js handles libraries. A library has a set structure, but resides it its own git repository (not linked to any core Node repo). There is a package manager that allows you to add libraries from a main library registry, or just add them from a git URL (or you can just put your own files in the right place).

In this way you can install whichever ones you want, remove them any time, and easily make your own that are distributed or private.

1 Like
#93

Agreed. nnnnnnnpm install thepartyvan#v0.1.1

2 Likes
#95

Anyone familiar with the text editor by github, Atom?

While I admit when I first started to think about my ideal interface to browse & install community provided scripts, I thought about command line interfaces (thinking Vundle for Vim specifically), reading this thread got me thinking more about a happy medium: something that would allow those of us who are not comfortable with CLIs to take advantage of the breadth of scripts made by the community without necessarily needing to ssh into norns itself… but something similarly that is more granular and allows a greater degree of individual user control than getting all the scripts all the time.

(Maybe it’s because I’m easily distracted? But the more loaded with functionality that I didn’t add a tool is the more likely I’ll just reach for something else in the first place.)

Atom has an awesome UI for managing packages. I wonder if we could add something similar to Maiden, but still fundamentally take advantage of git / github under the hood?

This is something I’d be interested in helping out with, if there was community consensus.

Either way, I will keep an eye out for the impending github-issue-proposal @tehn mentions above so as to contribute / follow along with the convo there.

2 Likes
#96

I had a parallel thought: that you could put a git repo or tarball URL into maiden and have it download and place the corresponding script somewhere logical, and have a button that lets you ‘refresh’ that script (by git pull or re-downloading the tarball if it’s changed), so sharing a script becomes a matter of sharing a URL and providing a new version of a script is just updating the content at that URL.

2 Likes
#97

Exactly. And, if we provided some sort of registration mechanism—this could even be just a list stored & updated in the Maiden repo that pointed to repos on GitHub that adhere to the package structure—we could provide a UI that prevented the end user from having to provide the URL.

#98

this is kind of what the Bela Web IDE does.
(Bela IDE is very similar to maiden really, allows running/compiling of ‘patches’ , editing, changes of preferences - and even an oscilloscope - could be a good source inspiration for Maiden)

each bela project is on the Bela board, and it can optionally be ‘backed’ by a GitHub repo, and it provides the primary git functions , like init/push/pull…

this works well, it opens up and additional workflow (compared to editing in the ide), where you can edit things in your favourite editor on your desktop/laptop, push them via git, and just pull/sync from the ide.
(they even have a script where, it detects files changing on the board, and then automatically recompiles, re-runs the patch)

im not sure that a ‘project’ per norn script is the right model,
as i said before, i think, better would be a list of sources for scripts.
so you could have dust as one, and another for your ‘private’ repo, and say another you are sharing with a friend as a collab.

git works well for this (although easily argued its a bit too ‘developer oriented’)

a package system (like deb, npm etc) is useful , if you start having dependencies between script packages… (e.g. mymlr:0.2 depends on dust:0.6) - this will happen if users start sharing libs/frameworks, and others build on them. then a package system is imperative… and you also need to support having multiple versions of packages installed (to avoid breakages)
… that all seems like a pretty big step from where norns is at the moment, but perhaps should be a goal?!

2 Likes
#99

i’m hesitant to take on creating a full-blown package manager for norns at this point.

but leveraging git more effectively seems like the best path, in addition to the ability to drop-in scripts from other sources.

also remember, while it’s not perfectly elegant, it’s possible to just copy a script (off lines or a gist etc) and then paste it into maiden and push run. of course this doesn’t work for engines at this point.

here’s the current thinking for the UI redesign, but i need to update it with further thoughts. comments highly welcomed as this is a pretty imperative user collaboration issue: https://github.com/monome/norns/issues/446

4 Likes
#100

fwiw @tehn I am not advocating a full-blown package manager, but I think we could gain a lot by providing a UI for managing what scripts are installed, and I think we could get some big gains with a relatively small amount of overhead.

I’ll put together a more thorough proposal as a github issue in maiden to discuss.

3 Likes
#101

@robbbiecloset this existing issue seems relevant.

#102

Definitely related, thanks @jasonw22.

EDIT: I think the difference between it & what I’m thinking is that this still assumes that all scripts exist within the dust repo, while I’m thinking more about a mechanism that would avoid this (while still allowing for updates of installed scripts via the maiden UI).

1 Like
#103

Here is an issue over on github. As I mention over there, totally happy to be told that we should move in a different direction, just happy to contribute to the discussion :grin:

3 Likes
#105

I commented on your proposal @robbbiecloset. Cool ideas there!

I wanted to bring up in here, that as I use norns more I am now feeling like treating the state of dust as a 1:1 mapping of the library stored on norns that something like my naive idea that is basically a button to do git fetch && git reset would not really map to how I want to use norns.

I want to follow along (and explore) when people like @dan_derks @martinmestres work through super cool scripts in gists and the review thread. I want to grab stuff like the experiments @jflee is doing on remixing scripts to work with different engines. (and I’m pinging y’all to see what ways y’all would like to (or to not) share these things for others to download before they are “dust-ready”)

EDIT: also, once you do it once, the SFTP path and manually adding stuff to the file system really is not that terrible of a way to grab scripts.

1 Like
#106

script project management is high on our list for the next update, so we’ll be discussing it here more in the near future.

on that note, if anyone could spare a few minutes and make a norns-SFTP howto (in markdown with a screenshot or two) it’d be great to add this to the docs. (i’ll get there after the next study otherwise!)

6 Likes
#107

How does everyone feel about starting a community sample library? I’ve got some samples that I think work well with scripts that I’d be happy to share, and maybe others feel the same. They could live within the audio/common directory or perhaps in it’s own directory. Of course filling up disk space is a concern, so the samples would have to be well curated.

8 Likes
#108

Apologies if this has been covered already, but what’s the protocol for adding features to existing scripts? Should we contact the original author to make sure they approve of the change before opening a PR?

Also, I noticed only a couple scripts list “enhancements” under “issues” in the repo. Maybe it would encourage more collaboration if people got in the habit of listing desired features for individual scripts there?

I just received my Norns last week and I thought a nice way to learn it would be to update some of the existing scripts, but I don’t want to step on anyones toes if they’re working on that same script concurrently, and also wouldn’t want to add something to a script if the original author doesn’t like the change.

2 Likes
#109

I’ve largely asked people on here - in threads or in private. People are pretty cool - certainly I’ve interacted with a lot of the people with scripts on the Norns right now and everyone has been lovely. I suspect given the nature of lines it will stay that way.

None of my stuff is on there yet (but soon - Kria port is well underway as part of Islands and I’m hoping to have the standalone midi version in PR next week - and maybe even Islands released too) and certainly I’ll be more than open to changes - probably prefer to talk first just because like you say - don’t want to be doing duplicate/conflicting work

1 Like
#110

Personally speaking, I think making changes to an existing script should probably happen in the form of a github PR. I wouldn’t mind seeing a random PR notification, but it would also be nice to know it’s coming, that way I could potentially share some guidance to my script.

If your changes are substantial enough to warrent it being called something different, that’s fine too. I see it in lot’s of open-source environment (and it’s sort of the whole point that we build off of each other). It’s probably best practice to credit the original in your documentation. Even if an author doesn’t like the fact that you’re using/editing their code (unlikely), they don’t really have reasonable means for complaint as it exists in an open-source environment.

I definitely agree with this.

1 Like