Lilli Wessling Hart

Inspired by a Facebook post from Max user Gary Lee Nelson, we are going to start an "Object of the Week" series in our newsletter tomorrow.

Gary has made the first installment especially useful by contributing an example patch for everyone.

SMSetclockConductorShare.maxpat.zip

We would be thrilled if other Max users want to participate, too. Submit your idea here:

Gary has made the first installment especially useful by contributing an example patch for everyone.


We would be thrilled if other Max users want to participate, too. Submit your idea here:
https://goo.gl/forms/WDwliQJnTvUM5q9O2 

Inspired by a Facebook post from Max user Gary Lee Nelson, we are going to start an "Object of the Week" series in our newsletter tomorrow.


new-"object-of-the-week"-series-on-the-newsletter

I mean: are externals admitted if Max users suggest them?

@Roald this 'Object of the Week' series will only be about vanilla objects. That way we can ensure that all users have them.

i could contribute my book about the bogus object.

For tomorrow's newsletter, PHIOL recommended 

. He gave me a patch that I am sharing here with his permission.

About it, he said "This example was done for my almost my 1.5 year old  son (Charlie) whom would always smash my ascii while I was patching. So I built him a patch using poly~."

charlie's piano.zip

For tomorrow's newsletter, PHIOL recommended poly~. He gave me a patch that I am sharing here with his permission. 

 object for tomorrow's newsletter and here's his patch.

OOTW_mtof (1).zip

Max Gardener suggested the mtof object for tomorrow's newsletter and here's his patch.

It's a good one! Note that the object is [mtof~], not your typical [mtof].

He gave me a replacement using both, so I updated the attachment.

Interesting series. How about making this post a sticky? I think a lot of people would find it useful.

Thanks for the feedback, Paul. Eventually, I may clean up the thread and turn it into an article. Not all people submit a patch with their suggestion, so I'm waiting to see how the project evolves.

You're welcome Lilli. And an article would be even better.

) kindly shared the attached patches and provided this explanation:

"It's a pair of patches, one to send MIDI, one to receive it.

Requires a DAW to output MIDI using a MIDI channel to Max's MIDI In port, and requires the CNMAT Externals pack to create OSC Packets.

The patch was intended to create a live A/V set, where the audio computer may be on stage, and the visual computer can be controlled remotely with MIDI.  The idea behind having Ableton output MIDI was to sync visual cues (Max/Jitter) to audio cues.

The patch can easily be modified to control something like Resolume, as long as the user adds a noteout and ctlout object to the receive patch.

I plan to add Ableton Link functionality eventually."

MIDI over Network Test 4.4.17 RECEIVE.maxpat

MIDI over Network Test 4.4.17 SEND.maxpat

