#85

sorry yes, didn’t mean to disparage (it is very important). just that i am going to step out of the conversation now. i’d be happy to support whatever contribution flow, but realistically am not going to be in charge of maintaining it.

2 Likes
#86

week-long trip ending, i apologize for my absence. many many posts coming tomorrow morning during the plane flight home.

10 Likes
#87

@jasonw22 It’s nothing scary :slight_smile:
Basically master of both repos should be stable and they should be updated in tandem. These updates can be done in larger increments (the releases that have been made so far) or in small increments by using git directly. The latter is effectively the same as how rolling release distro’s work (you update in small increments, but you do always update everything).

One thing we could consider is adding an option to the UI to update both repos through git to make it easier to get the current code.
There might be some technical challenges though like what to do with the running code if it changes.

2 Likes
#88

Some git shortcuts in maiden would certainly be helpful to those less familiar with git (and handy for those moments when you aren’t in a command line mood).

@simonvanderveldt I’m really quite experienced with software development, but not everybody here is. I try not to make assumptions about what people do or don’t know. Having spent a while hanging around the monome community, I know things can at times get quite messy, and that can become a frightening situation for the less confident. I wanted to understand what measures were being taken to allow people to feel safe to experiment, but also confident in the idea that their musical instrument will continue to function. I’m good now!

2 Likes
#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