bronzebygold

Quasi-Granulizer is not a granular synthesizer, but it works on similar principles. Quasi-Granulizer slices buffered audio into large grains which can be repeated at random (but constrained) intervals through seven “banks” of polys. While granular synthesizers generally use grains only a few milliseconds in length, Quasi-Granulizer is designed to generate grains of a few hundred to a few thousand milliseconds in length, creating interesting textures and ambient sounds.

This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/


quasi-granulizer

Quasi-Granulizer

alessio

granulator is a bang-based Max/MSP patch for real-time granulation of audio files. Every single bang message generates a grain by sending values to a 16 instances poly~ object.


santini-granulator

Granulator

tmhglnd

This is a monophonic waveshaper bass synthesizer I programmed in Max 7. It can be used as an abstraction or bpatcher. The shaping is done by using the jit.bfg object. You can select a slice of the 3D plane that displays the basis function with the slider. The slice is then used for waveshape distorting an fm synth made with sinewave oscillators. The selected slice of the plane gets windowed (so the sample always starts and ends at 0 for smooth transition) and is stored in a buffer. I use the poly object to give it a 4x upsampling to get rid of a lot of aliasing. It has 2 ADSR's, one for the FM modulator and off course one for the complete instrument sound. While it is monophonic it will remember your previous played notes and velocities when still holding on and pressing an extra key. On release of the new key it will slide back to the previous (still held) note.

This is a monophonic waveshaper bass synthesizer I programmed in Max7. It can be used as an abstraction or bpatcher. The shaping is done by 

th-bfgwaveshaper~

th.bfgWaveshaper~

Ernest

Polyoice Duo expands on the Polyvoice LRU allocator by providing two independent channels in one poly~. Any number of notes can on either channel, and each channel plays a different sound in the same poly~ object. Changes to synth channel parameters change the notes on the same channel, but not on the other channel.

 - Version 2a, 1pm 10/24/2013 - Cleaned up presentation and added notes.
-- 11/25/2013 - Redesigned in Ula for future expansion. Please see the Yofiel Website to find descriptions of object repurposing  for other designs.


polyvoice-duo

Yofiel Polyvoice Duo

Chris Vik

 - draw characters into a matrix with [jit.gl.text] and [jit.gl.node] 

 - sort the characters by brightness using [jit.submatrix]

 - draw different characters based on brightness using [jit.gl.text] within [poly~]

 - sample sections of a matrix to composite a [jit.gl.texture] and draw onto a [jit.gl.mesh]

selfie-sunday-tutorial-week-002-webcam-to-ascii-3-part-tutorial

Selfie Sunday (tutorial) Week 002 :: Webcam to ASCII (3 part tutorial)

Les Stuck

Ever wanted to play multiple notes (voices) of your synthesizer or sampler at the same time?  In Max, this is accomplished by using the poly~ object. In this video tutorial, we'll get you up to speed on how to use poly~, so you can start making your own polyphonic instruments.

How poly~, adsr~, and thispoly~ work together.

Cycling74 Max/MSP/Jitter Tutorials: Polyphonic Synth

poly-synth-tut.jpg

polyphonic-synthesizer-video-tutorial

Polyphonic Synthesizer Tutorial

Emmanuel Jourdan

Converting a "pluggo ready patch" into a "poly~ abstraction"

A common concern for many advanced Max users is the ability to load new sound modules into a running MSP patch without causing discontinuities in the sound. Many people worked around this by creating Pluggo plug-ins of their sound modules that could be loaded dynamically inside the vst~ object without breaking up the signal in the main patch. Another feature of the Pluggo engine was that it automatically generated the handy "egg-slider" GUI from the parameters specified in the patch. As exporting plug-ins is not currently available for Max 5, we will look at another alternative in this article based on a new feature of the poly~ object, which allows you to dynamically load new abstractions without recompiling the DSP. To help users explore this new alternative, we will demonstrate different ways to convert a Pluggo-ready patch made with MaxMSP 4.6 into a patch that you can load as a poly~ abstraction. Using the scripting capabilities of MaxMSP, we will also see how to automatically generate a Graphical User Interface for the newly converted poly~ abstraction. As this is a fairly advanced tutorial, you may need to consult the documentation browser for more details about the concepts and techniques involved.

