DSP Robotics Support

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

Oh dear! During editing my reply I accidentally deleted billv’s post.
Sorry Bill!

All good...I had a feeling you didn't like me...

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.

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?