For those of you who haven't seen my last thread "collaborative patching" here is what's going to happen in this thread. We're going to start with a patch and take turns modifying it. There will be no overall goal other than our own individual desires to make this interesting.

The intermediate and advanced threads will probably 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 to 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 so we're not completely lost.

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 own iteration which will involve some modification [big or small] of what has been posted recently.

-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 again thats too bad [this protocol 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 [you don't need anyone's permission to do this]. The zip file will contain all dependent files in a folder and a main max file called 'main'. Nobody should have to modify their max file preferences in order for it to run!

-You should explain what your modification is or what its effect is on how the patch works and how the user may interact with it [if they need to at all].

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!

There is a subpatch of colours for each user that wants to identify themselves this way. This is completely optional but if you do use it try to colour the borders of objects not the background colour. You can select multiple objects and hit cmd + i to change attributes for the selected objects [may not work for UI objects].

Just in case, it might be worth setting our preferences to the following so that we have consistent behavior across computers:

IO vector size: 512 Signal vector size: 64 Sampling rate: 44100 Overdrive: yes Audio interrupt: yes

There are probably more appropriate settings for this. please let me know if you feel strongly about this.

Below is something like a template that will highlight a few good practices. Namely to have a single loadbang that can be triggered manually [pasting a patch doesn't trigger loadbang automatically]. This will initialize everything as desired. The state of UI objects can be stored using a preset object or some other method. It would also be a good idea to have a single point at which audio is output [rather than multiple dac~ objects]. I'm using send and receive objects to allow this but people might prefer to have a strict visible signal path and thats fine too.