timtation

A little Javascript that opens your abstraction as bpatcher automaticly.

It does not update already connected patchcords in your existing patches wich already use your abstraction.

It does not resize automaticly if you include nested automatic bpatchers in your abstraction.


rbtnk-automatic-bpatcher

RBTNK Automatic Bpatcher

klaus filip

max-external (universal binary, max7, max6, windows)
combination of number and slider with
formatting options,
individual digit drag,
logarithmic slider and
keyboard-support
multislider optionhttp://ppooll.klingt.org/index.php/max_externals


ll_number

martinrobinson

an extended comment object implemented using jsui enabling pseudo-BBcode scripting for text layout. Updated, in particular to enable color changes.


robinson-bbcomment

bbcomment

Timothy Place

a group of signal meters built with lcd and created to be used in bpatchers. This includes tap.AquaGain~ - an Aqua themed stereo meter/slider combo pictured below.


place-signal-meters

Signal Meters

Andrew Benson

Keith McMillen Instruments recently impressed all of us at NAMM with demonstrations of a new pair of string performance devices, the K-Bow and StringPort, both of which include some very rich software applications written in MaxMSP. The K-Bow, a bluetooth-based wireless gestural controller integrated into a violin bow, has just started shipping so we thought it would be a good time to catch up with Keith and find out more about the project. I met Keith at his studio in Berkeley, CA, home base for Keith McMillen Instruments and the BEAM Foundation. When I arrived, Keith was looking over prototype boards for a new violin pickup with Joel Davel, who also designed the boards for the K-Bow. Once they wrapped up their discussion, Keith sat down and gave me a thorough tour through the technology and ideas behind K-Bow, with Max programmers Barry Threw and Nick Bonardi contributing details about their involvement in the project.

How long of a process has this been between working on the hardware and the software?  How did it all begin?


KM - It's been about three years. I woke up one day and, how all great projects start, was like, 'how hard could that be?' Of course, if you knew how hard it was, you'd never start in the first place. And then you reach a point where you can't stop. Right now to be a modern musician, you have to be a performer, programmer, and composer all at once. There are really very few people who are good at all three. I wanted to make a system that someone could walk up to, that's all been tested, and is really extensible for whatever you want to do with it.

BT - I have been involved with this project since conception. It's been three years I've been working with Keith now, including the work I did for TrioMetrik.

So did you have a detailed plan for the K-Bow, or did it evolve over time?

KM - Well I knew the gestures that I wanted to capture, and then there was an experimental stage that involved those sticks [points to some dowels with wire running down the length] and a white block, figuring out what is possible. Then I started making a few boards - the first one just had the bluetooth transceiver, the accelerometer, and the grip and hair sensor. The K-Bow now consists of two very tightly packed boards: the "emitter" which sits under the bridge and, and the bow itself which handles all the bluetooth communication. The bow circuit gathers all the sensor information, communicates via RF and IR with the emitter, makes a tidy data packet and sends it to the computer.

Was bluetooth part of the project from the beginning?

KM - I experimented with ZigBee, and at the time (3 years ago) I liked some things, but it wasn't that standardized and I was concerned about the long-term longevity of the technology. Also, bluetooth is included in every laptop nowadays so it seemed like a good place to start.

Right, with ZigBee you need a special serial interface board, and it seems to still be pretty DIY, whereas you can pick up a bluetooth dongle at any computer store or just use the laptop's built-in bluetooth.

KM - Although, a footnote, the bluetooth transceiver in your laptop is optimized for a mouse or keyboard, and the little $20 USB dongle will get you a much greater range. Also in that spirit, all of the charging hardware uses a standard USB plug found on any laptop, although it does ship with some high-power chargers as well.

That brings up an interesting technical issue. It seems like power management is pretty important in a wireless device, since you can't depend on plugging in to bus power. How much of that is built-in to K-Bow?

KM - There's 4 chips on each board that do nothing but power management. Everything runs off of a 5.6 gram Lithium Polymer battery, so there is a charging regulator, and also chips that make sure that no matter how much charge the battery has, the output voltage stays the same. The K-Bow also constantly transmits your battery charge levels to the K-Apps application, so you always know how much run time you have, and you can configure the bow for different battery performance settings. After a given amount of time of inactivity it will go into a low-power sleep mode, and then eventually power down. After it gets down to below 5% battery power, it automatically shuts down to keep the battery life up around 1500 charge cycles.

So, how did you decide to make a violin bow? Did it come out of your work with TrioMetrik?

KM - Exactly. And there is just so much information that is generated by a bow when you are performing. I had done the Zeta violins and I figured it was time to do a bow. I had also been working with Max since 1989, developing this sustainable performance system, and starting over probably four times. For TrioMetrik, our performance system ended up having about 250 user interface patches all nested, so I had a lot of material to pick from. The problem was, the only system existed in this room, so none of the players could do much to rehearse at home. Also, we were doing so much with foot controllers that it was just distracting. So, we had a need for a better performance solution, and we also needed a source of funding for the work the BEAM Foundation is doing to promote computer-based composition.

BT - There is a problem in electronic music performance which has two sides. One side is that there is no real interpretive performance of electronic musical works. There has to be a system for performers to load other composers works and replay them. The second opposing side is that western classical musicians don't have access to computer technology. We have many performers that have spent years building virtuosity on their instruments but they don't have easy access to the open sound world, and musical communication, that a computer provides. The thing about technology is that it is always the metaphor for how we view ourselves. We need a music that uses the tools of this century building upon the foundations of the past.

The KBow is a step toward solving this problem by bridging the gap between what is often thought of as the base of western composition, the string quartet, with the computer music technology that has been created in the last 60 years.

Besides you, how many other people have been involved in bringing the K-Bow to its current state?

KM - Chuck Carlson, whom I've worked with for over 20 years, wrote the firmware. He's put a lot of work into this. A lot of the patches were functioning already because they were pulled from existing projects, but Barry Threw came in and started to put it all together and making it into a consistent system. He's very persistent and patient. It couldn't have happened without him. Nick Bonardi then came on board and did all of the graphics and user interface work. Joel Davel, who you met earlier, did the circuit-board layout. All in all about ten people have contributed something.

