#21

yes, i’d like to make sure it survives any shutdown. this attached 64/arc version is updated to connect with max 7.
tml64_refactor .zip (36.8 KB)

#22

OK, I’ll put together another pull request later today.

Just a reminder that anybody can create a Github account, fork the monome-community/collected/ project, add files, etc, and submit a pull request.

#23

merged and also added @jasonw22 as a collaborator to this repo!

1 Like
#24

Thanks tehn! I’ll add the Max 7 version sometime this weekend, and start working on including some of the other archive.monome.org apps as well.

Edit: There have been a couple of new apps that have emerged since I started working on this. Control and René come to mind. Any others?

#25

OK, I’ve added the Max 7 version of tml to

#26

Just pasting the relevant bit above from the conversation at

If anybody wants to help out, any and all offers are appreciated!

2 Likes
#27

Just wanted to chime in here - sorry I’m late to the ‘party’.

I was the one that migrated all the existing apps into /collected and /collected-ms doing a cursory test / serialosc update wherever possible. Most apps in /collected-ms weren’t updated to serialosc because I couldn’t figure out a quick way (eg. cool apps like peter’s ‘flip’ and ‘npc’), or because they seemed too basic or reproduced other apps functionality to justify the time. Of course I haven’t used ALL of these patches so some of that was based on 30 second judgements.

Secondly, a number of the above apps weren’t added because I couldn’t find a working download, or I couldn’t get them to do anything. The process of adding them to github only takes 2 minutes, but it’s the testing / updating process that makes the task so daunting.

Realistically, I think the best approach is to decide on the most important / useful apps, and focus on bringing them up to full spec. Current versions of Max, all grids supported, good documentation. Adding useful documentation to a handful of apps seems more important to me than trying to fix a bunch of broken old apps that might never have worked in the first place. A lot of the old apps (mine included) were largely ‘learning patches’ that people shared to get feedback on and maybe help out a particular niche need, but weren’t by any means meant for mass consumption.

Obviously there’s a lot of grey area in making these decisions, but I think it makes most sense to start at the top, with the most used apps, focussing on documentation & usability & bug fixes. The best thing about this being that it’s the most rewarding work (to me at least).

Hope that gives some context to the current state of the github. 80/20 rule type thing, so there’s more to be migrated / updated, but they’re all complicated for one reason or another.

Finally, I’d really like to suggest that any new apps have their own repo. The ‘collected’ repo was originally intended purely for archival purposes, where any apps still in development would hopefully be forked to their own repos.

3 Likes
#28

i can’t emphasize this enough.

1 Like
#29

Sounds great! Which ones are the most important/useful?

1 Like
#30

Hah… If only it were that simple a question.

1 Like
#31

Right. I asked it a bit tongue-in-cheek.

Here’s one yardstick: if the author is willing to maintain it to any degree, it stays. If not, it doesn’t. Too harsh?

#32

It’s just hard to ignore the fact that I don’t really see many of these authors around here lately.

#33

Exactly- and myself included. My endeavours are best focused elsewhere these days, and I’d simply prefer to be making new things that continue to push the envelope than update a patch I built 5 years ago, and gave away for free.

I think the test should not be if the author is willing to maintain it, but rather if the community is willing to maintain it. This is, after all, one of the primary drivers for going open source.

Not to be too snarky of course! I would be absolutely interested in giving suggestions / guidance if someone wants to take over supporting mlrv2, or making an mlrv3. It’s a huge task though, and I understand why nobody has stepped up to date.

I would hate to see all of @stretta’s patches go to the trashbin of history because he’s not actively developing (outside of his work with BEAP). We should absolutely find a way to preserve these creations that survives any turnover of users / authors.

3 Likes
#34

So, I’ve been having some difficulty (with the exception of this interaction) finding any interest from the community in thinking about this to any degree.

But, if there is even one other person out there willing to put some elbow grease into coming with a preservation plan and executing it, then I’m willing to devote any effort necessary to seeing it through. I just need another mind to help me sanity check (and it would ideally belong to someone with a much longer history with the community than myself).

So, I’m hearing one vote for “save @stretta’s work!” (agreed!)

What else?

3 Likes
#35

I really like the idea of having a central archive of this stuff, so thanks for taking that on!

I’ve not really chimed in on any of this stuff as I’m pretty chalked up doing tpv2 and other similar things. So in that sense I’m trying to ‘clean up after myself’ with moving development of that app forward. (Max7 makes it crash hard still, and it’s been difficult (impossible) to figure out what change caused it).

I think trying to go forward with certain ‘house style’ things in place is probably a good idea, even if nothing else than serialosc being installed by default and standardized (though I miss the font/color editing in the previous versions!).

1 Like
#36

RE: missing apps, did tintinabulome ever make it over or even get converted post serialosc?

#37

It is here:

It does not yet work directly with serialosc (requires monomebridge)

#38

I’m going to start creating Github issues for the many tasks that are needed.

You all should feel free to do the same:

2 Likes
#39

@jasonw22 thank you for all of your efforts!

an idea-- once an application is updated (tested, versions noted, and a reasonable amount of documentation) it should get its own repository on https://github.com/monome-community

i don’t necessarily think this is an issue of things should go vs. stay-- just that a good bit of warning should be placed on untested/undocumented projects.

3 Likes
#40

ding!

echoing all the thanks @jasonw22