Building My Patch #7: The Looping Delay.

The next aspect of my patch that I decided to start work on was the Looping delay unit. Similarly to the phasor, in order to start this piece of my project I imported a 'loop_handler' sub patch from the cycling 74 examples folder.

Once this was imported, I uploaded a tap tempo sub patch from the cycling 74 examples folder too, along with a button and 'flonum' object, so that my users would be able to control the tempo and time at which their audio was delayed.

After connecting this to the loop handler, I created three dial objects, which would give the user control over the Delay mix, amplitude and filter levels of the audio's delay. All of these had a minimum value of 0 and a step multiplier of 1. Next I created 4 on/off toggles that would control the 'freeze', 'on and off', 'input active' and 'bypass' aspects of my looping delay. I felt that this gave my users a great deal of control over the level of delay on their audio.

Finally I created another dial that would control the click level, and connected all of the different aspects of my looping delay unit. Once everything was correctly labelled and I was sure that this unit worked, I was ready to move onto the next piece of my project.  

Looping_delay

Creating my Patch #6: The Compression Unit.

I next began work on my compression unit, as I wanted my users to have the ability to compress their audio, and therefore manipulate it in that way. Firstly, I imported a template of a 'comp_handler' from the cycling 74 example folder, so that I was certain that the subpatch would work correctly inside of my compression unit. 

I then created 2 dials, giving my user control over the threshold and ratio that their audio would be compressed. The threshold dial had 270 degrees, with 128 steps and a minumum value of -8. I felt as though this gave my user a helpful amount of control, thus improving usability. Similarly, the ratio dial used the same degree and step number, but had a minumum value of 1, with a step mulitplier of 64.

I then created three 'flonum' objects which would control the attack, release and makeup gain of my compression unit. All three of these 'flonum' objects had a minimum value of 0 and no maximum value, therefore giving my user no limitations, allowing them to have complete control over the degree to which their audio would be compressed.

As with many of my other effect units, I wanted my users to have the option of bypassing this particular effect altogether. In order to do this, once agin I created an on/off toggle, and then labelled this with a bright blue comment object, so that it would be easily to notice for my users.

I then wanted to make it easy for my users to see the effects of my compression unit, and to be able to make sure that it was working, and so added a level meter so that the level of audio would be indicated clearly. In order to make this level meter even more clear, I changed the colouring of it to Green, Yellow, Orange and Red; making it obvious when the audio was peaking.

Finally, once all of the dials and flonum objects were correctly connected to the 'comp_handler', I labelled each of the different aspects, and placed a comment box in the top left corner of the unit, making it clear which effect unit my users were using.

Compressor

Creating my patch #5: The Phasor.

The next aspect of my patch that I began working on was the phasor effect unit. I started this unit by importing a 'phasor handler' with a core subpatch inside it. I then create 5 dial objects, which would represent each of the individual effects that my users could manipulate in my phasor. These were rate, depth, centre frequency, spread and reactive power or 'Q'. Once all of the dials were connected correctly to the phasor handler, I the created a 'number display' and a value 'incdec' object that would range from 1 to 8, so that my users could decide the degree in which their audio would be manipulated by this phasor unit. 

I then, as I did in the spectral delay effect unit, created a bypass on/off 'toggle', thus allowing my users to have the option of making this individual effect unit inactive. Once again, once all of these aspects of this unit were in-place and connected properly I labelled each of the individual aspects of the patch with 'comment' objects, therefore improving usability and making my patch clearer to the user. 

Phasor

Creating my patch #4: My spectral delay unit.

The next piece of my patch that I wanted to begin work on was an effect unit that I did not originally plan on using in my final project; a spectral delay unit. After looking through a number of the forums on the cycling 74 website, I saw that this was not a commonly used aspect of many of the guitar processing rigs, therefore I felt that this piece of my project would make it stand out from the crowd and would therefore make my project more original. 

I began by importing a template of a 'spectral processing manager' from the example patches in MAX's database. This would ensure that the dealy unit would work correctly and would save me time in creating the subpatches inside. I then created two 'filter' and 'delay' buffers, and connected them up to a loadbang object. I then imported two waveform viewers for each of the buffers, so that my users would be able to manipulate and edit the way in which the filter and delay effects worked on my spectral delay unit. 

