Windchimes Patch
Hi, I was wondering if anyone could look at this patch for me. I wanted to 'emulate' the randomness of windchimes, so I sampled a 5 pitched windchime into .aif format. Each note was samples 4 times so things didnt sound too 'samey'
What we have here is a patch with a slider that counts up to 50 with metro speed X set by the user. Got that? When the select box sees 0 a bang is sent. So a random bang sent every x milliseconds basically.
This bang then triggers a random note. However each 'note' is a separate encapsulated patch where the bang triggers one of four samples for the same pitch (because you dont want to hear the same sample all the time). This is then sent to the DAC.
So two problems
1. Only one windchime sample played at a time.
2. The samples dont layer!!! Each sample interuppts each other. Its annoying. How do I get round this?
anyway, thanks !
Without looking at your patch, I would suggest trying poly~.
hth,
dan
As suggested uses Poly~ or uses a seperate buffer and sample player for each
of the chimes and mix them before the dac. If you have 4 chimes then
multiply each of the outputs by .25 (reciprocal of 1/.4) so that you do
distort the output.
Just a point. If you send a patch uses segmented patch cords and comment the
code so people can read your "design" intentions.
Another point might be to use Brownian motion to simulate the randomness of
the chimes maybe modulated by some "win" noise" .
There are some good libraries for randonmness out there. My favourites are
A-Objects, A-chaos objects and Peter Castine's Litter Objects
best P
On 03/01/2008, Steve wrote:
>
>
> Hi, I was wondering if anyone could look at this patch for me. I wanted to
> 'emulate' the randomness of windchimes, so I sampled a 5 pitched windchime
> into .aif format. Each note was samples 4 times so things didnt sound too
> 'samey'
>
> What we have here is a patch with a slider that counts up to 50 with
> metro speed X set by the user. Got that? When the select box sees 0 a bang
> is sent. So a random bang sent every x milliseconds basically.
>
> This bang then triggers a random note. However each 'note' is a separate
> encapsulated patch where the bang triggers one of four samples for the same
> pitch (because you dont want to hear the same sample all the time). This is
> then sent to the DAC.
>
> So two problems
>
> 1. Only one windchime sample played at a time.
> 2. The samples dont layer!!! Each sample interuppts each other. Its
> annoying. How do I get round this?
>
> anyway, thanks !
>
Okay thanks for the replies, I am using seperate buffers already , however how do I 'mix' them before the DAC.
I looked up brownonion motion on wikipedia and it looks complicated. How would I apply it?
I will look at these librarys too
-Steve
Steve schrieb:
> Hi, I was wondering if anyone could look at this patch for me.
Please consider that those you want to look at your patch might not have
a 21" monitor. Your patch would essily fit on a 7"...
Please do the tutorials...
Please simplify your patch, so that it only contains the part relevant
to your problem...
If you look at the groove~ help file, you should be able to localize
your bugs...
(and [loadbang]->[bang]->[toggle]->[sig~] can be replaced by a single
[sig~ 1] btw...)
Elsewise the advice of Dan (wise to not look at the patch... ;-) is
correct...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
There is a brownian object in Essl's RTC library. It generates random
values that are correlated within a specified range.
On 1/4/08 10:06 AM, "Steve" wrote:
>
> Okay thanks for the replies, I am using seperate buffers already , however how
> do I 'mix' them before the DAC.
>
> I looked up brownonion motion on wikipedia and it looks complicated. How would
> I apply it?
>
> I will look at these librarys too
>
> -Steve
Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson
Quote: SteveDaDark wrote on Fri, 04 January 2008 16:06
----------------------------------------------------
> I looked up brownonion motion on wikipedia and it looks complicated. How would I apply it?
----------------------------------------------------
There are several objects that do kinds of Brownian motion: drunk and lp.pfff (from Litter Power) come to mind.
For emulating wind chimes I would be inclined to use lp.pvvv, which allows you to continuously vary the "color" of the noise/random-number-generator from white to dark black. I would certainly use something darker than plain-vanilla random (which is whitish noise) to control pan, particularly for low "wind speeds".
For what it's worth, I've cleaned up this patch quite a bit...
if i were you i'd first get rid of all those groove objects within your voices. you could easily use larger audiofiles and set the different playback locations for each chime.. using a waveform~ inspector could help you determine the sample locations.
check out the poly~ object, just to get an idea on how it sorta works; darwin grosse has a good tutorial on the synth building pages.
Quote: Peter Castine wrote on Fri, 04 January 2008 10:55
----------------------------------------------------
> Quote: SteveDaDark wrote on Fri, 04 January 2008 16:06
> ----------------------------------------------------
> > I looked up brownonion motion on wikipedia and it looks complicated. How would I apply it?
> ----------------------------------------------------
>
> There are several objects that do kinds of Brownian motion: drunk and lp.pfff (from Litter Power) come to mind.
>
> For emulating wind chimes I would be inclined to use lp.pvvv, which allows you to continuously vary the "color" of the noise/random-number-generator from white to dark black. I would certainly use something darker than plain-vanilla random (which is whitish noise) to control pan, particularly for low "wind speeds".
>
>
----------------------------------------------------
I found lp.pfff and I followed the install isntructions exactly but it says cfm external does not work in the maxmsp console. What gives?
Quote: pvillez@gmail.com wrote on Fri, 04 January 2008 04:16
----------------------------------------------------
> As suggested uses Poly~ or uses a seperate buffer and sample player for each
> of the chimes and mix them before the dac. If you have 4 chimes then
> multiply each of the outputs by .25 (reciprocal of 1/.4) so that you do
> distort the output.
>
> Just a point. If you send a patch uses segmented patch cords and comment the
> code so people can read your "design" intentions.
>
> Another point might be to use Brownian motion to simulate the randomness of
> the chimes maybe modulated by some "win" noise" .
I cant figure out Poly so I used seperate buffers, however I am still getting interrupions on some of the samples.
Here is my patch where I have replaced the random number with a brownian motion output:
Sorry for being a complete noob
Quote: SteveDaDark wrote on Sat, 05 January 2008 01:03
----------------------------------------------------
> I found lp.pfff and I followed the install isntructions exactly but it says cfm external does not work in the maxmsp console. What gives?
----------------------------------------------------
The Litter Power Starter Pack is not yet UB. I realize this is inconvenient for many, but you get what you pay for.
The Litter Power Pro Bundle has been UB for quite a while.
Best,
Peter
At 9:16 AM -0700 1/5/08, Steve wrote:
>Sorry for being a complete noob
Everybody was, at one point.
Here's a re-tooled version of your patch, although you will have to study it for a while to recognize it, I think. It's now in several pieces, and the names of the files are important. Load each of these chunks, and save them into the same directory.
This first part is the poly~ guts. It needs to be called BamBoo.pat:
This next part is an abstraction that holds the poly~ and the buffers. It needs to be called Chime2.pat
Finally, this is the top level patch, which can be called whatever you like:
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
Chris thankyou very much for making it work better. I have had a good look through it, and this is what I think:
The windchimes patch utilizes two seperate algorithms to generate realistic windchime motion according to windspeed.
The algorithm works by telling the chimes to play every X milliseconds according to windspeed set by the user. Single chime mode has one chime going at one time and individual mode has chimes triggered randomly with chimes playing at the same time.
For 'single chime mode' the concept is that a random chime is triggered every x millisceonds. The metro object is randomized by a scale 5-80 ms according to the windspeed. There is a 1 millisecond delay to avoid unwanted distortion. Every time the counter object counts to 50 a bang is sent to a 'random' object box that selects 1 of 6 chimes to be triggered.
In 'individual chime mode' the algorithm is a bit more complex. The patch works on the concept that, for a windchime to be triggered, its threshold must be able to withstand the density of the wind. If the threshold of a chime does not, the windchime sample is triggered.
The metro object is randomized on a scale of 50- 500ms. The scale is slower because there is more room for random events to take place. Every time the counter object counts to 50 a bang is sent to the 'P indivchime patch', which works as follows:
When every counter bang is sent, 6 'random' objects randomly choose a number between 0 and 99. This is the threshold of the chimes. The same bang is also sent to 6 scale boxes the recieves the windspeed, inverted inside 100 (*-1 - 100) this is the density of the wind.
The scale boxes scale this value between 0 and 99 . At the same time the wind rate tells the metro box to randomly choose a number between 0 and 99, this is also sent to the split box.
The 6 split boxes check that the wind rate value is within the density of the wind, and the threshold of the windchimes. If this is true, then the chime 'moves' and the sample is triggered.
When a sample is triggered, it does not just play one single sample. There are six different sample sets of four samples each so that the piece sounds more 'natural'
When a chime is triggered, in the chime2 abstraction the sample is sent (regardless of single chime or individual mode) a bang, and a random integer between 0 and 3 and this is sent to BamBoo.pat which is a poly patch.
NO IDEA HOW THE POLY PATCH WORKS. Can you help?
Output of windchimes has a 'onepole' low pass filter that scales the cut off frequency according to the windspeed to make gentle breezes sound 'less harsh'. Also the volume of the output is scaled so that chimes with gentle breezes are lower and gale is higher.
A delay is sent to the audio ouput to stop chimes happening out of character when the patch is loaded.
At 11:32 AM -0700 1/6/08, Steve wrote:
>Chris thankyou very much for making it work better. I have had a good look through it, and this is what I think:
I'm glad you took the time to really study the changes. You did a good job, and you're mostly correct in your analysis. A couple clarifications:
>The 6 split boxes check that the wind rate value is within the density of the wind, and the threshold of the windchimes. If this is true, then the chime 'moves' and the sample is triggered.
It's worth pointing out that the density control is really just bringing the lower range of the split up towards the upper threshold, as the density decreases. At density 0, the lower and upper bounds of split are the same, so it will only trigger for that one value.
There are so many different ways to do this sort of random triggering that it's hard to decide which one would be best. I can imagine some sort of flocking algorithm might be good here. I just wanted to provide one other alternative.
>NO IDEA HOW THE POLY PATCH WORKS. Can you help?
poly~ is a general purpose voice allocation object. The basic concept is that poly~ will create N instances of the patch given as its first argument (in this case BamBoo), based on the value of its second argument (in this case 8). You can inspect the eight different copies of the BamBoo patch by clicking on the numbers above the inspect instance comment near the poly~.
You feed the first inlet with a list of either "note n" or" midinote n v" to get it to start up an instance. poly~ sends this to the first instance that isn't considered busy. The thispoly~ object inside of BamBoo is how an instance tells poly~ that it is busy. It the case of the BamBoo patch we are considered busy for as long as the sample is sounding. If this was a synth patch, we might be busy for as long as an envelope was still active.
BamBoo uses the note value (the output from random in Chime2, in this case) to determine which of four samples to play. It changes which sample groove~ is pointing to, picks a random velocity and pan, then starts the sample playing. I also apply a small random pitch change by changing the input value to the sig~ that drives groove~ to keep it from sounding too much the same. The phase output of groove~ is used to set the busy state of thispoly~. It's worth noting that the argument to groove~ to designate which buffer to play is largely a formality, as the buffer is being changed on the fly with the set message.
I have a couple other poly~ examples on my Max examples page: http://www.xfade.com/max/examples
>A delay is sent to the audio ouput to stop chimes happening out of character when the patch is loaded.
Not quite, I've found that some delay is needed to get audio to turn on reliably from a loadbang.
-C
--
Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." - Brian Eno
Thanks, I still have to find out more about poly, ill look into it later.
I made a noise generator with a resonator object where the base frequency changes with the strength of the wind. Now you can hear the wind and it sounds really realistic.
I used a multi slider to automate the wind over time, or you can choose the option of a simple patch I did where a metro object changes the speed of the wind ever x seconds. x is a number object that is also randomized so the 'gusts' of wind change over time. I interpolated the numbers so the wind changes speed naturally.
I also put a low strings loop in with a high pass filter that reacts to the wind as well so everything sounds really creepy and weird.
I am going to edit your patch a and make it more my own, but I definitely learned from it thanks. I just need to look more into the poly objects.
Steve
Can you post these new versions of your patch? They sound interesting.
On Jan 6, 2008, at 6:04 PM, Steve wrote:
>
> Thanks, I still have to find out more about poly, ill look into it
> later.
>
> I made a noise generator with a resonator object where the base
> frequency changes with the strength of the wind. Now you can hear
> the wind and it sounds really realistic.
>
> I used a multi slider to automate the wind over time, or you can
> choose the option of a simple patch I did where a metro object
> changes the speed of the wind ever x seconds. x is a number object
> that is also randomized so the 'gusts' of wind change over time. I
> interpolated the numbers so the wind changes speed naturally.
>
> I also put a low strings loop in with a high pass filter that
> reacts to the wind as well so everything sounds really creepy and
> weird.
>
> I am going to edit your patch a and make it more my own, but I
> definitely learned from it thanks. I just need to look more into
> the poly objects.
>
> Steve
----
Steven M. Miller
Professor, Contemporary Music Program
College of Santa Fe
Home
SFIFEM
Atrium Sound Space
OVOS
CMP