GMU:I and my Max/Felix Geith: Difference between revisions

Revision as of 12:12, 20 January 2021

UPDATES

This week I started repatching the game using the [multislider] object for the display instead of the jitter matrix. This makes it possible to have multiple moving "pixels" at once. The piezo hand controller is now "spawning" new pixels. A very nice feature, to have a kind of random way the pixels take is the [drunk] object. It's kind of similar to [random], but works with a step range. This means it outputs random values that have a defined distance from the value before, so you can for example give it a step range of "1", so it will just move one step, either up or down. So it won't jump too far.

I hope to have the patch finished by the end of this week. So far it looks like this, it's not yet tidied up or arranged to have an interface to play on. Still only patching.

Well, I've made a point. After multiple weeks now trying and thinking about the water sensor and the fact that its data flow is just too undynamic and unstable to really have an impact on the game, I made a cut and a change of plans.

Well, I stayed with pressure caption, and the fact that the other data impact of the game will come from a different source than the first players control data. To have a game that's not functioning on just one console or interface, but tries to draw a line between diverse interfaces.

On one hand we have still have the OSC control via Smartphone, that controls the first player. On the other hand (literally) we now have some piezo sensors that collect pressure data from each finger. This gives us two opportunities. We use this new data input to control either the opponent or a second player. It would be amazing if there were both possibilities to choose from.

This far I have arranged the piezos on my table, and connected them to Max. So far only with breadboard action.

This runs through the arduino and gives us values roughly between 0 and 1000. With this arrangement on the table we have some little data hysteresis I want to get rid of. Also I want the piezos to have a minimum pressure to be used to trigger the patch, so that positioning the hand isn't that much of a problem. This can be archieved with the [past] object, which bangs when a certain value is reached and passed by, but just in the upwards direction, so this is perfect for me.

In the patch below we can see the serial connection receiving the data from the arduino. To display the input I used a [multislider] object.

These bangs now can be used to control the pixels that are the enemies in the game, to control for example the position where they get "spawned", which is now controlled by random.

They can also be used as position control for a potential team player mode.

Anyways, I'll have to get back to fixing the multiplayer problems I have. It works so far, but the pixel control has a bug that I haven't solved yet.

I'll come back for updates!

Project Idea Stuff

Weekly Tasks:

@@ Line 1: / Line 1: @@
 == UPDATES ==
+This week I started repatching the game using the [multislider] object for the display instead of the jitter matrix. This makes it possible to have multiple moving "pixels" at once. The piezo hand controller is now "spawning" new pixels. A very nice feature, to have a kind of random way the pixels take is the [drunk] object. It's kind of similar to [random], but works with a step range. This means it outputs random values that have a defined distance from the value before, so you can for example give it a step range of "1", so it will just move one step, either up or down. So it won't jump too far.
+I hope to have the patch finished by the end of this week. So far it looks like this, it's not yet tidied up or arranged to have an interface to play on. Still only patching.
 Well, I've made a point. After multiple weeks now trying and thinking about the water sensor and the fact that its data flow is just too undynamic and unstable to really have an impact on the game, I made a cut and a change of plans.