Darwin Grosse

Recipe-0201.png

image.png

02.SettingPlotter.zip

In the last two recipes, we targeted individual instances of MC objects to affect their actions. "Wrapped" MC object - MSP objects that are enclosed in an MC wrapper - respond to a number of messages that generate instance-specific behavior. The 

In some cases, it can be difficult to understand exactly what is happening with these objects. To provide more insight, we create a scaling system that can produce a visualization of the generated results.

Option-click (right-click on Windows) on a wrapped MC object to see the available options available for those objects. Among the details displayed in the help files, you will find a number of additional messages that can generate interesting value ranges.

Use the deviate and spread messages with wrapped MC objects

Use the plot~ object to visualize generated MC results

In the last two recipes, we targeted individual instances of MC objects to affect their actions. "Wrapped" MC object - MSP objects that are enclosed in an MC wrapper - respond to a number of messages that generate instance-specific behavior. The deviate and spread messages are two examples.

mc.sig~ : An MC-wrapped static signal generator

deviate and spread messages : Messages that generate value variations

mc.snapshot~ : Creates messages from individual MC channels

mc.makelist : Assembles a list from multiple channel sources

The deviate message produces values around a centerpoint with a defined deviation. In this case, the slider produces values between 0. and 1., and are sent to a message box which will cause a deviation of that value, centered around 1.0. This will cause the mc.sig~ to generate values from 0.0 to 2.0.

An alternative generation message is the spread message, which will create an even range of values between a low and high value. In this part of the patch, we make simple calculations to create a spread evenly spaced around 1.0.

The mc.plotscaler abstraction (included in the download) sets up a plot~ object, sets the number of points to the number of channels, and creates a display list from incoming MC signal values. The arguments sent to the abstraction defines the low and high end of the display range.

You can change the number of channels that are calculated, but the actual number of channels flowing through the MC patchcords will not be altered until you turn the DSP off and on again. Use the attrui object to change the number of channels while DSP is running, then cycle the DSP switch to see the change in the patch.

Learn More: See all the articles in this series 

Use MC Recipe 2 to create a scaling system that can produce a visualization of the generated results.

mc-recipe-02-deviation-and-spread

i didn't see any link to download the patch like in previous MC recipes(same thing with the recipe after this one), so i went ahead and built the patch myself, also added ability to play with the "harmonic" message for the frequency spacing:

(it was strange at first, though, seems i had to put explicit @chans arguments otherwise from "mc.*~" onward down the chain to mc.ezdac~ everything would only be one channel(mousing over the patch chords showed just a '1' instead of '35' like i thought they should automagically since "mc.sig~ 1. @chans 35" already existed at the top of the chain), after adding the @chans arguments to everything, i could then erase the arguments and everything remained with the proper amount of 35 channels afterwards)

This visualization technique along with the jit.cellblock trick in the previous recipe seems essential! Thanks for sharing 👍

(it was strange at first, though, seems i had to put explicit @chans arguments otherwise from "mc.*~" onward down the chain to mc.ezdac~ everything would only be one channel(mousing over the patch chords showed just a '1' instead of '35' like i thought they should automagically since "mc.sig~ 1. @chans 35" already existed at the top of the chain), after adding the @chans arguments to everything, i could then erase the arguments and everything remained with the proper amount of 35 channels afterwards)

This visualization technique along with the jit.cellblock trick in the previous recipe seems essential! Thanks for sharing 👍


Thanks for the heads-up; the patches were supposed to be in there, but they were missed. I've taken care of that.

Regarding the explicit @chans requirement - did you try flipping the DAC on and off again after changes? Toggling the DAC should cause the 'downhill' objects to adapt to the number of incoming channels.

But I'm glad to hear you are experimenting with the patchings - some of the additional generators (like harmonic) are pretty amazing.

ah sweet, i remember reading that somewhere, will try that from now on.

ya, these additional generator messages like 'deviate', 'spread', 'harmonic', etc. add an extra element to the whole MC wrapper stuff that I didn't expect to find, speeds up so much for me(stuff like that i found easier to code in languages like supercollider long ago(iterating through control loops), but now it's much easier in max with a simple message..... i can imagine this, in particular, being big for live-coding/fast-synth-design... very exciting :D).

Toggling the DAC should cause the 'downhill' objects to adapt to the number of incoming channels.

ah sweet, i remember reading that somewhere, will try that from now on.
ya, these additional generator messages like 'deviate', 'spread', 'harmonic', etc. add an extra element to the whole MC wrapper stuff that I didn't expect to find, speeds up so much for me(stuff like that i found easier to code in languages like supercollider long ago(iterating through control loops), but now it's much easier in max with a simple message..... i can imagine this, in particular, being big for live-coding/fast-synth-design... very exciting :D).
Thanks again!

if i input a "deviate" value which is greater than 1 I will, in the case of that patch with those values, have chances to generate values (frequencies of [cycle~] ) which will be negative (such as -0.6) - which is normal. In the case of a "normal" (non-mc) patch I would use a flonum with a set minimum (to, say, 0.01). in the case of MC how (with which object) could i set a "hard-floor" (or ceiling) ?

if i input a "deviate" value which is greater than 1 I will, in the case of that patch with those values,  have chances to  generate values (frequencies of [cycle~] ) which will be negative (such as -0.6) - which is normal. In the case of a "normal" (non-mc) patch I would use a flonum with a set minimum (to, say, 0.01). in the case of MC how (with which object) could i set a "hard-floor" (or ceiling) ?

You could use an mc.clip~ after the mc.sig~ in order to prevent out-of-range numbers. Or you could also manage the values on the input (the number going into the deviate).

Hello - very helpful tutorial, thanks. I'm working on a patch that uses [mc.tri~ @chans 8] with a spread message with 440. and 880. as the low/high. When listening to each chan individually, the 8th isn't 880, but is just flat. I have to raise the second number in the spread message to 942.9 in order to get the 8th chan to be 880. Can you explain why that is? I figured that it'd set the first chan as the lowest, then the high as the last chan, then equally distribute amongst the others. 

Hello - very helpful tutorial, thanks. I'm working on a patch that uses [mc.tri~ @chans 8] with a spread message with 440. and 880. as the low/high. When listening to each chan individually, the 8th isn't 880, but is just flat. I have to raise the second number in the spread message to 942.9 in order to get the 8th chan to be 880. Can you explain why that is? I figured that it'd set the first chan as the lowest, then the high as the last chan, then equally distribute amongst the others. 
Thanks!

Figured it out - I should have used spreadinclusive rather than spread! Awesome to have both options!

Is there a way to apply an expression to spread?

@MATT JACKSON Not sure exactly what you want to do, but you could explore mc.gen~...

Ben I ‘m already using gen~ to make a reverb. I use it because I’m more comfortable with my own hand made snippets and because I’m doing sensitive feedback calculations. Inside this feedback network, I’d like to do some complex multi-band processing (and I’m not sure how many bands I’ll need yet). I’ve made a great mc.gen~ to do the multi and stuff b but now I want to use that inside the gen~ feedback. 

I’ve heard from a reliable source that it isn’t possible. So I’m looking at other solutions.

Ben I ‘m already using gen~ to make a reverb. I use it because I’m more comfortable with my own hand made snippets and because I’m doing sensitive feedback calculations. Inside this feedback network, I’d like to do some complex multi-band processing (and I’m not sure how many bands I’ll need yet). I’ve made a great mc.gen~ to do the multi and stuff b but now I want to use that inside the gen~ feedback. 
I’ve heard from a reliable source that it isn’t possible. So I’m looking at other solutions. 

MC Recipe 02: SettingPlotter