digiology

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].

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:

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.

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.

-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.

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

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.

mspaudio-collaborative-patch-intermediate

I've added a little processing to the audio input. The details are in the comments. It essentially makes noise if you have your internal mic and speakers enabled. If not be sure to modify it to your liking.

-changed send and receive objects so that they can convey audio :p

-regrouped all objects in a smaller area. Sorry for that, might be less common for you if you have a bigger screen, but with a macbook 13'3" i really need to have things more compacted... feel free to uncompact if you feel like it :)

-added a matrix~, matrixctrl and preset connected to that last thing. BUT i'm very pessimistic about capacities of the preset objects to keep saved preset through compressed copy and past.

here...
mainly :
-added phasis modulation
-changed send and receive objects so that they can convey audio :p
-regrouped all objects in a smaller area. Sorry for that, might be less common for you if you have a bigger screen, but with a macbook 13'3" i really need to have things more compacted... feel free to uncompact if you feel like it :)
-added a matrix~, matrixctrl and preset connected to that last thing. BUT i'm very pessimistic about capacities of the preset objects to keep saved preset through compressed copy and past.
EDIT : that does actually work !

Added modulation to the phase modulator oscillator [which is enabled by default now] and added a comb filter to frequencies roughly above 200Hz [the volume of this signal also varies in volume over time].

I also removed the version history thing. I don't see this as necessary unless I'm missing something.

I also just broke the booking rule! I think we can ignore this if we don't want to commit to holding up the thread but we do this at the risk of loosing our work in the process.

After a good days work on setting up a BT-network i'm back on the inter-web and booking.

I've added interactive synthesis in the form of function, a looping method and a waveselektor, adjusted the ADC~ on startup to synthesis, (i constantly and immediately get feedback with adc turned on). That's it.

Added an arpeggiator to control the pitch of the filter and the cycle that feeds channel 2 of the matrix, and also now controls and syncs to the line time of FRid's function. The line thing should probably have a switch to go back to the function time, but I didn't add it.

time's up; did a little house-keeping, but all I could do was add a litle sweep to the [lores~] - future tinkerers take note, maybe download the latest iteration and spend some time familiarising yourself with it before tinkering, just like i didn't!

Also changed the [lores~] resonance value to 0.1, as with certain combinations high cutoff = too much resonance; my addition is easily erasable btw

time's up; did a little house-keeping, but all I could do was add a litle sweep to the [lores~] - future tinkerers take note, maybe download the latest iteration and spend some time familiarising yourself with it before tinkering, just like i didn't!
Also changed the [lores~] resonance value to 0.1, as with certain combinations high cutoff = too much resonance; my addition is easily erasable btw

Yeah I would agree that its wise to have a look over the patch before booking. That said, I don't think we need to be too strict about the booking time, this thread hasn't been as busy as I anticipated.

How about we extend the maximum time to 2 hours?

two hour limit gets my vote; maybe i could do something a little more aesthetically innovative........btw, iterators (tinkerers/contributors) seem to be fairly shy about adding comments to their additions where needed - this isn't the 'advanced' thread, so perhaps the project's 'choatic' evolution could be ameliorated by some handy comments, and thereby also contribute to learners' development too.....?

Ha ha I finally got to take a look at this. Not sure whats going on yet but it sounds interesting.

In fairness people are giving explanations within the thread and combined with the colours this is helping. perhaps some commenting on groups of objects would help for us to decode whats going on in each modification.

modifications are added in a specific colour

comments are added next to groups of objects or as subpatcher names but a full explanation is added in the version history patcher [which I can add back in].

This would allow the components to be identified but the full explanations can be kept in order and out of the way.

I should also stress that if you don't like whats going on in the patch, either with the sound or the lack of control. Change it, take it apart and rewire it into something new, delete what you won't need [or leave it 'floating' out of the chain for someone else to find a use for].

modifications are added in a specific colour
comments are added next to groups of objects or as subpatcher names but a full explanation is added in the version history patcher [which I can add back in].

I should also stress that if you don't like whats going on in the patch, either with the sound or the lack of control. Change it,  take it apart and rewire it into something new, delete what you won't need [or leave it 'floating' out of the chain for someone else to find a use for].


I did a little house keeping to try to make it a bit more readable. Also added some more parameters and UI controls. Oh, and I changed Brendan's color because it was a little too similar to Digiology's.

MSP/Audio collaborative patch - intermediate