BT - I have coded most of the software for KBow (excluding firmware), including Max patches, the custom externals, and various other parts. There are sections that were modeled after the TrioMetrik work, but many things in the KBow project also had to be rebuilt from the ground up based on earlier ideas.

What does the manufacturing process look like for the K-Bow?

KM - It's diffuse, in that the boards are fabricated in India, and then loaded in Fremont, CA.

Then, in El Sobrante, the bows themselves are built by Dan Maloney, a luthier I worked with at Zeta for many years, so the bows come back looking really nice. We also have a machinist, Jon Anderson, who builds all of these custom parts, like this titanium screw on the end of the bow that saved us 2 grams of weight. One good example of the collision of technologies needed, Dan and I had to do a month-long research project on how to glue horse hair to titanium. When the bows come back from Dan, Joel will run the quality control and I will test each one before they go out.

So, let's have a look at the K-Bow software.

KM - Well, it's a standalone application written in Max. Here is the main Application window that we call K-Apps. At the top there is a main preset recall menu. This allows you to load a whole set of presets for the entire application. Each of the windows in K-Apps also allows you to store and load presets for those settings as well.

From here you can call up the K-Data window. This gives a graphic display of all of your bow controls. All of the controls can also be calibrated by opening the Calibration window and setting minimums and maximums. You can also store different presets to accommodate the techniques required for different pieces. Some pieces are very delicate and you don't want to have to engage the full range of the sensor.

BT - The preset storage system, and the communication in this patch are all based on pattr. This allows some nice perks like being able to access any parameter in the patch at any time. The modulation screens are the best example of this - the destination menu contains every parameter that is addressable in the patch, and it is all dynamically generated. If I were to add any random new control, it would show up in the menu and able to be targeted by the bow without any extra work.

Great, so give me a tour of the different controls the K-Bow offers to a player.

KM - First we have bow hair tension - as you press the bow against the string we get a reading from that. Then, of course we have our 3-axis accelerometer that tells us how fast the bow is moving in each direction. The next thing is an infrared proximity sensor that tells you where on the bow (length) you are playing as well as distance from the bridge. There are cones of infrared light coming from the emitter that are picked up by the sensor on the bow handle. That's accurate to about a quarter of an inch. And then there is bow tilt and grip.

That's really not bad. I would expect the infrared and accelerometer data to be a lot noisier looking from my experience. It seems pretty well-conditioned.

KM - I killed myself over this. It's a 12-bit analog-to-digital converter inside of here, and there is tons of signal conditioning before it even gets there. I think there is something like 20 Op-Amps inside of the bow. When you power it on, the sensors all auto-calibrate, and the signal quality is actually really good. It's accurate to about 0.1%. Now if we open up the Time Graphs window you can see a timeline display of the K-Bow data.

That seems useful.  How do you see this working in practice?

KM - Well, it's really good for impressing people [laughter], but maybe you want to isolate which parameters are going to be useful for a particular piece. You can turn on just the X-axis for example and start playing, and then maybe you realize for that piece that the Z-axis will give you more useful information. The timeline allows you to really see what's going on with the data. It's also really useful for training or practice for someone just getting started. It can be very overwhelming to have all these controls, so we usually tell people to just start with one, make a wah-wah effect with the grip or something.

The user interface looks very cohesive, and I can't spot very many standard Max UI elements in there. Nick, what was your process like for creating the graphics?

NB - As a long time wannabe violin player, this is just another reason to tolerate my initial steps into the string world where every noise I make is reminiscent of small mammals dying. I started working with Barry and Keith in November of last year. I was brought on to design and implement the GUI initially. At that point concepts were laid down, but there was still much to be done. As the project progressed I ended up co-programming along side Barry. The most challenging part was crafting the user experience to make it both straightforward and flexible. For the graphics, Flash and the Photoshop "contact sheet" process are essential for creating custom knobs in Max 4.6. I'd usually animate everything in Flash, export a PNG sequence, then line them up using the contact sheet process in Photoshop.

So I notice all of these are continuous analog controls.  How do you handle triggers?

KM - Well, let's open up the Triggers window. Inside there you can create triggers based on the accelerometer or grip data, and you have controls for the amount of sensitivity and there is an articulation control to desensitize the opposite direction after something gets triggered. This helps keep you from accidentally triggering things. There is also a certain amount of hysteresis, like with a comparator circuit, based on the sensitivity setting. All of the data from K-Apps can also be sent over MIDI or OSC to other applications.

Okay, now that we have sensor input, what can we do with it?

KM - For example, let's open up the K-Tone window. This has a full set of essential rack effects - dynamics (using the OMX objects created by Keith), pitchshifting, filters and delays, etc. Now let's get into Modulation. This is really where all the fun happens. We have lots of these "mod-lines" where you can take any source, scale and offset, run it through a table (or create your own table), and pick a destination. One other thing that makes this more of a performance system is that one of the destinations is the 'mod-line' itself, so you can create conditional layering of your modulation. For sources, in addition to the direct sensor data we also have things like overall playing speed or movement, or gesture recognition sources. There is also a looping window and a phase vocoder that allows you to scrub through a sample using bow position as well.

One of the interesting things to me about physical controllers is how they impose or encourage a certain type of ergonomics or style of performing. Do you find in practice that people play differently with the K-Bow?

KM - It's additive. There's a way to teach, and to play stringed instruments, and there is a lot of tradition there. Since there's no way of perverting that concept, I realized I had to be additive. So players can still do everything that they do normally, but they also get a lot of extra control over their sound by mapping their bow movements to the processing controls in software.

Violinists usually pick it up and say, "Oh this is pretty light," and then they'll play for a couple of minutes and say, "it's not bad," and then after about ten minutes half of them say, "this is better than my bow!" The classical string world is very traditional, and there are certain things you just can't violate. The violin is probably the strongest icon for classical music and the bow is really part of that. My goal is to take traditional Western Classical Music and smash it into the computer age. There are some things you can get away with and some things you can't.

