Collaborative patching

FRid perhaps we could categorize it into max/msp [audio based] and jitter [video based] projects. This wouldn’t rule out using objects from either class but we could categorize based on the medium or goal in mind.

FRid,

I don’t think there should necessarily be a point where we stop!

It would definately be cool if we all understand each iteration, that said if someone wants to throw in an encapsulated object whose implementation is unclear but its goals (input and what it does to the output) are clear then I think this should be allowed. This is probably where the beginners and experts can find some interaction without too much explanation.

The intermediate and advanced threads would differ more in terms of how much explanation needs to be done and how much low level detail can be delved in to. So an ‘advanced’ subpatch/encapsulation could be added as an intermediate iteration as long as its purpose or results are likely to be somewhat clear.

We don’t have to be too strict with the boundaries here, we just need some common sense and to make sure we explain what we are doing with each iteration.

I’m not sure I understand. If we paste each iteration as a post on the thread then all the old versions are also kept so that anybody can baktrack should they choose to.

A typical thread would look like:

Introduction, rules and skeleton
first booking
first iteration and explanation [within certain time period after booking]
second booking
second iteration
etc.

Or had you something else in mind?

Yup. I’m not sure if we’ll use the compressed text form or the upload feature. It would be nice to keep everything in the one file but thats not so easy when dealing with javascript for example. A zip archive might be easier.

Keep the suggestions coming!

vichug, you can upload a zip file. It might be nice to have a folder of seperate files in case things start getting large as long as we have a ‘main’ file.

Emerson, thats a great point. Although none of the iterations will be lost I can see how people [that actually have lives!] won’t be able to keep up with the entire development.

I’m not sure what the solution is to this. We could increase the slot time but that would leave many waiting or we could simply accept that not everyone is going to be able to follow the entire thing.

I think later on after we’ve done this a few times we can change the protocol a little perhaps have multiple projects that move at a much slower pace and that each have different specific goals.

I suppose I’m just concerned that someone might take an iteration, look at it for 10 minutes to figure out whats going on, and then spend 15 minutes modifying it.
I don’t want their work to be wasted or worse have someone post an iteration that completely ignores the previous one because it was posted while they were coding theirs.

It would be very frrustrating to have your work lost like that.

I see… I would hope that people would make reservations based on ideas they have specific to the previous iterations. I think it should be first come first served in terms of who gets to reserve for the next iteration.
If someone posts a reservation without seeing that someone else has, then the first person gets it [this would require looking at the thread after posting your reservation].

I don’t think that the second person to make the reservation should get the following iteration without explicitly reserving again later on [I hope that makes sense].
This would avoid a queue of people who may not have the time to both wait for the next iteration and code up their iteration in response to an unexpected change.

This just keeps things simple.

"thats what i mean by "first come first served""

Yeah I realise that now. So we’re agreed on this aspect I think.

"Why not make it really challenging, (like a freestyle): If someone is second in line that person would have just improvise on what the one before them did."

I’m not too concerned about how much planning or improvisation is done, but do I think some foresight would actually make it more [not less] interesting but that doesn’t mean that someone can’t improvise.

I think its simpler to have it the way I explained above. If two people’s reservations conflict the rest of us aren’t left wondering if the next slot will be free. The person should have to rereserve, its a lot less troublesome I think, even if its not quite as fair.

I agree not to have a goal but at the very least for us to know what overall function it has. Does it create sounds or simply midi? Does it require sound from the audio interface or other user input to function?

In intermediate stages it might not do anything and thats fine but shouldn’t our modifications be directed with something vaguely in mind even if only to steer it in an interesting direction?

Any restrictions on overall function will probably not be worth it and be too restrictive in some cases. I can trust that we’ll all make contributions with the goal of making things interesting in mind. Hopefully we can be disciplined and respectful enough to keep things tidy and well commented.

I don’t agree with what I think you both are imlying that somehow letting it loose to become unpredictable or worse an unmanagable level of comlexity would make things more interesting. Sure we can have chaotic parts that produce interesting result but I would hope we can understand why they are chaotic or at least have them encapsulated in such a way as to still have some grasp of whats going on on other parts of the patch. I hope I’m making sense here.

"In intermediate stages it might not do anything and thats fine but shouldn’t our modifications be directed with something vaguely in mind even if only to steer it in an interesting direction?"

To quote myself. I don’t mean with respect to a collective goal but for each of us to have some willingness to steer it in some direction. I think this will happen organically by itself anyway.

Yup. I’ll post a summary of the proposed rules later on and give it a few hours to see if anyone has any major objections or suggestions. After that I think we’re ready to go and we can refine it as we go along.

Ok here are the draft rules more or less how they’ll look on the first post of the thread. please let me know what may be missing or what should be added or clarified.

I’ll start with a simple patch, this and each modification will be referred to as an ‘iteration’.

-After an iteration is posted within this thread someone can reply with the word "reserve" to book a time slot. This gives them time to work on their iteration however small this might be.

-After ‘booking’ they must post their iteration within an hour of expressing their intent to modify. Failure to do so allows someone else to book. In reality the time between modifications will probably be much smaller.

-When posting your booking check the reloaded thread to see if anyone else managed to book before you. By default they get that booking. You must explicitly rebook after that person has posted their iteration in order to get a place. If someone else gets in before you thats too bad [this keeps things simpler].

-In the unlikely event that there is a conflict and two iterations are posted together the next person can choose to merge these or choose one. more generally people can simply choose to undo the previous iteration’s modification or start from a much earlier iteration if desired. It would be nice to avoid doing this as much as possible though.

-each iteration posted should be pasted as compressed text using max’s "copy compressed" function. If later on multiple files seem necessary we will begin uploading a zip file. This will contain all dependent files in a folder and a main max file called ‘main’. Nobody should have to modify their max file preferences!

Other rules
No samples or external objects

Keep things tidy, encapsulated and well commented where appropriate. I suppose this isn’t really a rule, just some good advice!