#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
#51

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.

2 Likes
#52

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:

https://monome.org/docs/modular/teletype/manual/#whats-new
https://monome.org/docs/modular/teletype/manual/#changelog

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.

5 Likes
#53

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.

2 Likes
#54

yeah, i imagine implementing tt in vcvrack would be an order of magnitude more complex than porting trilogy/ansible. will be happy to help with any tt questions!

#55

It might be more of a general feeling coming from my experience with the trilogy/tt, i2c and Ansible development history and information policy that holds me back from getting more involved. I know not of any specific bugs in the 2.3 firmware.

Yep, it actually is behind. Of course it is only a small symptom but it irritates me when I try finding my way between different firmwares and beta versions and then I just stop it. I remember that I once tried to achieve a membership in github but could not work it out and again just capitulated.

But anyway, that is just my inexperience since you asked why one would not participate. I am sure it is easy fun for other people.