Click here to download the patches used in this tutorial.

Before starting, it's important to have an idea of how a Pluggo-ready patch (henceforth referred to as PRP) typically looks. It usually looks like a more or less normal MSP patch with three special elements:

plugin~/plugout~ objects represent inputs/outputs of the plug-in (instead of adc~ and dac~ objects for a normal patch)

pp objects declare names and characteristics of the parameters that user can manipulate

plugconfig object stores information about the plug-in, such as the parameter programs (presets)

Click here for a large image of the patch.

The original purpose of poly~ was to load a patcher multiple times to create polyphonic synthesisers and effects. However, there are many features of poly~ that are useful for other purposes as well, especially since Max 5 was released. We will use poly~ in a special way here, to load a single instance of a patcher, taking advantage of the fact that poly~ uses a different DSP chain than the main patch. This means that it is possible to load a different patcher inside poly~ while the DSP is running in the main patch, without causing any interruption in the other processes. A typical abstraction designed to work with poly~ includes special numbered input and output objects (in~/out~ for signal, in/out for max messages).

In order to be use our PRP in poly~, a few changes need to be made. To facilitate this work, and to make the process reusable, I've included some abstractions to replace objects like plugin~, plugout~ and pp,which are typically found in a PRP. The pp objects declare parameters of our plugin for the host application. The arguments of pp give the name of the parameter, the range, the unit... With this information Pluggo would automatically create an "egg-slider" GUI for the user to manipulate the parameters. In order to automatically generate our own GUI for our poly~ abstraction, we also need to have access to these parameters. This will be done using the pp2pattr abstraction, which includes three pattr objects, one for saving the parameter (in order to make presets), two others (which use the invisible attribute) to store the arguments of the abstraction and the hidden state (in order to be able to access them from the parent patcher). Using the pattr system will give us a great deal of flexibility of control and allow us to access the parameters in a programmatic way later on.

The first step is to import our PRP and clean it a little bit (using the Edit->Scale feature). Newly imported patches from Max 4 may need a little sprucing up to take advantage of the new look of Max 5. See the video below for a demonstration.

Next, we will need to replace the plugin~ and plugout~ objects with in~ and out~ objects to expose the inputs and outputs to the poly~ object. You can replace them manually, but a much more convenient way will be to replace the plugin~ and plugout~ with plugin2poly~ and plugout2poly~ abstractions, and then using the De-Encapsulate function from the Edit menu. This will paste the contents of the abstractions into the main patcher while keeping the connection in place, which will save us some time.

Next, we'll need to replace our pp objects with the pp2pattr abstraction. To do this by hand is fairly straightforward, but can be quite tedious if there are a number of parameters to deal with. To do this simply retype the object boxes with "pp2pattr", leaving the arguments intact.

#3b: Replacing pp (regular expression is fun)