BT - While the first release of the KBow software is for a single performer, much of the amazing power of this technology comes from tying the data of several musicians together. When you have the up bow of the violinist affecting a filter sweep on the viola, or the bass transposing the whole ensemble...well, you have a completely new genre of music performance in which there are many more complex structures possible to compose. These are the directions we are interested in exploring with both the KBow and our upcoming products.

One thing I'm always paying attention to in people's custom performance systems is how much they have to look at the screen to perform effectively. How is this managed in K-Apps? How much of the UI is necessary for performance?

KM - Well, depending on the complexity of your setup, you might need to peek at it now and then just to get a sanity check. For this purpose, we created the K-Live window. This window gives you a summary of everything. It shows me the condition of the sensors, how much the bow is moving, which gestures are getting recognized. So you can glance at that to see what's happening and then go back to what you were doing. In this window you also get basic mixer controls so you can adjust the gain and 3-band EQ. Everything in this window is adjustable by hand, or you can assign an external controller like a foot pedal as well. Granted there are also things like the Loop window or the Phase Vocoder, where it's complex enough that you might want to keep an eye on what's happening.

Barry, what would you say were the biggest challenges in bringing all of this together?

BT - Conceptually the most challenging part when designing software like this is to strike the right balance of ease of use and power. I think with the KBow we have done a good job. Ideally, we would really like performers without programming knowledge to be able to create complex musical structures, and be able to trust the software during performance.

Technically there are four major challenges that always present themselves in projects of this scope:

One is processor usage. With any music system with many parts managing DSP is a huge concern. Making sure things that are not in use are not taking any processor cycles is the key to making the whole thing run smoothly. Second is data storage. This may be the biggest and most time consuming issue, but Max offers many tools such as the pattr system to make it way easier. We are also still in 4.6 because our product timeline just didn't match up with 5 development, however, there are more new pattr features in Max 5 that I wish I had every day.

The third issue is organization, which can be difficult with a visual programming environment. There is a certain critical mass of a Max project where if you haven't thought through your abstraction and organizational process early on you get stuck and have to rewrite some things. I don't know any good advice around this problem but experience, however our whole system is very modular. Parts can be reused very easily across applications.

It is incredibly important to have a consistent naming structure for all sends and receives, parameter names, patch names, etc. to keep the patch development manageable and maintainable. Many max programmers don't run into this issue right away because the patches are made for themselves, but another programmer should be able to approach your patch and start coding on it as easily as possible. Consistent naming is the most powerful tool to make this happen, along with documentation. We have a document in flux that lists of all the hundreds sends and receives in this patch, where they go, and what their purpose is.

Well, I'm impressed by the complexity of the system underlying this seemingly friendly interface. It seems like you could just keep digging deeper and deeper to get what you want.

KM - I look at it like this. First off, if we sold a bow that worked great, with no software, that would be terrible. Then if we made a bow that wasn't easy to start with, that would be terrible. And also, if you made a system that after 4 years you've exhausted its performance capabilities that would be equally terrible. It's a challenge to balance all of these things, but it is really a wonderful challenge.

K-Bow Product Page on Keith McMillen Instruments Website 

Keith McMillen Instruments recently impressed all of us at NAMM with demonstrations of a new pair of string performance devices, the K-Bow and StringPort, both of which include some very rich software applications written in MaxMSP. The K-Bow, a bluetooth-based wireless gestural controller integrated into a violin bow, has just started shipping so we thought it would be a good time to catch up with Keith and find out more about the project. I met Keith at his studio...

an-interview-with-keith-mcmillen

An Interview with Keith McMillen

Gregory Taylor

As a Max programmer, I spend quite a lot of time making patches that some people might find a little odd; rather than a large "instrument" that I toil over at great length or "the patch is the piece" outings, I love to make Max patches that don't make any noise or play any movies or create OpenGL scenes. Instead, I make things that are generative - working from the idea that Max is really just about messages, numbers, and lists and how you move them about; I love creating ways of generating and organizing variety, and then exploring what those generative structures do when hooked up to audio or video or other outputs.


LFO Tutorial 1: The Zen of the Silent Patch

Just as there are always several ways to do any given thing in Max, so there are several different ways to end the sentence, "One of the cool new things in Max 5 is...."

One of those things that piqued my interest is the ability to specify time in Max in ways that make so-called "musical" sense; in addition to creating metronomes that send out a bang every 100 milliseconds, you can now work with lots of new and interesting ways to specify time: ISO 8601-format hh:mm:ss.ms-style time, samples, "ticks" and note values. There's a long list of objects you can work with (you can find that list here,  both older Max objects as well as some new objects that help you take advantage of them (timepoint, when, and combine).  While lots of people are interested in using the new Max 5 transport object to arrange and trigger events in time, I'm personally a lot more interested in the ability to synchronize processes in Max using time values that resemble musical note values to create control structures that can be easily time synced.

This may be because I have a deep and abiding love for some of the interesting and esoteric control voltage uses of the LFO (Low Frequency Oscillator) in traditional analog synthesis. I'm thinking of analog modules like this - a cool set of LFOs that can be combined to achieve interesting effects (Anybody want to sell me a beat-up old AKS Sythi on the cheap?  No? And you wonder why I patch...). The great thing about Max is that you can produce the Max equivalent of these great general-purpose modules, and use them in any way you want. In fact, I'll often create patches like this and then spend the next few weeks hooking them up to all the patches I've got sitting around to see what they can do.

This tutorial is about making one of those kinds of modules - a quartet of synchronized LFOs whose outputs I can sample individually for several kinds of data (triggers for waveform start, LFO outputs that I can sample at variably synchronized rates, and a nifty summed waveform I can use for more exotic kinds of control).

Note: The downloadable materials that accompany this tutorial contain not only the large patch I'm going to talk about making, but a number of the little steps along the way - feel free to take the pieces and tear them apart and make things that are interesting to you, in addition to following along.

