Preserving monome apps for arc and grid

[jasonw22]

If anyone would like to help:

Issue: Test the apps

[ppqq]

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.

Definitely interested! Boarding a flight now but I’ll send you a pm to keep the conversation going.

[jasonw22]

If anyone wants to add serialosc support to the 3 apps from @stretta that don’t have it yet:

Issue: Update @stretta's apps

If you see any other apps in the collected-ms repository that you’d like to be able to use with serialosc, please open an issue here:

monome-community/collected-ms

[tehn]

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

i’d say it’s up to you, as a conservator. you’ve already identified a few that slipped through the cracks. and i suspect you have a good sense of what constitutes “value” for both newcomers and archival purposes.

seeing the github updates coming through-- warms my heart! thank you!

[ppqq]

@jasonw22 and I have had a side-band conversation but it occurs to me that some of my questions might benefit from a larger audience.

I’m curious, in general, how folks feel about the future of these apps. Where there’s interest should they be evolved in place or new patchers created? Assuming the changes are small, I guess in place makes sense where new features maybe justify a new one? Either way, what do you all think about attribution? Should we broaden them from the author names to add monome-community or something? To take a specific case, I’ve been playing with @stretta’s lovely mabalhabla and would like to fold in support to directly select a plugin (rather than midi) out. This is largely for my own enjoyment but may come in handy for other folks. If that patch lands, should we do anything to the attribution in the patch that reads:

stretta.com 2007-2011 

?

Assuming we want to evolve apps, do we want to grow them in the community repo or should we do that in our own forks?

Thanks in advance for any thoughts!

[glia]

[quote=“ppqq, post:45, topic:1989”]
what do you all think about attribution? Should we broaden them from the author names to add monome-community or something? To take a specific case, I’ve been playing with @stretta’s lovely mabalhabla and would like to fold in support to directly select a plugin (rather than midi) out. This is largely for my own enjoyment but may come in handy for other folks. If that patch lands, should we do anything to the attribution in the patch that reads:

stretta.com 2007-2011
[/quote]cant answer as an app dev, or for stretta himself
but I have an opinion as a community member + user

if things are being tweaked/revised/re-released…attribution in line with the original would be unnecessary

[Galapagoose]

My preference would be that the original attribution remained with an additional line added by the contributor(s). This is especially the case when the original author can’t be / isn’t contacted. I would note that while the nature of the community developed & shared applications is framed in the open-source mindset, this can’t really be a presumption. Authors should be treated with the utmost respect as such, and if you modify their work it should both be clear that the new thing is built on their work, but also it’s not been approved / sanctioned by them.

Point here is that if you make an edit to an app it’s important not just to maintain the existing attribution, but to make it clear that the later modifications were done without collaboration. I note this along the lines that later modifications might take an app to a place the original author desired to avoid, and it would be disingenuous to have it appear as though there was interaction between the parties.

I myself am guilty of modifying many (very many!) of the patches when ‘updating’ them to serialosc without such attribution. In fact with no attribution, and leaving the existing author’s details present. It felt appropriate at the time, but I’m aware there may be some cases where my job was imperfect and some functionality was lost. I guess the main balance is between simplicity & functional differences – nobody will read 3 paragraphs of attribution info!

[glia]

wise words

a few facets I thought of and others I hadn’t considered at all

[ppqq]

My preference would be that the original attribution remained with an additional line added by the contributor(s).

Mine too. Is in the patch preferred or should we add an AUTHORS or CONTRIBUTORS file?

Also, sorry if I missed it, but has there ever been a conversation about licensing? I notice, for example, that other monome code bits (e.g., teletype) are GNU-licensed. Something to consider here?

[jasonw22]

In the readme.md there’s usually a “Created by: [name]” near the top of the file. Just a single line, nothing fancy.

[abalone]

thanks, it’s cool to have apps working with serialosc

[scanner_darkly]

i find it very strange that further modifications authored by another person would not need to be acknowledged/attributed. if you have some old patch that doesn’t even run on the latest version of max, and somebody volunteers their [possibly significant] time to make it work again, should they not be recognized for their work? this is obviously with the disclaimer that any modifications were permitted by the original author, based on their intentions expressed in one way or another, including specific license used.