Replacing pp by pp2pattr by hand is not super fun, especially if there are a lot of pp objects. One way around this is to use a Regular Expression (aka Find and Replace) in your favorite text editor. One benefit of the new text-based file format in Max 5 is that it's easy to use intelligent text search/replace to alter patches. Let's have a look at what we will need to change first. A pp object looks like this in the Max File Format (it's an extract of the patch):

"box" :             {
"maxclass" : "newobj",
"text" : "pp 1 Gain -1. 1.",
"patching_rect" : [ 478.881042, 294.241638, 86.892197, 19.0 ],
"id" : "obj-34",
"fontname" : "Arial",
"numinlets" : 1,
"numoutlets" : 3,
"fontsize" : 10.623105,
"outlettype" : [ "", "float", "" ],
"save" : [ "#N", "pp", 1, "Gain", -1.0, 1.0, ";", "#PP", "text", "The level of the input signal", ";" ]
}What we want is the following:

"box" :             {
"maxclass" : "newobj",
"text" : "pp2pattr 1 Gain -1. 1.",
"patching_rect" : [ 478.881042, 294.241638, 86.892197, 19.0 ],
"id" : "obj-34",
"fontname" : "Arial",
"numinlets" : 1,
"numoutlets" : 3,
"fontsize" : 10.623105,
"outlettype" : [ "", "float", "" ]
}In the second example, the name of the object has been changed and the last line has been removed (which also means that the comma at the end of the "outlettype" line has been removed too - otherwise the file would be corrupted). We will now use a text editor that supports Regular Expressions (TextWrangler in this case) to make the replacements. Before continuing, you might want to backup your patch just in case something goes wrong or a mistake is made. Open the "Generic Effect.maxpat" patch with TextWrangler, and choose Find in the Search menu. Here's one magical expression to do the search:

"text" : "pp([^}]+),[^}]+"save".+$
This expression means that we will search literally for "text" : "pp followed by as many characters as possible which are not a } followed by a comma, and a certain number of characters which are not }, followed by the literal string "save" and everything else up to the end of that line (.+$). The replacement string is a bit simpler:

"text" : "pp2pattr1
where 1 is the only special pattern, which means replace with the first back reference (the part of the searched text in parentheses).

After hitting Replace All, and saving the file, you can now reopen the patch in Max5 to see the result of this process.

In order to construct our graphical user interface, we will need to get the arguments of the pp2pattr abstractions, which define the parameter index, name, range, etc. To see how we accomplish this, have a look at the AutoGeneration and AutoGenerationJS patches for two different methods (see below). In both methods, we will use the getclientlist message of pattrstorage to get the name of all the visible pattr objects in our patch (one per pp2pattr abstraction). From there, we can extract the name of the pattr object which stores the arguments in each pp2pattr abstraction using a regexp object. For instance, the name of the pattr in the abstraction which controls the Gain parameter has a name like: pp2pattr[8]::Gain (the number might be different). From this, it is easy to generate the name of an invisible pattr object which is located in the same abstraction (pp2pattr[8]::args).  Then we can query the current state of that particular pattr via the getpp2pattr[8]::args message to pattrstorage. The values received from the argspattr are then saved in a coll object to be used in different places in the patch. In order to manipulate pattrstorage easily, aliases of the pattr object in pp2pattr are automatically created.  It is then possible to set the value of pp2pattr[8]::Gain directly using the message Gain. A separate coll object which stores the hidden state of a pp2pattr is created based on the same technique. The regexp object is used to separate messages coming from the outlet of pattrstorage. In order to have a clean interface, we create the objects so they appear automatically in presentation mode.

In order to create the UI objects, we can send messages to the thispatcher object to create new patcher elements programmatically. We use the script newobject command to create the objects that we need. To integrate the UI scripting into our PRP, paste the contents of the AutoGeneration.maxpat file, as demonstrated on the movie below.

We can also send messages to this.patcher within JavaScript in order to create the objects. One advantage of using JavaScript here is to be able to quickly create and customize the UI. Tasks like generating many objects programmatically are often much simpler to represent using a text-based scripting language than the equivalent patch. The included js code (GUIgenerate.js) has an internal representation of each of the pp2pattr objects, and is able to automatically create UI objects that bind to the appropriate parameter in each case, setting all the necessary attributes as it goes. To integrate the UI scripting into our PRP, paste the contents of the AutoGenerationJS.maxpat file, as demonstrated on the movie below.

In a PRP, the presets are stored in the plugconfig object. When you double click this object you can see its script.  A program (aka a preset) is indicated with the setprogram keyword, followed by the program number, the program index, the program name, the parameter offset and finally the values of each parameter. For simplification reasons, the parameter offset will be ignored. The parameter values are always expressed as a floating point value between 0 and 1:

#C setprogram 4 "White Chorus" 0 0.855 1. 0.855 0.1 0.0282 0.0111 0.1 0. 0.;
The conversion we use consists in a few steps:

pasting it in a text object, so we can dump it.

extracting only the lines which contains the setprogram keyword, using regexp again ;-)

scaling the parameters to fit the real range of each one (we use the coll which stores the range of each parameter for that)

and save each preset with the appropriate name coming from the plugconfig script.

The patch Preset-conversion.maxpat contains all the items to be pasted in the patch.

