Reaktor Group Project - 'Pinball Wizard'

I have an idea for a Reaktor Group Project.

First imagine a 2D room with an object inside that is subject to two forces - gravity and wind.
The size of the room is fixed - the walls are from -1 to +1 on each side with 0 in the center.
The object has adjustable mass (size) and surface area (i.e., a coefficient of friction).
The wind is a force of variable strength that can be directed in any single direction (vector scalar) or it could take on the properties of a vortex (circular field).

Gravity has similar properties - it is identical to wind in many respects - it can have a variable strength and direction, and also can be a vortex.

The only difference is that the coefficient of friction affects the wind and not gravity.
I'm not sure if the wind should be affected by the walls - it should be a field effect only - virtual wind.

So I can set up the room parameters and inject a ball into it and watch what happens.
The walls are elastic with a 'bounciness' parameter - some kind of elastic coefficient.
When the ball hits the wall it bounces off in a reverse angle of incidence.

This is the basic module and the location of the ball at any time can be a source of modulation.
The ball hitting the walls may also be an event or trigger source.

Using this one can make an interesting modulation source and one can copy the module to affect many types of processing parts of an audio application.

Now let's extend this to an array of such rooms - say a 4x4 grid with 16 rooms arranged in a square matrix.
Each room has it own rules of behavior - the force settings and material properties.

Imagine all the rooms are empty at first, but with a mouse motion we can start a ball up in a room (or as many balls as we like with additional mouse motions).

When a ball hits the wall, it not only bounces off, but also causes a mirror image to emerge in an adjacent room following the same extended trajectory. However, in this reflected room the ball may have different mass and friction parameters as well as the different force vectors from the room properties.

Since this may cause lots of balls to appear we need a way to make them disappear. I'm not sure what is the best way - there could be black holes in various spots or when the object slows to a crawl and stops it disappears. Or they could evaporate in the wind over time.

With all these events and modulation sources we can inject them into 16 samplers, one per room, with the sample triggered and modulated by the activity in the room.

Naturally the grid could easily be 6x6 with 36 samplers or 8x8 with 64 samplers, etc.