also, i’m not entirely sure explicitly stating modifications were not approved by the original creator is necessary when working with git. forking achieves both goals - it makes it clear what the source is, and the fact that it’s a fork, be definition something that is intended to build upon the original. i think in this case it’s implied that such changes were done without the explicit original author’s consent [i very much doubt that every fork out there on git specifies this…] again, assuming the license allows for further modifications.

i operated with these assumption so far, but would like @tehn to comment on whether an explicit clarification for some of the firmware mods are needed, so i can add them accordingly.

[jasonw22]

I hope I wasn’t misunderstood. I agree completely. I was merely saying that an AUTHORS file generally hasn’t been used, and attribution has historically been a simple “Created by: [name]”.

That was NOT intended to mean “don’t credit all authors”.

My feeling about attribution is “the more the better”. That being said, it’s not as if there’s a consistent precedent within the monome community (as of yet). When folks pulled together the monome-community repository some consistency in the readme.md was imposed by the curators, which we’re trying to continue.

But of course we could be more thorough. Might be tough in some cases. Try spelunking the depths of the many mlr versions and making sense of it. It’s important to remember that much of monome’s Max history precedes widespread use of git.

[scanner_darkly]

yeah, for something that is distributed in a different manner from git it’s more important to state that it’s a different version and what exactly was changed, as it wouldn’t be entirely clear otherwise, and i could see the original creator not wanting people to confuse modified version with the original.

[elquinto]

i think i have a sosc version of tintin and tr-256 i can help u with. never heard of trigger sequencer… one of stretta’s?

[jasonw22]

I think people should make their best effort to follow the advice in this thread. That being said, I’m not sure how much sleep we should lose over any failure to do that, that may have happened in the past. It’s pretty challenging just finding the time to save what’s there from bitrot (the endless march of dependency versions).

[jasonw22]

Very cool. Please make note of attribution advice from this thread.

Feel free to host them in your own repository since you’re already doing that with other apps. You can leave a comment on the github issue so that the updated versions get included in a future wiki page that will include only working apps (as opposed to the current laundry list of every app whether they work or not).

Yes, trigger sequencer is from @stretta.

Here’s that github issue where you should leave comments about serialosc updates, etc:

Issue: Test the apps

[elquinto]

could i just submit a pull request to the tintin / tr-256 repos? (do they have repos?)

[jasonw22]

They don’t. Here’s the repos:

monome-community

If you look at the github issue above you’ll see which apps (that were previously converted for use with serialosc) have been tested and which ones haven’t. If it’s on the list but not crossed off, it might already work, and I just haven’t tested it yet, and is meanwhile waiting in the https://github.com/monome-community/collected holding area. If it’s not on the list at all, it’s probably a monomeserial app that needs to be converted for use with serialosc, in which case it’s likely located here: https://github.com/monome-community/collected-ms

[Galapagoose]

Yeah to clarify, I’m talking almost exclusively from the pre-git days. That whole monome-community repo was created by manually dumping all of the stuff on the wiki into it to save the hassle of making a separate repo for hundreds of patchers.

I paid zero regard to the licenses any authors had attached to their works, as almost none explicitly did (ie. technically retaining full copyright). Obviously we can assume something from their public posting of the patches, but it’s not as clear cut as using the license currently attached to the patches.

Seems to me this is mostly an academic consideration anyway though. Traditionally the monome position is something like:

1. If you plan on freely sharing or taking some nominal fee, go for it with proper attribution.
2. If you plan on making a business out of something, contact the author before going ahead.

I’d say that’s broadly the mentality that most existing content was created within, so probably a good framework to keep in mind if no explicit license is mentioned.

//
I realize this is probably a bit off topic now. Just trying to reflect on the origins of much of the shared material.

Some open-source fanatics (particularly from the software realm) had issues with the use of non-commercial license (“not TRUE open source!”) which created issues in the hardware realm. This ‘contact for commercial use’ isn’t to discourage commercial use, but simply to maintain legal rights to stop carbon copies undercutting the hardware. In theory.

All said, I don’t remember what license monome used on the early hardware, but this is just some food for thought, or perhaps just a reflection in hindsight.