Collaborative patching
I'm wondering if anyone has tried collaborative patching online perhaps through this forum.
We could conceivably start with someone posting a patch and then it being modified iteratively by members of the forum.
What do you guys think?
This is a great idea, and a novel use of the forum, although where it should be hosted might be an issue - - count me in.
Yes, this could be really cool! Something like a "cadavre exqui". Funny you've mentioned this now because about two weeks ago i was thinking about a similar thing. So yeah, i'm definitely up for it and who starts? :)
FRid
native objects only, no loops/samples?
May I ask another question:
Since Max can be used for many diverse applications, what will the aim of the patch be?
I guess that's up to digiology, but if it's aimed at the lowest common demoninator so that everyone, regardless of skill/ability can participate and enjoy, then perhaps a simple but fun and novel self-contained interactive multimedia patch.
I agree that it's very intriguing.
Then you mean choosing one idea, instead of simultaneously advancing many projects by members who are interested in those.(? I thought the latter would "maybe" iterate to the current usage of the forum.)
About the aim of the patch, maybe it's possible to have three different categories, Max/MSp/Jitter, where emphasis lies on one of those three. I agree with the restriction of native-objects/files only and no samples/loops, this keeps it open for all to join in and add.
Ok I'm thinking in terms of logistics we could simly do it on the forum by copying and pasting the patch text. If this isn't a good idea please let me know why.
We would need some protocol in order to avoid people working concurrently on one iteration. perhaps something like:
-After an iteration is posted someone replies to book a time slot to work on the iteration [even if its only a small modification].
-After 'booking' they must post their iteration within lets say an hour of expressing their intent to modify. Failure to do so allows someone else to book.
-After the iteration is posted someone is free to book a slot.
I don't want to be the dicator here so if you have a better way of going about this please do share!
I terms of the patch I would agree with brendan on having no loops or samples. It could however be feasible to start with a small folder of samples which we may or may not choose to use but not allow adding to that collection later on.
As for what the goal of the patch would be. I think the patch should generate its own input [if that makes sense] and output audio. As a protocol we could say that on the top left should be a bang button that begins the patch [which may involve the unfolding of a composed intentional sequence or something more generative and endless] and at the bottom right have the output stage.
I could make up this skeleton beforehand.
Would you agree with this or do you think it would be nice to be able to 'play' the patch?possibly allow user input to be played with and recorded as control data.
I would hope that we all understand the entire patch as it evolves but there are going to be cases where this isn't going to happen or it may not even be necessary.
I would stress that we should modularize it as we go along so that some of the complexity can be reduced.
We could have an 'intermediate' and 'advanced' thread to be practical. What do you think?
Each iteration that is posted should have a little explanation on what has been changed preferably on the forum post but also in the patch comments!
Ok so I've given some suggestions of what kind of rules we could abide by. please let me know what you think. I don't want to have too much authority over this just because I started the thread!
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.
@digiology: "I don't want to have too much authority..." - you could perhaps moderate, and it seems you have some skeleton ideas for overseeing the evolution of the project already. Would 4 stickies be possible on this forum? One each for Max/MSP intermediate/advanced, Jitter intermediate/advanced. Perhaps low-level detail like automation/user input etc could just 'evolve' with the project?
Yeah, i like the "booking"-idea, maybe just post a reply in the thread saying you want to modify next and so on. About the understanding, the reason why i like the idea is because of the ability to learn from others in a more direct way than the forum and seeing new approaches made by others. So in fact i'm hoping i won't understand (at first :) and get challenged to understanding it. Because of the iterations and the ability to trace back the progress, i think this would be a great learning-tool.
Sound versus Video sounds good. And anoter question, when do we stop? :) like a number of iterations or would i be cooler to just keep on adjusting till we recreate reason and final cut pro in a patch :),
(The "h" on my keyboard is kinda broken so if there are "h's" missing, i'm sorry)
Yeah I don't mind moderating, I realise we'll need some loose rules but I want to make sure I get some feedback before deciding on them.
I don't think we need any stickies, the thread should be active enough to stay on the front page and the first post can outline the rules (to be edited along the way if necessary). If the moderators feel this is important enough to make a sticky thats fine, it could even evolve into a whole forum section of seperate collaborative projects.
I wonder would it be more interesting to avoid the intermediate and advanced boundary and allow some of the indeterminacy that would arise from beginners taking a stab at it!
If someone has wrecked the whole thing or taken it in a dead-end direction then another person can easily post an iteration that simply undoes the previous modification.
Perhaps if we had a seperate forum for this, new threads could be spawned at points of contention where the patch could evolve along seperate patches. The link to the previous thread could be indicated by a version number like: 13.1 & 13.2 referring to thread 13 and 13.2.1 referring to thread 13.2!
I think we should start out small first with few threads and see how it goes from there. Perhaps the mods will be willing to foster this, failing that I can set up a website for it.
This should be a great way to learn new things and be creative.
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.
would it be too simplistic to suggest that participants must keep two versions of the iteration they download: the original, and their extended/varied version; just as a way of backtracking should things get out of hand - it would be so easy for the less-experienced to break the whole 'chain'?
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?
Doh; the forum itself is the repository, of course.
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!
Sorry for trying to contribute although I'm new here, but I wish to kindly express my opinion that "the risk of the loss of the track/original" mentioned by Brendan is maybe one of some disadvantages of the "time-booking" idea. I don't think all participants may follow the project 24/7 to book the time. Also, not to miss the advantage of getting the best ideas from a population for each iteration, I think if someone wants to suggest an alternative for a past iteration while keeping the newer add-ons, this better be permitted.
Count me in !
as for javascript and the zip archive issue... i dunno, maybe keeping the copy/past compressed format is the easier way to go ? and beginning with a simple thing will allow better further improvement, maybe would be better to avoid javascript if it can't be uploaded here through the compressed method ? (and anyway can't you upload a zip archive through attachment here ?)
and as Emerson, though i'm new i'm full of enthousiasm :)
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.
About the development and slot-time. What if you ave time you just respond/reply to the thread then post the iteration back and if someone feels the need and has the time, then just reply saying you take up the next iteration and after that post it back. If nobody responds the patch is just waiting to be edited for the first one to reply? Isn't there a saying about this "First come first served" or something?
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.
Because of the fact you reply will show the next one their "place" is taken and then you will have to wait for the editor to post the new iteration. Maybe to keep it fair you can take up a "reservation" :) by replying to the thread saying that you would like to edit the next iteration if someone is editing ensuring you will be next in line.
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.
"I would hope that people would make reservations based on ideas they have specific to the previous iterations."
:) 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.
"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]."
No, ofcourse. thats what i mean by "first come first served" i think you confuse it with "Last in first out" (omg, this brings back good old "mtg"-memories. :)
Maybe its also better to have two threads; one for reservations and one for the actual iterations.
"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.
"improvisation" is the key word here, if you want my opinion (let's say ;) ) we should even not have a particular project or goal for a patcher which is going to be created collectively, better begin things simply, very simply, and see what one can add to that, so that crossover iterations would not even be a problem ; and moreover hoping the result to be completely unpredictable. or ?
"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"
I don't think i understand you here. Why would reservations conflict? If be any chance someone posts a reservation and when that person reloads the page and sees that someone has posted while he was replying, so be it. You would just have to wait for the one before you to complete the iteration.
Also because what if they both decide to rereserve, the whole thing could happen again? And what if (to make it even more interesting :) a third person be any chance posts a reservation while the other two are posting their re-reservations? Ah man, this is even more complex then i had thought... :)
It would seem, then, that the only major stumbling block might be ensuring that iterations evolve linearly. I really have no suggestion as to how this may be implemented, maybe a blog somewhere off-forum??
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.
brendan I think the protocol I've outlined would ensure this or at least make conflicts very very unlikely.
I've try to outline this protocol in one post later on just to make it clear and see what people think of it.
"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.
hm maybe knowing which of
- a linear solution, or
- a more free, side-modifications-allowing system
would better work ; is only possible by testing it out ?
And definitely you Digiology, as a moderator, should set up some rules, the one you personnally prefer, and an overall direction if you feel like it, and just go ! Cause we are now arguing with no elements, and maybe it's not leading anywhere, or really slower than by testing things practically...
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.
yay !
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!
What about max preferences? What preferences could we keep static yet allow efficient behavior for any direction it could go in?
What about the following:
IO vector size: 512
Signal vector: size 64
Sampling rate: 44100
Overdrive: yes
Audio interrupt: yes
I haven't looked in to timing issues or the scheduler for a while so I'll need so help choosing these settings. I think this would allow for a temporal resolution of 1.45 ms and to remain fairly in sync with the audio though.
I'm thinking we should have:
-intermediate audio
-advanced audio
-jitter audio/video [most jitter guys are advanced aren't they?!]
Good work digiology, looks like we're prepped for launch!
that all seems perfect :)
(maybe copypaste those "rules" in the first post of the sooncoming thread)
last minute idea : having a subpatch with list of contriburs, and why not one particular color per contributor :p
Glad ye like it. Can anyone give their thoughts on the max settings? I mean it shouldn't matter for most types of functionality but it would be nice to have an agreed upon setting from which to work.
Too small a signal vector size will be too heavy for some computers but may not give enough timing accuracy for some functionallity.
vichung that might be nice. I don't think I'll make that a rule but if you want to do this early on and ask people to stick to it thats fine. I'm not sure there are enough colours to represent us all though so it could be optional.
I suppose this would help people recognize their own work that might have been rearranged.
So yeah if anyone wants to make up their own conventions along the way be my guest.
the basic settings, the one you proposed, are fine i think. Anyway i'm not sure it's a problem, since different people with different max settings can use the same patches as far as i know.
there are cases where the settings are important. This is mostly true when interacting between the msp and max levels for example getting values at specific moments or synchronizing between both the signal and control rate.
I'll start the thread within the next hour or two. I think we're ready to go.