#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

#48

Agreed. NOTE would be a convenience – as would a GATE with a specific length that doesn’t also issue a pitch CV, instead of separate commands to turn the output on, delay and turn it off.

But I’m not sure it would encourage much more code sharing:

  • I was unaware there even was such a repsitory for the TT community, so of course I didn’t use it :slight_smile:

  • I’ve never really learned git, but then I haven’t been very motivated. In my career I’ve used Perforce, SourceSafe, SVN (briefly), TFS, and proprietary source control, but there was always someone else at the company who managed it and instructed people in its basic use.

  • Most of my scenes and scripts tend to be one-offs for their particular song. There isn’t much reusability even for myself. I take mental or actual notes about particular techniques, very short code snippets etc. but I tend not to even save scenes. The couple of them I’ve written, I haven’t really put to use but acted more as a learning exercie/puzzle.

  • I may be vastly underusing TT in general, but mostly it’s serving me as an algorithmic gate/trigger processor with occasoinal modulation CV. I find it really easy to use for that purpose and don’t really have to think much about implementation.

1 Like
#49

it’s interesting to hear various reasons on why scene sharing is not more common. i do think a big part of it is perhaps scenes being too big of a block to share (as they can be very specific or aimed at very personal goals). working with grid ops however i think there is definitely a room for more general “preset” style scenes (and we have a precedent in the scenes that are included in official releases by default), as grid scenes tend to act more like standalone “apps” (which makes them closer to norns approach).

it’s not all about full scenes though, i think having a library of code snippets is a great idea! there are many tips and tricks in various teletype threads, it’d be nice to capture them somehow.

agreed that git can definitely make it not user friendly for people not familiar with the workflow. perhaps we could have teletype codex curators that could be responsible for adding content to the repository, and could also help others with git (or just add on their behalf)? (i’m sorta being such a curator for grid scenes, and i definitely plan on documenting/posting/sharing more grid scenes once 2.3 is out).

it would definitely be great to have a web-based editor which would allow building your scripts online / validating (maybe even running some basic simulation as suggested) / posting them to the repository / pulling scenes or snippets from the repository. it’ll be interesting to see norns approach. if somebody could take this on it’d be totally awesome. or imagine if there is a vcvrack version of teletype (pinging @dewb :)) that is capable of connecting to the library, so you could edit / post and try it right away?

9 Likes
#50

I’d be happy to help manage getting things into the Codex git repository.

1 Like