Max Guitar Processor, Part 5 - Revision history

Gtaylor@rtqe.net at 19:44, 6 February 2013

2013-02-06T19:44:04Z

Gtaylor@rtqe.net at 19:43, 6 February 2013

2013-02-06T19:43:22Z

Gtaylor@rtqe.net at 19:38, 6 February 2013

2013-02-06T19:38:11Z

Gtaylor@rtqe.net at 18:42, 6 February 2013

2013-02-06T18:42:04Z

Gtaylor@rtqe.net at 18:41, 6 February 2013

2013-02-06T18:41:05Z

Gtaylor@rtqe.net: Created page with "In this, the final episode of our guitar processing extravaganza, we are going to step away from making effects and focus on performance support. For a system as complicated a..."

2013-02-06T03:33:57Z

Created page with "In this, the final episode of our guitar processing extravaganza, we are going to step away from making effects and focus on performance support. For a system as complicated a..."

New page

In this, the final episode of our guitar processing extravaganza, we are going to step away from making effects and focus on performance support. For a system as complicated as this, performance support means two things: patch storage and realtime control. Thus, we will learn to create a preset system and manipulate the various on-screen controls with an inexpensive MIDI footpedal system.

[http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/GtrProc-5.maxpat.zip Download the patch used in this tutorial].

===Tutorials in this series:===
<ul>
<li><a href="http://cycling74.com/2008/07/28/max-5-guitar-processor-part-1/">Part 1</a></li>
<li><a href="http://cycling74.com/2008/09/03/max-5-guitar-processor-part-2/">Part 2</a></li>
<li><a href="http://cycling74.com/2008/11/25/max-5-guitar-processor-part-3/">Part 3</a></li>
<li><a href="http://cycling74.com/2009/01/27/max-5-guitar-processor-part-4/">Part 4</a></li>
<li><a href="http://cycling74.com/2009/01/29/max-5-guitar-processor-part-5/">Part 5</a></li>
</ul>
==Preset Handling==

The "pattr" objects manage the basics of preset handling for complex patches. This subsystem revolves around an object called pattr, which maintains the state of a control and allows it to be saved or remotely controlled. In our patch, we won't use the pattr object directly; rather, we will use the autopattr object (which creates a virtual pattr for all named objects) and the pattrstorage object (which provides for preset storage and remote dispatching).

In order to make autopattr work, we need to name all of the controls that we want maintained by the pattr system and we also must make sure that controls we want left "untouched" are unnamed. If you select a control and bring up the Object Inspector, you will see that I've named all of the appropriate controls, using a naming convention that identifies the module and control function for each UI element.

<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/gtr5-scriptname.png</img>

In addition to naming all of the controls (so they can be seen by autopattr), I've also added a textedit object that will be used as a preset name. This "no-nothing" field isn't connected to anything, but it is named – therefore acting as a place to put our patch name. Gotta have a patch name…

Once the autopattr object is in place, we also need to handle the selection and storage of preset data. That is what the pattrstorage object does. We can use a number box (in this case, with an up/down control) to select patch slots, and create messages that will store the current settings as a preset. We also need to add controls for saving and restoring the contents to a file. With remarkably little patching, we've created a complete device preset system.

<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/gtr5-midipatch.png</img>

==MIDI Control==

Another important aspect to a usable live guitar rig is MIDI control – specifically, control from a MIDI pedal board. I happen to have a Behringer FCB1010 MIDI Foot Controller, and I've integrated its use into this custom patch. I've created a simple set of functions to create a list of MIDI inputs and to select a set of control functions, then manage the MIDI input within the subpatcher called midi_handler.

Incoming MIDI information is parsed (using the midiparse object), with program changes used to set the current preset slot. In addition, I use the program change command to act as a tap tempo button, since I have set the FCB1010 to produce the appropriate messages.

The most important section of this patch, however, is the routing of MIDI control messages. I have a subpatch that compares incoming MIDI CC messages with our selected controller numbers, and only outputs valid control messages. This is then sent to a gate object, which routes the value to the correct message box (and, in some cases, a scale object that scales the values). These message boxes prepend the pattr name of a control to the value, then send this set back to pattrstorage.

The result is an automatic update to the control, based on pattrstorage's message handling! This is a little known way of controlling pattr'd controls; we use pattrstorage as a "dispatcher" of messages, and let it update the control (and the current patch setting).

One thing to watch out for, though, is that these changes overwrite the current setting in the pattrstorage preset slot. So, if you load a preset file, change a setting with the foot pedal, then save the preset file, your changes will become the new setting for that control. It's a good idea to always review your current patch when working with pattrstorage, and to separate preset creation from live performance!

