#41

for the curious (like me), some details are here. looks really nice. thanks for sharing!

1 Like
#42

I guess what I don’t understand is why it is so tied to github as a main source of user scripts? Again, I refer back to the patches section of the Critter and Guitari site. Users post patches there with ease, and it’s easily searchable. I could certainly see the files that actually affect the hardware (monomer/norns) staying on github of course, I’m only talking about user scripts. This would also be a good way of working out the WIP scripts.

I guess what I’m trying to say in an ineloquent way is I wonder if some of this is being over complicated for the less tech savvy folks. Again, the Organelle is a similar device, but I feel their way of sharing patches and WIP is incredibly user friendly from the start. people completely new to coding not only need to learn Norns, but they will need to learn how to use github before they can even start to dig into norns. I just fear that this might seem too daunting or intimidating to some. Not saying the scripts and such can’t live in monome/dust, but maybe if there was a non-github way of sharing patches, then the cream of the crop can eventually end up in monome /dust?

Just some thoughts. I do really love the potential I’m seeing!

9 Likes
#43

once we get upload/download working within maiden it should be drag-drop ease. i think this will solve what you’re looking for. then a script collection could just be forum thread, or if you want it searchable, a wiki. etc.

git allows us to collaborate with a lot of fantastic features.

but script browsing i agree it’s not ideal, so we could easily have a secondary approach.

12 Likes
#44

@Heath if I may, I think you are asking for the same kind of thing that the discussion is tending towards.

Git is a near-indispensable tool for synchronizing code changes with multiple contributors. It’s a low level transport and storage mechanism. Using GitHub to host the code doesn’t mean we can’t have other more user friendly interfaces.

Supercollider Quarks are built on top of git, and to answer the question I think the way they have been built out with a GUI is quite nice. It is easy to browse, install and remove Quarks arbitrarily from within the dev environment without any knowledge that it’s git under the hood, seems like a good model.

I don’t know anything about the C&G example But would not be surprised if they are also using HTML interfaces to the git api as is being proposed

… Actually looking I think you may be referring to patchstorage? Which is for more than organelle

5 Likes
#45

Wouldn’t it be cool to have a small git frontend in maiden. Add a github repo, install app, select tag/version.

2 Likes
#46

C&G do not use git, or a repo.
users primarily use Patchstorage, whilst C&G just provide individual patches on their website (and also a full set, and in the OS image)

Patchstorage is pretty good, and is generic, i.e. for PD, Bela etc,
its actually developed by the same developers as blokas.

GitHub, ive not checked, are you saying Norns already does a sync with GitHub?

Axoloti…
ive a bit of experience in this area as I implemented patch and object sharing for Axoloti, backed by GitHub.

generally this has worked pretty well for Axoloti…
we took a slightly different approach, in that we actually made the repo ‘open’, i.e we allowed users to become contributors to the repo, so as to reduce the ‘overhead’ which once you start getting (hopefully) lots of contributes can become onerous.
(also id not want some one having to get their own patches reviewed, feels way to bureaucratic to me)

the biggest potential issue with using git/GitHub, is the possibilities of creating merge conflicts - this is a non-issue for developers but for end users , its impossible.
for this reason we have a ‘reset all’ button in axoloti, to dump the current local repo, and re-clone it… you need an easy/full proof reset!

also , you need to potentially consider versioning
if a norns is on 1.5 the api might have changed, so should the scripts/libs be stored on branches? this unfortunately can create its own complications.

fundamentally for us, the difficultly has been… make it non-developer friendly, whilst retaining the benefits.

personally, id say its great for a curated set, but for more transient/flowing stuff, I don’t think its suitable… id go for Patchstorage its pretty good, and the developers are open to ideas on how to push it forward.

2 Likes
#47

:+1: that’s what I was getting at a bit above.

I think additional repo adding and branch/version selecting would be nice. As the minimal/initial version of the feature (and by default) doing this with monome/norns’ master branch would lead to zero-config for non-git savvy users.

definitely. In fact, I think some sort of interface to git reset --hard will be necessary for production norns https://github.com/monome/dust/issues/113

2 Likes
#48

It’s not git or patchstorage (although that is another resource). I’m mainly referring to here:

Another issue I already see happening is that topics are getting crossed throughout the Norns threads. I see see scripting help in dust, help questions in pretty much all of them, etc. if I had a lua script I know it should go to dust, but I could see how someone might add it to scripting or even development.

This is a side issue that I know will most likely work itself out as things get settled.

#49

Ah ok, sorry I misunderstood
So that just looks like a discourse category with all kinds of threads in it. Some with attached files and many that are questions or links

Do you mean you’d like a norns scripting cat on lines instead of just a few threads? Makes sense. Personally I have no opinion one way or the other.

#50

I do. my only concern is that there is already a lot of Norns specific categories already, including dust and scripting.

1 Like
#51

well those are threads. the suggestion to have a cat makes sense in one way. it would encourage more, smaller threads. i’ve noticed that a lot of lines activity is concentrated on a few big threads, it seems to be what happens here.

but part of it is decision to make those threads in the first place, which i agree seems a bit - ha, categorical.

right now, norns is a tag not a cat. means only mods can apply it. i dunno.

re: topic collision, mods have been active in moving things to right categories, but hard to keep up and also judgement call when to damage consistency of a given conversation for the sake of categorical coherence

i think that’s all i got to say about organization of norns threads on lines right now

2 Likes
#52

Just thought it was worth mentioning that the Aleph is the first option when choosing what patches you want when you arrive at Patchstorage.

I don’t know much about aleph, but from my experience with C&G Organelle patches it’s a great spot to keep track of the new hotness and keep the discussions here on the forum.

It’s generally a compressed zip (that can be uncompressed on the Organelle itself), but I’d presume we’d be limited by larger codebase changes needed to support some of the scripts norns is capable of. It’d be easy enough if you just had to add the following:

/username/newscript.lua /lib/newscript_support.lua

… but the overhead is higher when you need to walk an inexperienced user through SuperCollider this and peripheral that.

#53

I also tried to fix a few typos yesterday and since I’m not a collaborator on the repo, I got a permission denied error. Obviously not a big deal, but I’m sort of curious if there’s a funnel for being ‘accepted’ as a contributor?

#54

This is a permission denied when trying editing file directly on github?

The normal workflow is to fork the repository on github, make the changes in your fork (copy) and then open a pull request to get it merged into the main repository.

There are several people who have contributed to maiden already via this workflow and it is how I expect to work now that the repos are public (despite being one of the people who can currently modify/mess up the main monome repos if I’m not careful!)

The term collaborators on github does gives the impression of exclusivity but in reality it is little more than saying whether or not one has write access to a repository. It does not restrict contributions.

1 Like
#55

I’m wondering now if it was because it was copy from the website (/study-2), which might be on the monome repo itself and not into the norns repo directory. Which would make sense. And if so, oops!

I tried pushing changes for review as a new branch and to the master branch when that didn’t work, knowing that someone could reject or merge changes accordingly after I opened a pull request, but I got the error on the push, which means I couldn’t open a PR.

#56

It sounds like you were working directly off of a clone of the main monome repository instead of a fork (then clone). If you had fork'ed the repository first you should be fine. For example I’m not a collaborator on the monome/docs repository so I would have to fork it (which I did some time in the past), make changes in my fork, then open up a PR to get those changes merged back in.

…but this is getting off topic so I’ll stop here and we can pick it up in a different thread if need be.

1 Like
#57

Here’s a great thread!

#58

yeah, that was something unsanctioned i did in an effort to consolidate our efforts after enjoying the simplicity of the platform

at the time i had an organelle as well and seeing the ease of upload/search/download asked them to create a new category for .scn and .hex files used for aleph apps

since nobody knew about it (i felt a bit guilty promoting the idea without tehn’s knowledge)
and most aleph users are quite comfortable with github…there’s really nothing there

1 Like
#59

Continuing on what some others mentioned about “discoverability” of other users scripts…

I went searching at https://github.com/monome/dust/network/members but did not find that any of those forks had any “personal” folders or user scripts other than the regular distribution.

So… I guess I’m keen to see what others are working on - even if that’s not ready for primetime - so :+1: for some kinda of solution for finding/sharing scripts.

1 Like
#60

The forks view is a bit quicker/easier for that purpose since it’ll give you an overview of the branches people have created as well :slight_smile:

2 Likes