Here's what I usually use to create LFOs in Max.

You might have been expecting to see a  cycle~ object here instead of the  phasor~ object. While you could certainly use cycle~ objects for your waveform output, I prefer to use the phasor~ - a Max object that outputs a ramp that cycles between the floating point values 0. and 1.0 at a rate you specify.

The  cos~ object will take the output of a phasor~ object and produce a nice sinusoidal waveform with the standard -1.0 to 1.0 output range. The nice thing about using a phasor~ is that I can also easily produce a sawtooth LFO output by adding a pair of objects that change the range of the phasor~ object's output. (For extra credit, you might think about how you could generate a triangle wave using a phasor~ as a source. Yes, I know - you could just slap a triangle~ object below the phasor~ in the patch, but I'm encouraging you to think about signal math. If that seems too easy for you, how would you produce a square wave?

Now that we've got two waveforms, what kinds of useful information can we extract for our use? Since the waveform's output is happening at audio rate, we'll need to sample its output. Personally, I prefer to use the snapshot~ object, which samples a waveform output at whatever millisecond interval I provide as an argument. I'll probably need to do some linear mapping of the resulting numerical output into a more useful range of numbers, but I'll get to that in a minute. I'd also be interested in sending a bang message every time my waveform began its cycle. The example above shows how you can do this using two simple Max objects – a >=~ (greater than/equal to comparison signal object) followed by the handy  edge~ object that detects zero to non-zero signal transitions (and vice-versa, too). Beginning Max users might wish to meditate on this pair of objects in the course of their quest for enlightenment.

But there's another good reason to use the phasor~ object to create LFOs in Max, as shown in the left-hand part of the next example.

The  rate~ object takes a phasor~ as an input source, and produces the same kind of output (0. - 1.0) time-scaled by the number specified as an argument or sent to the object's right inlet. In the previous Max 4.x world, this was the only reliable way to synchronize any two LFOs. While there's a new way to do that now (shown on the right-hand side of the patch below), the rate~ object will still be really useful, as you'll soon see.

As I mentioned earlier, Max 5 gives you new ways to specify time in Max - some of which use terminology that is more explicitly "musical”; besides the old school metronomes that send out a bang every 100 milliseconds, you can now work with different “kinds” of time: ISO 8601-format hh:mm:ss.ms-style time, samples, and the time format we'll be using in this tutorial - note values. Since I'm interested in the ability to synchronize processes in Max using time values that resemble musical note values, I’ll use note values – whole notes, half notes, etc. – to set the rate of my LFO. Here's a simple example:

This patch contains the familiar phasor~ object, but instead of using an argument to specify a frequency for the ramp, I've used different arguments to each phasor~ object (1n and (2n), and I've also added an attribute called (lock), set to a value of 1 (on). The arguments 1n) and 2n) refer to note values - in this case, a whole note and a half note (you can find a complete listing of these note numbers  here).

Each phasor~ object also has a  umenu object connected to it containing a listing of all the possible note values. By selecting a note value from the menu, I can reset the phasor~ on the fly.

But what are the phasor~ objects locked to?

In Max, a central timekeeping object called  transport is used to handle metrical timing. The transport object not only keeps track of time, but broadcasts information to any Max objects in your patch that are "listening" or expecting timing information. When we use a note value argument with the phasor~ object, we're telling the object that it will need to listen for timing instructions.

While you can add transport objects to your patch (and even have different transport objects running at different rates controlling different sets of Max objects in a single patch), Max 5 includes a handy Global Transport - a default source of timing information that is ready any time you launch Max. You can find the global transport by choosing GlobalTransport from the Max Extras menu

