Quilcom Rex Tree

Post any examples or modules that you want to share here
Post Reply
User avatar
Spogg
Posts: 3368
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England
Contact:

Quilcom Rex Tree

Post by Spogg »

Hello to my fellow FS addicts!

This is my version of a Mark Tree (also called a chime bar or bar chimes).

I love the sound and have often wanted to own one after seeing it used by Yes to add some magic sparkle to some quiet bits in Close to the Edge and so on. So, I bought a used Meinl 27 chime one. Then I got to thinking about making a plugin version, and that’s where the fun started!

To calculate the physical behaviour of many swinging and colliding chimes of different lengths was, of course, an unimaginable challenge (for me anyway). So, most of my time was spent trying to create an approximation, and the result is far from an exact physical simulation, but it might be “good enough”. Since the plugin takes this route, I decided not to call it a SIM, but instead chose to name it after its creator (me) just like the Mark tree was named after its inventor, Mark Stevens.

If anyone here can come up with a more convincing physical algorithm, I would LOVE to see it!

Download:

https://www.dropbox.com/scl/fi/49iqgcfg ... h5v73&dl=0

Video:

https://youtu.be/v-6o8HMvg2U
User avatar
Spogg
Posts: 3368
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England
Contact:

Re: Quilcom Rex Tree

Post by Spogg »

Oh dear! During editing my reply I accidentally deleted billv’s post. :oops:
Sorry Bill! :(
billv
Posts: 1165
Joined: Tue Aug 31, 2010 3:34 pm
Location: Australia
Contact:

Re: Quilcom Rex Tree

Post by billv »

All good...I had a feeling you didn't like me... :lol:
tulamide
Posts: 2714
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Quilcom Rex Tree

Post by tulamide »

Spogg wrote:If anyone here can come up with a more convincing physical algorithm, I would LOVE to see it!
I don't have anything useful to say or add, but this:

In a complex (chaotic) system like a Mark Tree, you can only go OOP. Instead of trying to keep track on why and where which pipes collide, you define one prototype. A pipe that has all the properties.

This pipe calculates its behavior based on its size and how it is influenced from outside. You then make instances of the prototype, define their differences in size and initial position and there you are. Any changes needed are only done to the prototype, since the instances automatically inherit those changes. It is still a lot of work to define ONE pipe, but once done, it can be a simulation of any size (how about 200 pipes, or just 3?)

Code-wise the perspective changes as well. Instead of you instructing everything, you create iindividual code structures that instruct each other. So that pipe 4 can tell pipe 3, that it touched it at the bottom while coming from the right (or something), and pipe 3 answers, that it was standing still, and therefore took over the moving energy. Things like that.
"There lies the dog buried" (German saying translated literally)
User avatar
Spogg
Posts: 3368
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England
Contact:

Re: Quilcom Rex Tree

Post by Spogg »

I think I get the idea tulamide but, as you might expect, such an implementation is way beyond me. I don’t know if FlowStone could manage it either.
If you ever feel the inclination to make the simulation, presumably in Ruby, I would love to add the DSP to make the sound.

The Tulamide Tree?
Post Reply