<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/gtr5-fullimage.jpg</img>

==Conclusion==

I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I've included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!

Thanks for following the series, and feel free to email me with any questions or comments: <a href="mailto:ddg@cycling74.com">ddg@cycling74.com</a>. Hope to hear from you soon!</div>

← Older revision		Revision as of 19:44, 6 February 2013
Line 44:		Line 44:
	I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I've included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!		I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I've included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!

−	Thanks for following the series, and feel free to [mailto:ddg@cycling74.com email me] with any questions or comments~~: <a~~	+	Thanks for following the series, and feel free to [mailto:ddg@cycling74.com email me] with any questions or comments.

← Older revision		Revision as of 19:43, 6 February 2013
Line 44:		Line 44:
	I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I've included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!		I hope that this series have been inspirational to you. The design and execution of the final patch is particular to my performance needs, but should be easy enough to modify into a system that will work for you. I've included a file (mypresets.xml) with a few of the preset I use with this rig – you may want to start your customization by making presets of your own. But best result would be for you to take this patch, rip it apart, and create your dream guitar processor!

−	Thanks for following the series, and feel free to email me with any questions or comments: <a ~~href="mailto:ddg@cycling74.com">ddg@cycling74.com</a>. Hope to hear from you soon!</div>~~	+	Thanks for following the series, and feel free to [mailto:ddg@cycling74.com email me] with any questions or comments: <a

@@ Line 23: / Line 23: @@
 Once the <strong>autopattr</strong> object is in place, we also need to handle the selection and storage of preset data.  That is what the <strong>pattrstorage</strong> object does. We can use a <strong>number box</strong> (in this case, with an up/down control) to select patch slots, and create messages that will store the current settings as a preset. We also need to add controls for saving and restoring the contents to a file. With remarkably little patching, we've created a complete device preset system.
-<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/5-MIDI_HandlerB</img>
+<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/5-MIDI_HandlerB.jpg</img>
 ==MIDI Control==

@@ Line 17: / Line 17: @@
 In order to make <strong>autopattr</strong> work, we need to name all of the controls that we want maintained by the pattr system and we also must make sure that controls we want left "untouched" are unnamed. If you select a control and bring up the Object Inspector, you will see that I've named all of the appropriate controls, using a naming convention that identifies the module and control function for each UI element.
-<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/gtr5-scriptname.png</img>
+<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/5-InspectorB.jpg</img>
 In addition to naming all of the controls (so they can be seen by <strong>autopattr</strong>), I've also added a <strong>textedit</strong> object that will be used as a preset name. This "no-nothing" field isn't connected to anything, but it is named – therefore acting as a place to put our patch name. Gotta have a patch name…
@@ Line 23: / Line 23: @@
 Once the <strong>autopattr</strong> object is in place, we also need to handle the selection and storage of preset data.  That is what the <strong>pattrstorage</strong> object does. We can use a <strong>number box</strong> (in this case, with an up/down control) to select patch slots, and create messages that will store the current settings as a preset. We also need to add controls for saving and restoring the contents to a file. With remarkably little patching, we've created a complete device preset system.
-<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/gtr5-midipatch.png</img>
+<img>http://1cyjknyddcx62agyb002-web-assets.s3.amazonaws.com/5-MIDI_HandlerB</img>
 ==MIDI Control==

@@ Line 4: / Line 4: @@
 ===Tutorials in this series:===
-<ul>
-	<li><a href="http://cycling74.com/2008/07/28/max-5-guitar-processor-part-1/">Part 1</a></li>
+* [[Max_Guitar_Processor,_Part_1|Part 1]]
-	<li><a href="http://cycling74.com/2008/09/03/max-5-guitar-processor-part-2/">Part 2</a></li>
+* [[Max_Guitar_Processor,_Part_2|Part 2]]
-	<li><a href="http://cycling74.com/2008/11/25/max-5-guitar-processor-part-3/">Part 3</a></li>
+* [[Max_Guitar_Processor,_Part_3|Part 3]]
-	<li><a href="http://cycling74.com/2009/01/27/max-5-guitar-processor-part-4/">Part 4</a></li>
+* [[Max_Guitar_Processor,_Part_4|Part 4]]
-	<li><a href="http://cycling74.com/2009/01/29/max-5-guitar-processor-part-5/">Part 5</a></li>
+* [[Max_Guitar_Processor,_Part_5|Part 5]]
-</ul>
 ==Preset Handling==