The Global Transport has an on/off switch (the button to the right of the word Activate", a flashing LED indicator, displays bar/beat/unit timing and temp, and a display that shows the current "position" of the transport since you've started it.

NOTE: Since these tutorial patches are time-critical, you should have Overdrive turned on when you run them. If Overdrive is off, you may find that playback gets jerky when the density of notes is high or you perform other tasks on your computer (such as opening another patch).

To see the musically time-synced phasor~ objects in action:

 Click on the Global Transport's activate button.

Once the Global Transport is running, you'll see a pair of synchronized waveforms, and you can use the umenu objects to change their relative rates on the fly.

Now that we've got a great way to product perfectly synchronized LFO waveforms, let's go back to our earlier LFO examples and add some additional functionality. Of course, since our locked phasor~ objects are producing beautifully choreographed ramp outputs, they'll also be outputting beautiful sine waves when we use the cos~ object. And while we don't really need the rate~ object to synchronize the phasor~ objects' outputs any more, it's still useful. Suppose we want to produce a nicely synchronized waveform that repeats at a period that's greater than a dotted whole note (1nd, the largest time increment we can specify using note values)? Easy - we can use our old friend the rate~ object to scale the output of the locked phasor~ objects to longer time periods.

And while we're at it, it would also be nice to be able to invert the waveform phase outputs, too. That's an easy one - just multiply the signal by a value of -1.0. The following example patch adds all of these features, and a set of switches that let us configure our output:

It's hard to stare at any number of simultaneously synchronized LFOs and not feel the urge to sum those waveforms to produce lovely new shapes, if only for the pleasure of watching them. It's easy enough to do - you just scale the output of each waveform by the reciprocal of the number of waveforms you want to sum (1/2 or .5, 1/3 or .33, etc.) and then add them together.

And for one final touch, I think I'd like to be able to sample the LFO waveform output at a rate which is independent of the waveform itself, but still synced to the "global" rate of the Global transport. In this example patch, I'm sampling the waveform output with a snapshot~ object, and using the scale object to map the waveform's output data range from -1.0 - 1.0 to a more MIDI-friendly range. That data stream is then sent to the right inlet of an int object, whose current value will be output any time a bang is sent to the left inlet of the int object. The source of that bang comes from another Max object that can take advantage of the new timing values - the metro object. I've used a note value argument to set the rate at which the metro object sends bangs rather than the more common number argument (which specifies milliseconds), so the metronome is now also outputting its bangs at a rate derived from the Global Transport.

All of these little component level solutions are used in the giant example patch called LFOur.maxpat - which, as its title implies, contains FOur different and independent LFOs. Although the patch is pretty large, it contains all the little techniques you've seen so far.

You should feel free to open up the LFOur patch and poke around “under the hood.”

Max 5 makes it really easy to create user interfaces using the  Presentation Mode.  You can find a good tutorial on it  here, and Andrew Benson has written  a great tutorial on creating interfaces, as well. Working in Max 5, I now find that using the Presentation Layer to prototype interface designs accounts for a lot of my patching time these days; the patch that you see when you launch the LFOur patch is the presentation layer arrangement I decided on. Since I've set this patch to open up in Presentation mode and show you the user interface, you’ll need to do two things:

 Click on the Lock icon in the patcher toolbar to unlock the patch;

 Click on the Presentation Mode icon to display the LFOur patch in patching mode.

(Note: You’ll notice that when you click on the Presentation Mode icon, all the UI objects gracefully glide to their original position in the larger patch. If you’re curious about how to do this in your own patchers, choose Patcher Inspector from the View menu and double click in the Setting column for the Box Animate Time setting. Typing in a large number will create the glide as you toggle between patching and presentation modes).

While you’ll probably be able to recognize parts of the larger patch from the examples above, there are some useful things I’ve added to the patch that may be less obvious:

Each user interface item in the LFOur display in presentation mode includes a hint that describes what the object displays or does, and gives you hints about how to use it. Those hints were added by entering text into the Hint area in each object’s Inspector.

I also thought it’d be useful to be able to create preset combinations of waveforms and rates, so I added support for the pattr family of objects. Although the pattr family of objects are deep and subtle, it was actually quite simple to add this to the LFOur patch in just four steps:

I opened the Inspector for each and every UI object I wanted to save as part of a preset, and entered a unique name for the Inspector’s Scripting Name setting.

 I added a  pattrstorage object to my patch and gave it a name (in this case, LFOs).

 I added an  autopattr object to my patch (which has the effect of adding all the objects with scripting names to the pattr registry automatically).

 To make storing and recalling presets super easy, I added a  preset object to the patch (and added it to the Presentation layer, of course), opened its Inspector, and entered the name of the pattrstorage object (LFOs) to the value column for the pattrstorage setting. Once I did this, I could use the preset object to load and store presets for my patch.

Of course, this patch doesn't make any noise at all, although it is interesting to play with and restfully instructive to watch. LFOur is useful because of a key idea in Max: data spaces are global; any time you have a send object sending data to a destination named "suitcase", anyreceive object in any Max patch you have open and running with a receive object that specifies "suitcase" as its source will receive and output the message. So I run my LFOur patch alongside whatever Max patch I want to use it with, and as long as I've added receive objects with arguments that correspond to the names of the send objects in the LFOur patch, I've got data to work with. In addition, I've added a few receive objects that will let you control some functions of the LFOur patch from your patch.Here's a listing of the data that my LFOur patch makes available when it is running:

 There are four outputs (named nvA - nvD) that correspond to the note values for LFOs A, B, C, and D. The messages sent correspond to what you see on the control panels for each of the four LFOs (e.g. the output is sent to an r nvA object would be 1n).

 An output named wavelist continually outputs the current value of the scaled integer values (in the range 0 - 127) shown in the moving window display.

 LFOur has a single  send~ object that sends the summed output of the four combined LFOs at audio rate to the destination audiowave. The output corresponds to what you see in the oscilloscope output.

 There are four outputs (sampA - sampD) that correspond to the most recently sampled waveform output value (in the range 0-127) driven by the notevalue sampling rate. These values are displayed above the display on the far right.

 There are four outputs (named bangA - bangD), each of which triggers at the start of the waveform's output. Each bang is displayed above the third output display.

The LFOur patch also contains several receive objects you can control from your own Max patch.

 Sending a bang with a destination L4sync will automatically synchronize all four LFOs to their starting point (0.) simultaneously. It is the equivalent of clicking the sync button located below the third output display.

 Sending a zero or one with a destination L4start will toggle audio processing in the LFOur patch.

 Sending a zero or one with a destination L4samp_on will enable or disable sampling the LFO waveform ouputs. When sampling is off, you can use the rightmost display to set the sliders to that the same value will be output every time an LFO starts its waveform and sends a bang message.

 Sending a number in the range 0 - 23 with a destination L4samp will change the note value rate at which values are reported (you might want to copy a umenu object from the original LFOur patch and connect its left outlet to the send object instead of trying to remember what numbers to send). Since the rate at which the LFO waveform’s position is sampled is not tied to the rate at which values are reported, setting different note values for the sampling will produce different sets of values = at very high samples rates [e.g. 64n], the outputs will essentially be in sync with the third waveform display.

Next time, we'll create a simple patch that uses the LFOur patch to make some noise.


I'm personally a lot more interested in the ability to synchronize processes in Max using time values that resemble musical note values to create control structures that can be easily time synced. This tutorial is about making one of those kinds of modules - a quartet of synchronized LFOs whose outputs I can sample individually for several kinds of data (triggers for waveform start, LFO outputs that I can sample at variably synchronized rates, and a nifty summed waveform I can use for more exotic kinds of control).

lfo-tutorial-1-the-zen-of-the-silent-patch

Marsha Vdovin

There's something about the kind of mind that looks for something beyond presets and conventional loops. I enjoy the mind that explores that intersection between computers and music. I'm very curious about what drives people to be artists.

Daevlmakr sells a suite of plug-ins created in Max/MSP. I was able to spend a lot of time with Vlad Spears for this interview because he lives nearby in San Francisco. I knew Vlad was a kindred spirit when I read the Daevl licensing agreement:


You must agree to Question Your Beliefs whenever you use the DAEVLPLUGS. While engaged in direct use of the DAEVLPLUGS, you are not to question the beliefs of others, only your own...

the differences between humans and other animals

the power of a single human being to change the world

(download the complete license by clicking here)

I grew up in two vastly different places simultaneously.

One was the broken land of the Akron/Canton/Cleveland triangle in post-industrial Ohio. Once a blue-collar paradise, by the time I arrived it had crumbled back into prehistory: head-high grass, dinosaurs wandering through backyards, dragonflies with 2 meter wingspans, ruined and rusting machinery overgrown by crawling vines. To this day I feel most comfortable in empty warehouses and abandoned factories.

The larger place, the place I spent most of my time and experienced most of my development, was on the inside of books. It began with fantasy and Lovecraftian horror, and then moved into science, science fiction and philosophy.

I carried my bubble of modernity and technological utopia with me everywhere. Once I was of age I made a crow's line for San Francisco and my real growing up began.

I was incredibly curious as a kid, a trait that has stayed with me. I learn just to learn. It feels good to put new ideas in my head. Everything is an experiment; every moment is a new world. Once teenage lightning struck, I found my youthful rebellion against tradition solidifying into honest iconoclasm. If it didn't make sense, I came up with new methods, like cutting most of high school to hang out in the computer labs at Akron University and Kent State. I've found a large dose of iconoclasm and wide swaths of experimentalism that are exactly called for when working with Max/MSP and Jitter. Or perhaps it's the other way around: a large dose of Max/MSP and wide swaths of Jitter when working with experimentalism and iconoclasm.

 What are some of your first creative memories? 

Lego was an early love, as was taking apart anything I could get my hands on and putting it back together in new ways. I remember being around seven years of age with a large spool of stolen black string that I used to create a web of connections between everything in my room to which it could be attached. I created a pocket universe of patterns and spatial divisions, my imagination populating it with all manner of Lego denizens and combinatory rules for moving along the threading. I knew it was finished when I couldn't escape because I'd threaded myself in. There was nothing left to do but sit in the center and enjoy the creation. Construction of imaginary micro-realities as early training for future Max/MSP development?

 Are there things, people, and experiences from your childhood that you think have influenced your creative work now? 

I was raised by the written page. I started reading early and it kept me from getting into the easier forms of trouble in an environment where trouble was the only form of entertainment.

If I had to name parental influences, I'd shout out to Robert Heinlein, Theodore Sturgeon, Roger Zelazny, Douglas R. Hofstadter. When I was nine I reached for a space opera on the higher shelves of a used bookstore. Heinlein's "Stranger In A Strange Land" literally fell from the top stacks and landed directly in my hands instead. Heinlein gave me humanism and the overwhelming realization everything imaginable is possible. If you can conceive it, it not only can exist, somewhere it already does. We are a living science fiction novel. Sturgeon taught me even our darkest impulses may have a core of love. Zelazny passed along the secret rainbow of a changing reality in every step I take. Hofstadter's "Goedel, Escher, Bach: An Eternal Golden Braid" gave me a grounding in logical tools for representing and working with the concepts and strange loops presented by the above.

It may seem strange to cite fiction authors as influences rather than musicians or programmers, but their works shaped the way I approach everything in my life, from relationships to musical composition, time planning to time travel, artistry to action, living in the moment to patching in Max/MSP.

Also, sounds of unidentifiable origin have always been a major drive. I've collected unusual audio on cassette and digital media for as long as I remember, and still have a collection of tapes from my childhood "sound hunting adventures." It's the new and unexplained which always catch my ears and imagination. When samplers were gigantic hardware beasts I remember hearing the Poke In The Ear With A Sharp Stick CD-ROM series and thinking "How did they make these sounds? It has to be some kind of magic. I've never heard anything like this before." They were so different they were singular and inspiring.

 When did you start making music (acquiring synths)? 

I am a child of the 80s. I bought a Casio SK-1 when it was released in 1985, and created songs on a Yamaha 4-track cassette deck. The SK-1's 8-bit sampling at 9.38 KHz created gorgeous grit and aliasing that was then rounded and compressed by tape saturation and the degradations of multiple bounce-downs. My sonic aesthetics were highly influenced by these processes. I still use the Casio SK-1 in every track: sometimes through layers of Daevl.Plugs or a hardware effect chain or both, sometimes bits and pieces blown into the Machinedrum, sometimes just a single hit clipped from one of the on-board rhythms... it is always in there somewhere.

Wide and never-ending... if we're talking about other musicians, I resonate with works by Brian Eno, the whole Skinny Puppy cabal, Bauhaus and its offshoots, David Bowie, Monolake, Curtis Roads, Amon Tobin. Listening to a third or fourth generation cassette copy of Eno's and Byrne's "My Life In The Bush Of Ghosts" on a big silver boom box while alone in an abandoned industrial center was a seminal experience.

My greater influence comes from the miasma of sounds we all swim through every day, what Lennon meant when he said, "I can groove to the sound of electricity in the house or the water pipes." I hear melodies in the metal on metal of the subway as we take turns at high speed. I pick up rhythms from the bangs of construction ricocheting off surfaces of skyscrapers in San Francisco in a gigantic, real world multi-tap delay. Dissonant beats of engines idling next to each other create foundations for entire works. Blendings of sky traffic with voices on the sidewalk amidst wind rattling whatever it can pick up provide endless symphonies. I could listen to the sound of falling water forever.

I have flashes where the entire world around me meshes into one song, everything in its place and in its moment.

Mid-2003 I fell in love with the sound of Abildgard's Droid-3 synthesizer. Made in the Netherlands, it's a tiny monster for making very digital, very dirty sounds. Abildgard hadn't received export permission, so the only way I could lay hands on one of these little beasts was to join the development team.

I created the Droid's Macintosh OS9 patch editor using Max/MSP. The Droid-3 has no internal sound storage, so all patches are created and stored on your computer, with edits accomplished via MIDI messages to the synth. I used Max/MSP not only to create the editor, but also to reverse engineer the Droid's binary file format and analyze sysex information. To prove I was serious in my intentions, I sent a working version of the editor to the Droid's mad scientist, David Filskov, which I had created without having a Droid in hand to test with. Max worked brilliantly for the purpose and I learned something new almost hourly in the endeavor. Shortly after, my little Droid black box arrived and I worked on refining the application. One of the joys of Max is always working with live code. If something isn't working, you don't find out during or after compiling... you know immediately.

This was also the time of my first real interactions with the Max/MSP/Jitter community through the Cycling '74 mailing list forums. This accumulated group knowledge and support available to everyone is priceless. I could not have accomplished the Droid-3 project without them.

Vlad Discusses Max/MSP Plug-in Development

 How long did it take you to learn  how to use it?  Is there a good story here? 

I had been using Max/MSP for three months prior to creating the Droid-3 editor. My initial introduction to Max/MSP was through Cycling's Pluggo suite, which I use for the twisted sonic fun it embodies. I learned about the Max/MSP sound laboratory through my Pluggo exposure and immediately dove into the deep end. I spent several weeks working through the documentation and tutorial material, chapter by chapter. It was fascinating and provided an excellent foundation for developing my own working methods. I don't sleep very often, but during my first year with Max/MSP I slept even less. When I did, I dreamt of Max patching.

The sounds of the world, the rhythms and melodies inherent in all of nature, are the sounds of chaos equations and fractal processes. It's the sound of life itself. I began using Max/MSP to explore this realm and found I could apply the uncertainty and "random" instability of these algorithms to a more sterile playing field: synthesizers and digital samples. Over three years I developed a personal toolkit filled with many MIDI mangling and digital signal processing Max/MSP patches, almost none of which had any counterparts in commercial audio software offerings.

I believe in changing the world through local changes. The first place for local change is your own immediate working environment, so I polished my toolkit and made it intuitive to control, minimal yet effective and visually pleasing to myself. This process led to the encapsulation of many patches as plug-ins, for the efficiency of using my toolkit within Ableton Live. From there it was just a small leap to releasing them as the Daevl.Plugs.

Max/MSP/Jitter is a bottomless rabbit-hole. I still don't feel I know the full capabilities of this Wonderland, even after all the above and using it every day. For me, the real key is knowing that if I can imagine it, I can likely create it in Max.

 Was there a distinct moment when your focus shifted from making music to making plug-ins? 

Spending all your time creating music-making tools in Max/MSP and none of your time actually making music is a well-known trap amongst the patcher obsessed, but I see it as part of one long compositional process. As I've been refining the Daevl.Plugs I've also been creating music and generating elements for further creation. During testing of the Daevl.Plugs alone I've amassed several gigabytes of raw materials: improvs, jams against other material, wandering compositions. I never destroy, only transfigure and transmogrify. I save everything. There are jewels hidden within the most innocuous of sounds, moments of divine madness in every 30 second or 30 minute piece. When we think about the process of writing music, we don't often consider the gestation period, the back and forth of ideas, the traveling of a trillion miles of wiring and all the circuits piping electrons around... I'm just making this part of my writing process open and available to everyone in the form of the software I'm creating.

The plan is to release two sets of plug-ins, then expand Daevlmakr into musical releases. To this end, the Daevl.Plugs have been wonderful for connecting with the larger community. In the first part of 2008, I'll have a track appearing on The Sound Machine, Ian Lizandra's good-for-whole-world project benefiting the Roald Dahl Foundation. Ian's project pairs musicians with abstract visualists, many of them also users of Max/MSP/Jitter. We connected when Ian was one of the very first Daevl.Plug users as Beta Two Agonist.

You have quite an arsenal of analog synths. Did learning Max/MSP increase your understanding of analog synthesis and your approach to programming sounds? 

I was knowledgeable in the basic principles of synthesis before I found Max, but my exposure to Max/MSP brought me to Curtis Roads' "The Computer Music Tutorial," a book which really cemented everything I knew before into a foundation for development. With Roads' book in hand and Max/MSP on my trusty PowerBook, I began experimenting with methods of synthesis I had no idea existed. Max/MSP let me concoct anything I needed to for both synthesis and analysis.

What Max ultimately moved me into was thinking of my studio and system of synths itself as a Max/MSP patch given physical form. The entire studio is in fact one massive instrument, one giant synthesis and compositional machine. I have a group of Max patches in continual growth, which sit, in the MIDI data stream just to watch, learn and then interact. My ultimate goal is to develop a "spirit in the wires" who will work with me and bring unexpectedness to the compositional process. My perfect household is one where I have no idea what's going to greet me when I open the door upon returning home. My perfect studio is just like that, only more so.

 What are some of your favorite Max/MSP objects? 

I love [uzi], the daring duo of [matrixctrl] and [matrix~] and the ever gorgeous [ubumenu]. [uzi] lets me blast data around everywhere, as fast I can. It's the ultimate power launcher outside of the audio domain. [matrixctrl] and [matrix~] because together they're a wonderful, elegant way to route signals. Non-binary mode in [matrix~] makes for smooth gain changes without clicks, something all of us want, and with [matrixctrl] as interface I just click and drag for connections. I use this pair often in my patches for the Monome 40h. They're both swanky, grid-based controller representations. [ubumenu] I use as both an interface object and as a storage place for generated lists that then become control elements farther into the patcher hierarchy.

I used to create special-purpose objects using CodeWarrior back in the Mac OS9 days. It's much more efficient to create cross-platform now in Java and JavaScript. I regularly use various objects I've coded up, like probability gates and mathematical generators. I'm also particularly fond of [jsui] for creating custom interface objects.

 Do you have particular patching styles in Max? 

1) Started messy.
2) Moved to messy with clean up.
3) Embraced segmented patch cords and sensible object placement as a paradigm.
4) Now I'm obsessive compulsive about in-the-moment, clean patching with clear signal and data flow designated by colors.
I utilize tons of comments and subpatchers containing supplementary information on the purpose of the patch, used methods and other possible but unused methods, third party objects involved, etc. This makes it easy for my future selves if deeper remembrance of the patch is needed. Part of Max's beauty is its ability to deliver fast results with a minimum of tricky work once you learn the foundations of patching. Future-proofing your patches takes longer, but I've found the time required to keep it clean and well documented now results in much greater time savings later when trying to figure out just what the me of three years ago was thinking.

 How do you interface with the outside world? Sensors? MIDI? Audio detection? 

