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.
Thanks for doing that! It is now merged and ready for anyone who wants it.
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.
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.
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.
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?
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.
valid point. would be nice to have a non-coder friendlier layer on top of it. gihub itself does that… but
no easy solution without losing repo control I guess.
but I digress.
Fork & pull request would be the common practice I’m assuming.
yeah that’s what I meant with
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 ).
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
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.
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
I admit to thinking of TT scenes/logic while at work wishing I could jot the ideas down in jupyter or a similar repl.
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
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
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.
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?
I’d be happy to help manage getting things into the Codex git repository.
For me there are mainly two reasons I do not share any scenes (as I word it I feel a bit bad about it, but it is like it is…)
One reason indeed is that I hardly manage to find and download anything from github. I tried to understand how it works and what it is good for but did not grasp in the end and so simply avoid it.
The second reason is that I got a bit lost on which tt firmwares do exist and what the most common stable one is at a given moment. Same with Ansible (plus the lack of backup opportunities there). So I expect shared tt scenes to be probably using a firmware, operators or abbreviations I am not familiar with. It’s a bit of a shame but I think the entry level is just too high for me. Also the monome development seems to be more oriented towards new visions and less towards maintaining a balanced ecosystem and bugfixes. This frustrates me and I don’t want to be and act frustrated. So I am writing small scenes as I need them, try things out and just don’t follow the evolution anymore very active.
the latest official releases are listed here: https://monome.org/docs/modular/update/. alternatively (as that page has to be updated manually and might lag behind) you could use https://github.com/monome/teletype/releases - it should always have the latest.
there might be several beta versions available as well at any given point but unless you want new functionality you could just ignore them. obviously, people might share scenes that take advantage of the new functionality already - i don’t really see it as a problem (but would be good to include version number in a scene somewhere, we should add that).
edit: we also have documentation on what features were added in which version, with breaking changes clearly identified:
could you provide specific examples? looking at the teletype repository there are 7 open bugs listed (the rest are enhancements), i’m planning to fix 5 of them in the upcoming 2.3 version. 43 defects are marked as fixed. i would consider that a very healthy ratio.
I fell into a rabbit hole trying to implement USB cables in VCVRack without making any changes to the core engine. After I either finish or give up on that, TT/VCV is probably the next thing to tackle. I think it might be too much to expect VCVRack TT to be a perfect simulation of the hardware anytime soon, but the ability to preview patches from a library would be awesome even if it’s not 100% accurate.