Once the buffers were set up correctly, I connected m spectral processing manager up to a live gain slider, which ranged from -70 decibels to 6. This would allow my users to choose how loudly the effects of this dealy unit would affect their audio. I then decided that I wanted my users to have the option of bypassing this effect unit entirely, thus giving them more control over the processing rig. In order to do this, I connected my live gain slider to a 'selector~ 2 1' object, and then onto a '+1' object. I then linked that onto an on/off toggle object, thus making it simple for users to make this particular effect unit active or inactive.

As this was all set up and I had tested that it worked sufficiently, I clearly labelled all of the aspects such as the live gain and delay/filter shape editors, so as to make it clear to my users what each aspect of my unit was. I then felt suitably pleased with this piece of my patch and so was ready to move onto the next effect unit.  

Spectral_delay

Building my Patch #3: My Reverb Unit

The next piece of my patch that I began work on was the reverb unit. As this effect is so commonly used on guitar processing rigs, I felt that it was the natural selection to come after the EQ unit.

I started by using a template from the max 'examples' folder for a reverb handler, and then connected it to a dial with a minimum value of 0, and a step multiplier of 1. I then connected a 'flownum' object to the reverb handler so that I could manipulate the decay time of my reverb unit. I set the parameters of the 'flownum' to a minimum of 1 and a maximum of 10,000. I felt this would give my users a sufficient amount of control over the level of reverb they used on their audio.

Seeing as users of my processing rig may not want to use any reverb at all on their audio I next created an on/off 'toggle' object which would act as a bypass switch for my reverb unit. Again, I connected this to the reverb handler and felt that my reverb unit was more or less finished.

Finally I focused on the aesthetics and, to improve usability, created three 'comment' objects and clearly labelled the 'decay time', 'reverb mix' and 'bypass' aspects of my reverb unit. I decided to make the 'bypass' comment box an obvious and eye catching colour of blue with white lettering, so that users would easily be able to identify and use it.  

As with the Filtering/EQ unit, I then placed a final comment box, simply stating the title of this particular unit, 'Reverb', and placed it in the top left corner of the panel. I was pleased with the aesthetics of this unit and so was ready to move on to my next effect.   

Reverb

Building My Patch Continued: Filtering/EQ.

Following the Input handling unit, the next piece of my patch that I began work on was the Filtering and EQ unit. I felt that this was essential to my guitar processing rig as it would help the user to control the overall gain and levels of the low, high and middle frequencies, therefore it was the naturual selection to be placed after my input handling unit.

I began by copying the template from the max help files for a 'filter handler patch', that would control the many scalers and filters that would be used. Similarly, I used a template 'filter clearer' from the help files so that I could set the preset levels of the frequency and gain dials when the 'clear filters' message was applied. As both the 'filter clearer' and the 'filter handler' were already in sub-patches I simply needed to connect the seven dials into the inputs and outputs for them both. These seven dials represented 'Low Frequency', 'Low Gain', 'High Gain', 'High Frequency', 'Mid Frequency', 'Mid Gain' and finally 'Mid Q', and to make them easy to identify, I numbered them and placed comment boxes at the side of the unit with each number and its corresponding dail noted.  

Once the 'filter clearer' and 'filter handler' were connected to the dials correctly, I connected the 'filter handler' to the 'clear filters' message and a filtergraph, so that the effects of the filters could be cleary seen by the user. I also connected a noise level meter to the handler, so that it would be easy for any user to see whether or not the unit was working. 

I decided that, as this was such a crucial piece of my patch, there should be no 'bypass' toggle. Finally, I simply placed a comment box with the title 'Filtering/EQ' at the top of my unit so that it would be easy to identify, and I was done. 

Eq

Building my patch: The input handling unit.

Naturally, the starting point for my final project was the input handling unit. I therefore began my project by creating the object 'loadbang' which I connected to an 'adstatus driver', an 'adstatus option 0' and an 'adstatus input 1'. These represented the audio driver, audio option and the audio input, which would be connected to the Core Audio, Built-in microphone and 'input 1', thus allowing for playout, mic input as well as an optional additional input. 

Given that I was relatively unfamiliar with the use of the 'adstatus' object and its uses, I used the template from the help patches so as to ensure that my patch worked correctly. 

Once I'd connected the loadbang to the 'driver', 'option 0' and 'input 1', I created a sub-patch for them to be placed in so as to avoid clutter on my patch and therefore improve usability. In this sub-patch, I also placed an 'adc~' object so that I could monitor the audio status within my patch. 