I bring in, send out or generate control signals in many ways. I use [send] and [receive], MIDI and ReWire extensively in my own patches and musical systems for communication between themselves, hardware and Ableton Live. DroidEdit communicates through MIDI CC, in most cases paired messages to extend the range from 128 to 256 values. Balron takes in OSC messages from the Monome 40h, converts them to MIDI note on/offs, then spits them back out to whatever synthesizer is listening. Most of the Daevl.Plugs run scalable peak detection on incoming audio to trigger changes in their chaotic processes. This has turned out to be an effective way of intuitively tailoring trigger points to source audio.

I do have a dream of creating robotic musical helpers sending commands back and forth via OSC over wireless. Perhaps after the next couple projects.

You are obviously interested in sub-cultures. How do keep your edge? How do you keep from being swept into the vortex of popular and consumer culture? Myself, I find it really hard. 

I don't actually protect myself, but I do have a single tactic to create thinking space: I don't watch television. Buckminster Fuller thought television would revolutionize our educational system world around, allowing us to lift all of humanity into a new world of ability and accomplishment. Sadly, the video waves were grabbed by giants intent on mind control for profit. I haven't put network programming in my head for over a decade... one day I turned it off and just never turned it back on. Suddenly I had time again for reading, writing, making music... creation! It's amazing how many irreplaceable heartbeats a person loses sitting passively immersed in the flickering drug.