Next up! George Antonios (https://georgeantonios.com/) kindly shared the attached patches and provided this explanation:
"It's a pair of patches, one to send MIDI, one to receive it.

I'm using MIDI over ethernet a lot but may i ask what could be seen as a newbie question ?

What is the real purpose of the 'OpenSoundControl' object ? i mean, sending plain text through udpsend works just fine.

i've got a setup on stage involving sending text messages to MadMapper and MagicQ, but not using any of the OSC formatting objects, only udpsend.

I'm using MIDI over ethernet a lot but may i ask what could be seen as a newbie question ? 

What is the real purpose of the 'OpenSoundControl' object ?  i mean, sending plain text through udpsend works just fine. 

i've got a setup on stage involving sending  text messages to MadMapper and MagicQ, but not using any of the OSC formatting objects, only udpsend. 

Actually a DAW isn't necessary for MIDI. There are a number of utilities that can do it, the longest renowned being midi-ox, although it's yokes are difficult to get working on modern machines, and now I prefer loopmidi by tobias. There's similar things for macs but Im no expert on that. Thanks for the tutorials )

Actually a DAW isn't necessary for MIDI. There are a number of utilities that can do it, the longest renowned being midi-ox, although it's yokes are difficult to get working on modern machines,  and now I prefer loopmidi by tobias. There's similar things for macs but Im no expert on that. Thanks for the tutorials )

i'm not sure you were replying to me, but i send mostly non-MIDI messages through ethernet. 

As for MIDI over Ethernet, it's natively included in OSX and is quite unpopular for no reason. It's working perfectly and so easy to set up. On Windows there is rtpMIDI that i also use on stage alongside rtpMIDI.

Thanks Ernest, 
i'm not sure you were replying to me, but i send mostly non-MIDI messages through ethernet. 
As for MIDI over Ethernet, it's natively included in OSX and is quite unpopular for no reason. It's working perfectly and so easy to set up.  On Windows there is rtpMIDI that i also use on stage alongside rtpMIDI.

This week, Chuck Bettis shares his simple "Touch The Sound" patch where he demonstrates how he typically utilizes 

TouchTheSound-Bettis.maxpat

This week, Chuck Bettis shares his simple "Touch The Sound" patch where he demonstrates how he typically utilizes pictslider. 


Hey, thanks for making me think about it. Now I can run yofiel synthcore on one machine and opengl husserl 2 on the other. Gone are the days of tos links. It used to be a nightmare in time and money to set it up, I just even didnt think about it before. Thank you very much!

Hey, thanks for making me think about it. Now I can run yofiel synthcore on one machine and opengl husserl 2 on the other. Gone are the days of tos links. It used to be a nightmare in time and  money to set it up, I just even didnt think about it before. Thank you very much! 

OSC is simply a standard protocol using the underlying transport. Unfortunately the uptake, especially among hardware manufacturers, was limited. Personally, I'd rather use a standard than reinvent YAW (Yet Another Wheel).

Sorry if i'm dumb, but what do you consider the standard, OSC or UDP ?

i'm just saying, i'm sending plain udp to madMapper and MagicQ, which are supposed to listen to OSC formatted messages, and it's working perfectly. I don't get the bonus (and the difference) of OSC over UDP.

Sorry if i'm dumb, but what do you consider the standard, OSC or UDP ?
i'm just saying, i'm sending plain udp to madMapper and MagicQ, which are supposed to listen to OSC formatted messages, and it's working perfectly. I don't get the bonus (and the difference) of OSC over UDP.

Isn't it because UDP objects in Max include some OSC features directly?

UDP (User Datagram Protocol) is one of the basic underlying internet transports, formalised in 1980 I think. It is light-weight and connectionless, unlike TCP for example. OSC (Open Sound Control) is a content format designed in 1997. It might use UDP as the underlying transport, or might not. The two are totally different kinds of things! Example: JPG is the image file format, but HTTP is the internet transport that delivers it to your web browser.

The confusion comes in the Max implementation. As Roald says, Max decided the UDP object should format messages using OSC semantics. But this is in no way required by UDP. It just means that for the most part you can use the Max objects as if they were OSC objects. (This follows my YAW principle.)

I note also that the Max help panels for [udpsend] contain incorrect info.

 UDP (User Datagram Protocol) is one of the basic underlying internet transports, formalised in 1980 I think. It is light-weight and connectionless, unlike TCP for example. OSC (Open Sound Control) is a content format designed in 1997. It might use UDP as the underlying transport, or might not. The two are totally different kinds of things!  Example: JPG is the image file format, but HTTP is the internet transport that delivers it to your web browser.

The confusion comes in the Max implementation. As Roald says, Max decided the UDP object should format messages using OSC semantics. But this is in no way required by UDP.  It just means that for the most part you can use the Max objects as if they were OSC objects.  (This follows my YAW principle.)

 is the feature this week with a patch provided by Cherif Hashizume. He said his patch uses 

 object with customisable root frequency for the key and scales.

PitchTable.maxpat

Coll is the feature this week with a patch provided by Cherif Hashizume. He said his patch uses coll to replace the mtof object with customisable root frequency for the key and scales.


Raphael Radna has the spotlight this week with his suggestion for

. He said that the attached patch is a "simple primality test that demonstrates one of my favorite uses of zl: as a collector for lists of indefinite length."

RR.primeTest.maxpat

Raphael Radna has the spotlight this week with his suggestion for zl. He said that the attached patch is a "simple primality test that demonstrates one of my favorite uses of zl: as a collector for lists of indefinite length."


Hi all! This week I get to share how much I love groove~ - the little playback object that helped me dream up a lot of my work in Max/MSP, and one in which I discover new uses all of the time! 

Groove~ has been my gateway to all kinds of creative explorations in buffer~ playback, but the loop length, direction, and speed controls are most inspiring to access. I use groove~ and these access points for simple sampling, building reversed and/or pitched delays, and granular synthesis!

This patch features a simple piano motif with a chorus of groove~, playing back at various speeds and directions. By interacting with the time stretching and formant shaping options - you can easily create wonderful ambient vibes. By interacting with the directions and speeds, you can get wonderful chimes from the piano loop.

You can open the collective file (.mxf) or the .maxpat. If you want to play, open the collective, if you want to customize (please do!), use the Max patcher. The included piano loop is just one idea - drop your own samples into the playlist~ !

Hi all! This week I get to share how much I love groove~ - the little playback object that helped me dream up a lot of my work in Max/MSP, and one in which I discover new uses all of the time! 

Groove~ has been my gateway to all kinds of creative explorations in buffer~ playback, but the loop length, direction, and speed controls are most inspiring to access. I use groove~ and these access points for simple sampling, building reversed and/or pitched delays, and granular synthesis!

This patch features a simple piano motif with a chorus of groove~, playing back at various speeds and directions. By interacting with the time stretching and formant shaping options - you can easily create wonderful ambient vibes. By interacting with the directions and speeds, you can get wonderful chimes from the piano loop. 

 and offers a fun, little example patch for everyone to try out. Take a look!

time_dependent_delay.maxpat

This week, Tobias Reber suggests thispatcher and offers a fun, little example patch for everyone to try out. Take a look!


Maybe it is not the line worth, as it is too easy but how can I integrate the *.maxpat patch to M4L?

My problem with M4L is twofold. First, even Live 10 will not support multithreading in poly~ objects. Second, M4L objects are limited to one (1) MIDI channel, two (2) audio channels, still will not support MPE in v10, and still only support one (1) MIDI channel on REWIRE. What's meant to be the resolution? Using SysEx messages for MIDI channels? There is no way to use multiprocessing with more than two audio channels or more than one MIDI channel.

My problem with M4L is twofold. First, even Live 10 will not support multithreading in poly~ objects. Second, M4L objects are limited to one (1) MIDI channel, two (2) audio channels, still will not support MPE in v10, and still only support one (1) MIDI channel on REWIRE. What's meant to be the resolution? Using SysEx messages for MIDI channels?  There is no way to use multiprocessing with more than two audio channels or more than one MIDI channel. 

@ERNEST in Live 10 there is no limitation anymore with audio channels

He means you can access multiple (more than 2) ins/outs in max audio devices in Live 10.

Well, I guess it would be possible to build some complex rack with loads of sends and receives between the bits if you want more than one MIDI channel, but it still doesn't support multiprocessing, and none of the audio I/O options to an standalone Max app provide more than 1 MIDI channel and two audio I/Os regardless. At least on Windows 10.

@ERNEST in live 10 and max 8 you can send and recieve multiple audio tracks between devices as I pointed before . Just by using plugin~ 1 2 3 4 5 6 7 8 and plugout~ 1 2 3 4 5 6 7 8

Thanks for the clarification, and I haven't seen the information elsewhere, so I'm especially grateful. but it still doesn't help me, as my design requires parallel processing, and there is no interface to external devices which supports more than one MIDI channel and 2 audio I/Os.

Hello everyone. It's my turn to share one of my favorite objects. It's a somewhat hidden gem that's part of jit.mo package, called jit.time.

The jit.time object has a few different variants (settable via the @mode and @function attributes), but one of the most fun is jit.time.perlin. Something I love to do is chain a few jit.time objects together, where the output of one affects speed and scale attributes of others. You can quickly and easily get some interesting motion with little patching. By default jit.time syncs to the render context frame swap, but you can disable that via the automatic attribute (and of course you can use these objects for any object parameters, not just video objects).

If you haven't already, open up your Package Manager and install the jit.mo package, then check out the attached patch.

jit.time-patch.maxpat

Hello everyone. It's my turn to share one of my favorite objects. It's a somewhat hidden gem that's part of jit.mo package, called jit.time. 

It's been awhile, since we had a patch to share for this series. Thanks to Arne Eigenfeldt, we now have one for 

 - his suggestion for Object of the Week!

deferlow_example.maxpat

It's been awhile, since we had a patch to share for this series. Thanks to Arne Eigenfeldt, we now have one for deferlow - his suggestion for Object of the Week!

Simon Lysander Overstall bringing a new patch to the table with 

 this week--useful as a GUI for probability distributions in stochastic processes.

ootw-table.maxpat

Simon Lysander Overstall bringing a new patch to the table with table this week--useful as a GUI for probability distributions in stochastic processes.

jit.gl.asyncread example.maxpat

With Max 8 we've improved the default behavior of 

 to perform up to twice as fast as Max 7, and have added the ability to readback from any texture source.

Alaghast shares his appreciation for jit.gl.asyncread with a patch!

And we share some news: 
With Max 8 we've improved the default behavior of jit.gl.asyncread to perform up to twice as fast as Max 7, and have added the ability to readback from any texture source.

New "Object of the Week" series on the newsletter