In my input handling unit, as well as controlling the digital sound processing, I also wanted to control the gain level of my audio input. I therefore connected my 'input handler' to a '*~' object and then to a scale object, allowing me to not only use the normal gain levels of 0-127, but also to a scale that goes from 0-2, i.e.from silent to double the volume. Using a 'loadmess' object with a 64ms reaction time and a Gain dial, gave me a suitable level of control over my top-end gain. I made the gain dial green, with a white needle, so that it would be easy to identify and therefore simply to use. At this point I felt as though my interface looked very tidy, and though I may change it once my project was completed, I felt satisfied with the layout. 

I finally connected my '*~' object to a 'recieve~ test' object and a level meter, so that the audio could easily be tested, and that any auio output that peaked would be displayed by the level indicator, once again improving usability. 

I felt suitably pleased with my input handling unit and so was ready to start work on the individual effect units that I would make up the rest of my processing rig.  

Input_handler_screenshot

Session 7: Beginning work on my final project.

This we began working on our final projects. The session began with Pere coming round to each of us indivdually, to find out what are plan was and to see our first design outline. 

I explained to him my concept and decribed how I planned to accomplish it. I started my processing rig with an input handler, naturally, and then gave the list of effects I planned on using in my project. These included a compressor, EQ/filter, reverb unit and a phasor. I explained that these were not necessarily in any set order just yet, as I imagine I will chop and change them as I progress. Nevertheless, he was pleased with the high number of different effects I would be using. 

I then moved onto my presets. Here I planned on having a Modulating Digital Delay unit, so as to control the level of delay coming through after all of the other effects have changed the sound as much as the user likes. I then wanted the whole thing to come through an Overdrive/gain modulator. I decided to do this as I overall wanted my effects pedal to produce an overdriven or gain heavy sound, but for the user to have control over what other effects they had on it. The sound would then go out through the output handler and play out.    

I was very pleased with this session and feel fully confident that Pere is happy with my project. Therefore, in our next session I will begin working on my patch and start to create the indivdual elements. 

Session 6: Planning my final project.

This week we were encouraged to think about our final project in greater detail and, ideally, to finalise our idea.

I decided that for my final project I am going to create a guitar effects processing rig. This will follow all the usual conventions of an effects rig but will be, in my opinion, enhanced to suit the users needs and therefore improve usability. 

I have not yet entirely decided on the layout and processing chain of my rig, but am considering using an overdrive function as the last element of my rig, so that any sound that goes through, will be effected by it.

After discussing my idea with Pere, I felt confident in my plan and was excited to begin shaping my Max 6 patch. This week I will be researching the methods and conventions used when building a guitar effects processing rig so that next week I can think about starting work on my own.    

Session 5: Output Sliders.

This week we were learning about the use of output sliders in our Max 6 patches.

We began by learning that a gain slider is both a multiplier and a slider combined, and that we can use a VU level meter to gauge the level at which the sound stars to become distorted. This allows us to limit and scale our levels. We were told that the output for audio levels needs to always be scaled to 0-1, and for midi controlling audio, it needs to be between 0 and 127. 

Alternatively, we can remove the gain slider, and simply use a multiplier and a slider seperately. However, again these need to both be scaled to 0-1. Similarly we could place a 'scale' object in between two 'flo.number' boxes. We found that often the reason that a Max patch isn't working is due to an integer and a decimal number box being used together. These two forms of number box can not work together and therefore must never be matched. 

We then began learning about the object 'multislider'. This is the same principal as a single slider, except that, as the name suggests, it can have as many individual sliders as the user requires. In order to keep track of these multiple sliders, we can use the 'slider style' setting to change the colour of each slider and make our patch tidier.

We then learnt about 'pack' and 'unpack' objects. Unpack objects are very powerful and useful in a patch as they send whatever information comes in, out in all its individual parts. We use the unpack object with the multislider to define each sliders level and output. If we are using integers rather than flo.numbers, then we have to change the unpack object from 'f's' to 'i's'. This can also work the opposite way with the 'pack' object. However, with the pack function, we need to use a button control so that the sliders are able to move seperately from one another. 

The 'Umenu' object allows the user to put text or numbers into a box on their patch. Each object in a patch can have an individual name by changing the scripting name in the Inspector. This allows the user to keep on track of their patch, especially if there are multiple mulitsliders being used. Another key technique used for tidying patches and making them look more professional, is the use of the 'Encapsulate' feature. This basically creates a sub patch of anything selected which you can then name.

This week's session was very useful and I look forward to starting work on my own individual project, as I start to create my own guitar effects patch.