I see sub-cultures as systems of shared spaces, ways of filtering and making sense of the enormous streams of data reality sends our way. I don't keep them out, I take what parts of them I find useful or interesting and re-use them. What makes goth? What makes hip-hop? Look at drum 'n' bass: a reaction against the tyranny of four to the floor dance music, but the formula for qualification as strict drum 'n' bass was so tight it immediately opened the style up to other forms with only marginal resemblance, usually by way of an off-kilter kick or rib-rattling bassline... you'll also see those appear in techno, some forms of rhythmic ambient, rap and hip-hop, which lots of drum 'n' bass lovers here in San Francisco listen to. At what point does a track stop being drum 'n' bass and turn into another style?

I like to find those transitional zones, plant my feet inside them and examine the larger system from there. How did goth merge with the oontz of euro-trance? How did disco infiltrate industrial? Taking the system as a whole, you find not just the mechanics of stylistic evolution, but of cultural and social integration. For all the efforts of the Mainstream Music Machine to channel every one of us into segregated consumer segments to maximize profit, we still take what we want, when we want and do whatever we wish with it. Undead breakdancers pop locking to 8 bit chipcore? How did *that* happen? I'm reminded of William Gibson writing in Neuromancer, "The street finds its own uses for things."

 What lies in the future for Daelmakr and Vlad Spears? 