In order to communicate from the outside of the "poly~ abstraction", we need to create a new input (in 3) and output (out 1). The getSet.maxpat abstraction also contains a subpatcher which communicates with pattrstorage, in order to set / get parameters. This patch is designed to be compatible with the vst~ syntax: get followed by an index returns the value of the parameter, a list of index and value, or a symbol followed by a float value sets the value of the parameter.

In order to make the patcher look nicer after resizing the window, we will change a few options in the patcher inspector:

check "Save Default-Valued Object Attributes" (this is only if you want to make sure that the patch will always look the same, no matter what the default color scheme is).

Finally, we need to check "Define Fixed Initial Window Location" in the view menu, to save the default position of the patcher window.

#7: Dynamically Loading Our poly~ Abstraction

pluggo2poly_main.maxpat shows how to load your "poly~ abstractions" dynamically using the patchername attribute. We use matrix~ in order to change the amplitude of the effect smoothly: we fade out, load a new abstraction in the poly~ object, and then fade back in. This patch also demonstrates a way of controlling the parameters from the outside of the poly~ object, in the same way as with vst~ object (with get messages, and list of {parameter, value}).

Here are a few suggestions to go further:

use a more sophisticated regexp in 3b, and you could get the text associated to the pp to display the hint of your sliders.

add randomize and evolve capabilities (would be relatively easy from JavaScript)

add a more vst~ -friendly message to get the parameters and programs name (this would require querying pattrstorage)

add a default value attribute to pp2pattr

Now that we have the tools to convert Pluggo-ready patches into poly~ abstractions, it will be pretty simple to start converting your Pluggo patches for use with poly~. Also, now that you have played around a little bit with programmatic patch creation, you can begin to put these tools to other uses with a little development. Have fun!

As exporting plug-ins is not currently available for Max 5, we will look at another alternative in this article based on a new feature of the poly~ object, which allows you to dynamically load new abstractions without recompiling the DSP. To help users explore this new alternative, we will demonstrate different ways to convert a Pluggo-ready patch made with MaxMSP 4.6 into a patch that you can load as a poly~ abstraction.

re-purposing-plug-ins-in-max-5

Re-purposing Plug-ins in Max 5

Darwin Grosse

One of the more difficult things for many beginning Max/MSP users is dealing      with polyphony.  So I thought I'd write up a few articles about the poly~ object, and help take some of the heat off of a new user's head.

One thing that is important to understand about the MSP portion of Max/MSP      is the creation of a DSP chain.  When      you create a patch containing audio functions, all of the signal-rate      objects are used to create a chain of DSP functions that will execute      once audio is activated.  In order to maintain a stable audio path, this      set of functions, called the DSP chain, is compiled at runtime, and cannot      be changed without interrupting the signal path.

Unfortunately, polyphony requires changes in the signal path.  With      a polyphonic synthesizer patch, you will only want the voices that are currently      sounding to be active (in order to save CPU usage).  Under normal circumstances,      this would require a constant recompilation of the DSP chain, which just wouldn't      be good for business.

So, along comes the poly~ object.  This object acts      as a switching router for the DSP chain.  When the DSP chain is executed,      and it encounters a poly~ object, the currently active voices      of the poly~ object are each executed - allowing the audio      path to be altered in real time.  Understanding this bit of magic is      the key to understanding polyphony in Max/MSP.

In order to exercise the poly~ object, I've created a little      patch that will drone out a number of triangle waveforms, with voices coming      in and out randomly.  The core of this patcher is found in the ppaper_sub01.pat      patch, shown here:

 Inputs and outputs: Rather than using the inlet and outlet        objects, like you would in a subpatcher, you have to use the in and out objects (or in~ and out~ for audio signals) to pass information from poly~ to the        subpatcher.  In this case, we don't have any audio coming in, so a        single in object is sufficient for our needs.  Likewise,        we only have audio going out of the subpatcher, so only a single out~ object will be used for this patch.

 The Audio Engine: Not much going on here.  A single        tri~ object produces the sound, and a *~ object scales the output level to prevent output overload.  Pretty        simple, as befits a demo patch.

 The Voice Muting System: This is particular to a poly~ implementation, and deserves a close look.  Whenever the incoming on        message is "0", the message "mute 1" is generated and        sent to the thispoly~ object.  The result is that        all of the DSP functions for a voice are turned off.  This way, we        are saving the CPU use of this instance whenever it is not sounding.         This is the great advantage of using poly~ versus just        having six subpatchers active in our main patcher.