All these physical properties are rather simple 'physics of motion' problems with simple quadratic equation solutions (I think - I haven't worked them out). I guess they are actually differential equations and may have very general solutions in the complex plane.
I haven't done this sort of math since the 70's so I'm rusty, but I think I could work them out given enough time.

Actually, they don't need to be exact as long as they give the proper impression, but we need to get exact answers first before we simplify the solution.

There are obviously many somewhat independent parts to this that people could take on (as groups if they like).

There are graphical parts for the GUI and the rooms and lots of multipictures.

There are the rule-based event processors.

Someone has to figure out the various force equations and check the math and do some simple simulations to see what works.

Then someone has to wrap all this around some audio generators and effects processors to hear what can happen.

There could also be lots of modulation possibilities - the ability to assign many of these parameters to various stuff.

If one were really clever, these could be 3D arrays, but I don't think that is necessary - there is plenty of diversity already and no need to get that complex.

There will be some simple setups with simple sequences of events that are probably periodic or mostly periodic with variations, and many setups would be totally chaotic.

I think there would many musical possibilities that could come out of this.

Any thoughts?


PS - feel free to offer a better name than 'Pinball Wizard'.
---
Some last minute additions:

When gravity is operating as a vortex - it is a black hole - so the balls disappear when they hit the center (and go faster till the reach the event horizon?)

Balls can interact with each other by bouncing off, but perhaps we can start off with no interactions and see how hard it would be to add a collision detector.

 

Cool idea, only thing is that it seems quite math heavy, and my knowledge in that field is rubbish.

Maybe you could make the balls disappear by type definition? One fading away like a delay, one interacting only for a given number of times (glitch-y), one that pitches itself out of existence (from a human perspective at least), etc.

 

i am knee deep in a very large project right now, so this is a little big for me to implement at the moment. we could, however, map out what it would look like... i'd suggest, first off, that we figure out what parameters we want each ball to have, how many balls each room can fit, how many rooms total and how much interaction should they have with each other (i vote for none, honestly), etc.

for example, each ball needs:
x position
y position
x velocity
y velocity (or if you prefer[i don't], velocity angle and velocity magnitude)
radius/diameter
friction coefficient

each room needs
an array of ball objects [max 128 or whatever power of 2 is deemed appropriate]
gravity direction and depth
wind x velocity, wind y velocity
wall elasticity

any other behavior that wants to be implemented should probably be part of the plan from the start because a project like this can easily collapse on it's own weight in reaktor.

 

Math experience not necessary, someone could work these out.
Probably this will be the easiest part because it's just a bunch of equations in a macro.

 

yeah a lot of simple collision stuff is just inverting velocities. you can build it in such a way that a new macro could be placed to implement new features such as friction, as you go.

 

I guess 'ball' is a good name for the objects, but I imagine they could be models for metal ball bearings as well as cotton puffs based on mass and friction coefficient.

And 'room' is a good name for the basic module in the grid.

I agree that ball interaction is not necessary and adds too much complexity.

There are few other parameters:

For the 'balls':
Mass (for the gravity interaction and wall bounce; the friction coefficient is for the wind).

For room:
The wind parameters - force and direction.

Also for room:
How do balls disappear? By time, by bounce counter decrements, by evaporation in the wind (snowballs)?

As for number of balls, I would propose 1024 for the array size. That would allow each ball to be assigned a voice if it is thought useful. I think 1024 is the maximum number of voices.

I like the idea of a vortex force field - a tornado of wind or a black hole of gravity, it could be an option of the type of the forces. The two forces are either typed directional attraction (gravity gradient), spinning attraction (gravity vortex - black hole) OR direction repulsion (wind gradient), spinning repulsion (tornado).

However, this might be too complex. I imagine calculations are vectorized or parametrized so it's a 'simple' method of swapping equations.

What I don't know about is how to best do the calculations - they need to be updated at least at the display rate - 24 Hz or whatever that is. So 24 times a second every room has to be updated for the display to work smoothly.
Faster than that may be better if CPU is not a big deal. The event control rate (400Hz) is probably fine.

So we could use either the event clock or the display clock (maybe allow either option for CPU reasons or perhaps switch from one to the other when the ball count gets very high). This clock would drive all the update mechanism that take in the room arrays and update their values. After the update, the arrays are displayed. I suppose that means two arrays are needed, one to hold the display and one to do the update, then they get swapped each cycle.


So I would have this list of parameters:

Global:
Clock rate (display rate, event rate, or switched based on ball count).
Ball Count Threshold - used to switch the clock rate mechanism when total number of balls reached this amount.
Room grid dimensions: (x by y), probably 4x4
Zoom factor to scale the room grid array display

Per room parameters (each room may have different forces and masses):
Room [i,j]:
The array, size 1024, that holds the balls dynamic data: direction vector, dissipation value (ball is deleted when this is 0)
Wall elasticity
Ball mass (gravity, attractive force component)
Ball friction (wind, repulsive force component)
Wind force vector (directional: linear or radial)
Gravity force vector (directional: linear or radial)
Dissipation type: How do balls disappear - never, by time, by bounce, etc.

Then there is the initialization issue - how do we set up the initial balls - mouse click and drag to set starting velocity and direction?

Then there is the bouncing issue: when a ball hits a wall, the adjacent room inherits that ball's velocity and location, but not it's mass or coefficient of friction.
A ball hits a wall whenever it's x or y position first reaches +/- 1.

Using floating point, we need to be concerned about comparisons, we always compare for equality of a and b by using |a - b| < delta, where delta is a small number.

If you think of this as a vector field, the particles in each room are subject to two forces - one of attraction and one of repulsion.

If you look over your old Calculus book on Vector and Parametric Equations you will see how to convert these forces into localization details.

For example, if gravity is a constant and only pointing down (in our case it isn't) and there is no friction (no wind or repulsive force) the equation is:

F = d(mV)/dt

If mass doesn't change (in our case it will), we get these simple equations:

Initial conditions (v0 - initial velocity, alpha - initial angle of trajectory)

dx/dt = v0 * cos (alpha)

dy/dt = v0 * sin (alpha)

Force due to gravity in the x direction is 0, but in the y direction it is F = -mg.

So when you solve these you get

x = (v0 cos (alpha)) * t
y = -.5*g*t*t + (v0 sin(alpha))*t

Our case is more complicated because both mass and gravity are not constant or directed like that. The direction issues can be fixed by a rotation of the co-ordinate system so that gravity points downwards, that will probably add a sin and cos term to x and y for gravity's direction. The mass part is not relevant because mass always divides out of these equations - it is on both sides so it falls away. To solve the vortex issue, conversion to polar co-ordinates will simplify the equations.

If you set up the equations for repulsion, they will probably be similar if we reverse signs and think of wind speed as gravity and the coefficient of friction as mass, we should get a similar result.

So the final location would just subtract these two results for x and y.

With a few days of thinking and reviewing my old books, I may be able to derive these.
---
By the way, the reason I would like each room to have different parameters is so that this grid is more like a terrain map. When winds hit mountains they slow down, when particles move through space and near other objects they get attracted.

This allows a very primitive implementation of a dynamic system, so there should be plenty of cases of resonance, chaos, constancy and so one.

If one has sufficient CPU and memory, maybe a grid size or 64x64 may be possible (or larger). Who knows? We should just make sure that the design allows for easy scaling.

 

it would be an interesting idea to put each ball in a separate voice, possibly doing away with arrays altogether and just having polyphonic variables, very interesting.

i assumed that mass would be a function of the radius/diameter, but i guess we could separate them since they are not really linked in reality. at that point i feel like you get into GUI concerns though - i really don't like the idea of two balls that look identical interacting in different ways in the same environment, so we'd have to differentiate that IMO.

i think the vortexes should stay out of the main function and can be obtained by modulating the wind direction.

i don't think disappearing balls makes sense unless you have some sort of ball generator... or right clicking on them to delete.

 

Ian Dury had a wonderful song about you lot

 

As far as two balls looking alike, all balls in a room act and look alike and if you set all the room parameters the same you get identical operation in each room, so this general case can degenerate that way.

The rooms can have colors or textures that are modified by their parameter so they look different, but as far as the GUI looks, I have no real interest or concern. I rarely get involved in elaborate GUIs (but I admire them) - I just care about the sonic nature of the ensemble.

Modulating wind direction implies there is some input to the rooms for that purpose.

Maybe that is practical, but do all room get the same modulation? How do we assign the modulations?

If balls bounce off walls and generate reflections in other rooms (I was thinking of Automato here) then there is a possibility that they will keep on increasing in density. So some form of population control needs to be there.

To me, if all the rooms are the same, there is no need for rooms, just have a big array and maybe some drawn in bumpers to make a pinball arena.

But if we have the idea of rooms as an element in a grid - like the way weather map models or temperature flow models are made (usually using array processors as rooms) - I think we can generate some really intersting and abstract behavior patterns that would not be easily predictable - that is, an experimentalist dream environment.
---
As an example of a simple test setup, imagine all the rooms are the same and gravity points down and there is no wind.

Initially all rooms are empty.

Let the population control be set up so that a ball disappears when it hits a wall.

The start it up with a mouse gesture in the lower right point at 45 degrees.

We have just launched a cannonball. It will arc upwards at a height dependent on the initial velocity. If we push too hard, the cannonball bounces off the top room.

But if we do it just right we would get a perfect parabolic arc.

As the ball hits a wall it disappears and the trajectory is continued in the next room with identical conditions.

Gradually add parameter changes and keep testing to see if it all works.

What I mean to get at is that if you understand the model and set things up carefully you will get something predictable and easy to verify.

Then when things get very complex, we can trust things to still work if they appear to be doing the job without actually checking every ball.
---

Hit Me With Your Rhythm Stick?
There Ain't Half Been Some Clever Bastards?
Blockheads?
What A Waste?
Mash It Up Harry?
You're My Inspiration?
I Want to Be Straight?
Two Old Dogs Without a Name?
P.C.Honey?
The Right People?
All Those Who Say Okay?
Common as Muck?
Reasons to Be Cheerful?
You're More Than Fair?
Delusions of Grandeur?
Dance of the Crackpots?
Dance of the Screamers?
(Take Your Elbow Out of the Soup You're Sitting On The Chicken)?

 

I was thinking particularly about "There Ain't Half Been Some Clever Bastards" but there are several other good ones there.

A fascinating thread. I'll sing a rousing chorus of "There Ain't Half..." and dedicate it to you later tonight

 

So far we have not actually talked much about what to do with all this data.

Or even what it will look like.

For me it is fine to dwell at this ideative level and just brainstorm possibilities and approaches.

The most important idea for me is that we develop a rich generator of data that is correlated. By that I mean it isn't random.

If correlation is too high, things are predictable, if too low things are noise.

Somewhere in between is that golden range of possibilities.

Once we decide on a format and approach, then we can decide what controls what and what goes out to other stuff.

It's simplest to talk about just a room and what you can do with the data that is available.

Then we can look at what happens over several rooms and if there is something new that can happen by combining room parameters.

For example:

Suppose we find a way to make a bunch of balls bounce around a room and also influence another room in a sympathetic way.

By looking at the sympathies we can figure out what to do with the outputs.

To continue, suppose we has 5 rooms and the number of balls in a room fluctuate in some manner that is semi-periodic.

We can take (for example) the number of balls in a room as one parameter and use it to determine a pitch. Then we can take their average velocity and use it as a volume.

This would result in a pseudo-random sequence of notes.

I'm hesitant to assign any meaning to the values yet - I'm most interested in coming up with a platform of approaches.

I know there is at least one Reaktor U/L ensemble that is designed to similate motions, but I don't remember the name or what it did. And I don't intend to do what it did unless by accident.

If I get a chance I'll look it up.
---
It didn't take long to find these two:

Newtonian Bouncer:

https://co.native-instruments.com/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=1004

and

Wave Bouncer
https://co.native-instruments.com/index.php?id=userlibrary&type=0&ulbr=1&plview=detail&patchid=9856


It's entirely possible that I saw these a long time ago and forget them and recreated their ideas.

Whatever -- I think I'll look at them in detail.

 

i think there are several obvious interactions that we could choose from... balls colliding with walls, or with other balls triggering notes seems is an idea i've had before but never bothered to implement. if we're going with a set of rooms, each room could control one midi note and (any collision in that room would trigger that note), then you could easily set up scales like in automata and be good to go.

or the velocity and angle of the impact could control the pitch and velocity of the midi note.

 

I think I will wait a few days before I respond to let others catch up.

Most people are used to 'tweet-type' posts of a few characters and little substance.

 

My tweetlike post would go something like this:

As the ideas seem quite dependant on GUI, Is the sound a consequence of the ball, or is the ball a consequence of the sound.

Before you think I'm going all Confucius here, are we going to model a ball with sound effects, or are we going to model sound with a (fancy?) display?

 

Audio Paradox

http://www.noah.org/wiki/Audio_paradox

Some food for thought. There are also many book on the future of computer Audio designs. Listen to some of the cool samples. I hope this inspires more love for this interesting project.

 

I'm not thinking much about how it looks, just the activity that is internal.

I'm not even thinking very much about what it will sound like.

To me, this is an event generator. Just what events get generated is not yet clear.

These events could drive pitches, but also other things.

If you know Automato, that salamanderanagram made, you know that the things in the cells don't do anything until they hit the wall, and the location that they hit generates a MIDI note On event.

I imagine something like that for this, although exactly what gets generated is not well understood yet.

That's part of the group effort.

Here is an example of what could be done:

Let's say we have events driven by IC Sends or MIDI events so that no wires are needed to make a connection (I prefer outputs with connections, but in this case a send may be best).

Suppose we use the impact of a wall as a note velocity and the spot on the wall to be a pitch. This could be connected to an instrument outside the thing we make and use it to generate the sound.

That's much more trivial than what I imagine, I would like the balls trajectory used as an event source as well, but there could be 1024 of them per room, so that is a difficult thing to manage, and probably very CPU intensive.

We could use MIDI CC's to send event data or other methods.

I imagine Herwig will mention the possibilities of using the Partial's Framework to manage these event streams - that may well be a good idea.

Maybe this discussion is too abstract to draw in more people?

I now wish I hadn't given the thread a title like Pinball Wizard - as that implies balls bouncing off stuff.
As I mentioned, I think of this more as a terrain map.

Besides the two Newtonian bouncer U/L entries, there are other things that come to mind about this _
Newscool uses life to pattern events, Spiral uses curved paths triggered at points, Spacedrone uses something weird...

 

unfortunately i think the idea of using a voice for each ball with polyphony will not work :|

my reasoning is that it's very hard (if not impossible) to use data from one voice with a different voice in core, and we'll need to compare that data to do collisions properly.

 

I have another idea, more in line with the thread title.

That would be to allow the user to draw lines in an empty grid that act as pinball bumpers. The user can assign a note to the bumper.

After drawing the lines in some pattern, they can launch a ball into the grid and hear what happens.

This is the beginning of an idea, it needs to be a bit more involved to be interesting, I think. There needs to be a way to get more balls into play and maybe ways to steer the ball, like with a flipper.

I don't find this as appealing, but I welcome other ideas for group projects as it looks like my first idea is not getting enough interest.

 

This is what I had in mind as a terrain map:

http://hint.fm/wind/

 

Okay, I couldn't find Automato, so if anyone has a link, I would be glad to check it out.

I've had an idea spinning around for a bit though. If we turn it around and let the cells carry the information, and the ball trigger it, would that still be a problem with polyphonic voices?

I'm thinking generally in the direction of a conditioned evolving step-sequencer. Maybe a bit like life, but insted of applying to preset rules, let the rules be made out of the balls triggering the surroundings?