The lab expands, the experiment grows... it's alive!

Daevlmakr will be releasing a second suite of transmogrification plug-ins, also built with Max/MSP. There are Instrument Racks coming for Ableton Live's Simpler/Sampler, based on small monsters of the vintage synthesizer world: the Casio SK-1 and VL-Tone, the Stylophone and Texas Instrument's Speak & Music.

I'll be contributing a track as Wolf Interval to The Sound Machine project and playing gallery openings with artist Glenn Gibson using a minimal rig of the Monome 256 and a MacBook Pro running Ableton Live, Max/MSP/Jitter patches and the Daevl.Plugs. Daevlmakr will be releasing brand new audio works, and there are a couple top-secret plug-in and musical projects brewing.

I'd like to establish a patching circle skunkworks in the San Francisco Bay area, so please get in touch if you're an interested local user of Max/MSP/Jitter, Pd, Quartz Composer or Processing.

 Thanks, is there anything you would like to add? 

Giant telepathic thanks go out continually to all existing and future users of the Daevl.Plugs, The League of Extraordinary Beta Testers and The Cabal of Cunning Advisors, Brian Crabtree and Kelli Cain of Monome, David Filskov at Abildgard, the elektronic masterminds at Elektron, the distinguished denizens of the Max/MSP/Jitter forums and all the wunderkinder at Cycling '74.

 Vlad Spear's website: http://daevlmakr.com/

 Vlad Spear's interview videos by Marsha Vdovin and Ron MacLeod for Cycling '74. 

Daevlmakr sells a suite of plug-ins created in Max/MSP. I was able to spend a lot of time with Vlad Spears for this interview because he lives nearby in San Francisco...

an-interview-with-vlad-spears

An Interview with Vlad Spears

Darwin Grosse

This series of tutorials first appeared on my CreativeSynth.com website between 2001 and 2002. Due to their popularity (especially amongst new Max users), I have moved them to the Cycling74.com website. Read the introduction. 

As promised, we are going to clean up our previous synth-building patch, create some presets and, well, clean it up some more.

Output manipulation using Envelopes (part 2)

While having a Pluggo-based VST plugin is cool, it isn't quite as cool as having one that can store and recall its settings.  For most occasions, the MSP object that you will use for parameter handling is the "pp" object. (No snickering - I'm sure it stands for Pluggo Parameter.)

One thing that is a misconception is that pp's parameters have to exist in the 0.0-1.0 range.  Not true - you can tell pp what the range and type of your settings are, and pp will handle all of the translation for you.

So, to use pp, we need to lay them into the patch, connect them to our UI objects, and loop the output back to the input.  This seems to violate Max's "don't make loopbacks" rule, but pp is smart enough to stop any unwarranted looping.

All of our onscreen controls are pretty straightforward except that pesky filtergraph~.  What to you connect to what?  The best bet is to use the freq/gain/resonance outputs as separate parameters, and loop them back to their appropriate values.  Also - don't forget to set the "filter type" menu, otherwise you'll get unexpected results when you restore a patch.

Search Results