Now that we have a "voice" subpatcher created, we need to build      a main patcher to host it.  Here is a complete "main" patch:

Don't worry about all of the initialization stuff on the left hand side for      now - instead, focus on the bottom of the patch.  Here, we've instantiated      a poly~ object with our subpatcher, and a voice count of      6 (since we will have six tones in the drone). Now let's take a look at that      initialization mess.

In order to set up each of the voices for playback, we need to send messages      to each.  When the loadbang fires (when you first load the patch), it      will send the messages in right-to-left order.  The first message uses      the "target 0"message, which tells poly~ to send      the next message to all voices.  It then sends the "on 0" message,      which turns off all voices.  After that, we target each voice for a "freq"      message that tunes its oscillator.  This sets up the voices for subsequent      playback.

The right-hand side of the main patch is the drone playback system, which      randomly turns voices on and off.  In order to see the generated messages,      you might want to attach a print object to the output of the pack message      - this way, you can see the voices as they are affected.  Turn on the      DAC~, then turn on the metro object - you      should hear the Cm13 chord blip in and out as the voices are randomly turned      on and off.

This works fine, but that initialization code is a real mess.  Wouldn't      it be cool if the individual voices could just initialize themselves?       Yeah - that's what I thought, too.  So I created a variation of the subpatcher      that uses a unique property of the thispoly~ object: a bang      message sent to thispoly~ will cause the object to output      the current voice number.  From there, it is pretty simple to make the      subpatcher tune its own oscillator.

Since no frequency information is coming from the main patcher, it is unnecessary      to route messages, so message handling becomes a lot more simple.  Of      course, all of this implies some changes to the main patch, which can be seen      in this new version:

Much simpler, and a whole lot easier to visualize.  In general, if you      have voice initialization to do, you can save yourself a lot of grief by placing      it in the voice patcher rather than having the main patcher send piles of      messages.

While this patch is all nice and fine, it sure would be more interesting      if the voice would fade in and out, rather than just appearing.  So,      placing a little logic into the subpatcher accomplished that pretty easily:

This looks a bit more complicated that you thought it might, doesn't it?       That's because of how the mute system operates: when you mute a voice, the      audio stops, dead.  Therefore, when you turn off a voice, you have to      make sure you delay the voice mute until the fade-out is complete.  This      is done by storing the 0 (using the set message) prior to starting the fade,      then having the completion of the fade-out force the voice muting to occur.       Since there is no similar fate on fade-in (as long as the voice is un-muted      prior to fade-in, everything will be OK), we don't have to worry about the      timing of the "on" message.

In order to add a bit of glass to this version of the patch, I've added a      simple digital delay subpatcher to the patch, and added a control for regeneration.       Turn on the DAC~, start up the metro and      check out the difference a fade makes.

In this initial tutorial, we've seen how to create a poly~ patch that can prevent duplication within your patch system, and save CPU      as part of the bargain.  This concept can be extended to as many voices      as you need, with only a chance in the initialization scheme to support that      expansion.

In our next tutorial, we will look into using the poly~ voice allocation mechanism for polysynth emulation, and also into some of      the details for efficient voice programming.  In the meantime, drone      away!

DSP chain: A set of objects (or, actually, the functions the represent)      that are compiled into a processing chain for realtime playback.

signal-rate objects: MSP objects that work on high-speed data.       These are called signal-rate objects, because they don't always pass audio;      sometimes, they are also used for high-definition control values as well.       Any objects that operate at signal-rate are compiled into the DSP chain.

glossary

One of the more difficult things for many beginning Max/MSP users is dealing with polyphony. So I thought I'd write up a few articles about the poly~ object, and help take some of the heat off of a new user's head.

Search Results