#28

before joining this forum, I had no idea what github was or that I could possibly understand how folks edit a max patch to make music, lol…

2 Likes
#29

sweet! Please add me as well. user: courdek

#30

how did i miss this thread all week?

please add zunaito

#31

edit: forget about it, no need to add me.

#32

I think the repo is public, so you should all be able to view, clone, and fork it. Once you do that you can add your scripts and we can merge them back in.

I don’t think we need to explicitly add everyone to the Monome group, or do we @tehn? I’m not that familiar with how groups work.

#33

me neither

just throwing my name in there in case it’s necessary

#34

Great, I threw in the first pull request.

I have two commits on my fork:
-All factory docs and default scenes. TT Studies is preset as a PDF, but not yet available as .txt files.
-All files found through searching for “.txt” here. There are many more TT scenes available here, but I thought I would start with the ones that were already formatted.

3 Likes
#35

Thanks for doing that! It is now merged and ready for anyone who wants it.

#36

i’ve been thinking that the codex could be used not just for scenes/scripts but also some related documentation which can be as simple as a short description or a breakdown of a scene or a complete study or anything in between. and such documentation can be a work in progress, i think it would encourage people to add more scripts and document them as their time allows.

how should we document? a corresponding readme file for each scene? or should we use the github wiki? with wiki you have the benefit of using markdown, and it would be easier to link things. it would also be nice to have a central starting point which would list all of documented scenes, categorized. this could become an extension to the official studies and perhaps we could link to it from there.

3 Likes
#37

The wiki is great for more general info and documentation. For scene specific docs I would tend to use a readme in the scene dir. GitHub supports markdown for readme, just call it readme.md and it will be displayed under the file listing.

I’m up for experimenting with it until we hit on something and fills the need.

2 Likes
#38

As a relatively new Teletype adopter, I would definitely like to encourage a wider sharing of scenes. If this helps (and it seems like it would), then I’m all in.

1 Like
NOTE teletype op
#39

While I think your proposal has a lot of merit in its own right, I think the main issue with a lack of sharing is a human problem. I suspect that the barrier is threefold (at least)

  • Technical know-how required to commit to git. I think this is easily solved, but having a few people who could commit on behalf of those who can write TT scripts, but don’t want to learn how to use git. I’m happy to help in that regard.
  • Fear of looking like a novice. I think this is likely less of a concern in this forum than elsewhere, but probably still some part of the issue.
  • Personal high standards. along the lines of “this isn’t good enough to share”, or “my script isn’t finished yet, I’ll share it later” (and it’s never “finished”). As can be seen in the various TT threads, there’s huge value in sharing even small snippets of code. Could this be addressed by adding a part of the repo for snippets?
6 Likes
Github Basics
#40

I think this is a wonderful idea.
reusability is indeed a concern (no fun to port a scene to address a different module after squeezing logic into the available script space). this alone makes it worthwhile imo.

full support!

re:

valid point. would be nice to have a non-coder friendlier layer on top of it. gihub itself does that… but

image
image.png1089×358 23.8 KB

no easy solution without losing repo control I guess.
but I digress.

1 Like
#41

Fork & pull request would be the common practice I’m assuming.

#42

yeah that’s what I meant with

1 Like
#43

As someone who has been meaning on sharing a scene or two for the past month or so, I can chime in on the main reason I haven’t yet, and it is much more practical than you guys are thinking.

When I’m playing modular I’m not at my computer, and I don’t want to be. And when I’m at a computer, I’m often at work, and far away from my modular. I’m also slightly afraid of writing scenes to a thumb drive, as it’s very easy to accidentally overwrite all your scenes on the module (I’ve done this numerous times before, usually during a firmware update :frowning_face: ).

EDIT: So I guess what I’m suggesting is a web browser interface, maybe? Some way to write / verify scenes while I’m away from the modular would be amazing

7 Likes
#44

My Scenes are so convoluted and specialized to my own setup that I can barely keep track of how they work myself, let alone think that they would be interesting for others to try.

The other issue is that currently I’m building a suite of tracks that I can improvise around and perform live, then ultimately produces and release, so there’s a selfish intellectual property component too.

That said, I’m not opposed to sharing Scences, and think it’s a good idea especially for areas like Grid Ops, where you could design a functional starting point.

2 Likes
#45

Good point, usb saving/restoring definitely needs improvement.
Not sure if a scene syntax validator is worth the hassle… still can’t really test the scene. but might be a fun project. though I fear my employer will be less pleased :slight_smile:

2 Likes
#46

I admit to thinking of TT scenes/logic while at work wishing I could jot the ideas down in jupyter or a similar repl.

#47

We could at least test that gates are firing / cv is outputting something reasonable. Could be very useful for debugging complicated scenes

though I fear my employer will be less pleased

100% agreed haha