Medien Wiki - User contributions [en]

GMU:I and my Max/Felix Geith

2021-02-03T12:39:27Z

Jice8745: /* THE PROJECT */

== THE PROJECT ==

'''The game "Catch Yourself If You Can"'''

The idea of my project was to create a simple game in Max MSP, that will be played by only one player using both hands to play against each other. So one hand is the others opponent. The player has to decide to let one hand win over the other, or try to balance the game. Both works.

To make this difference between the hands a bit clearer I decided to use two different interfaces/controllers. For the left hand piezo sensors track the tipping of each individual finger, on the other hand (literally) there's a slider on a OSC application on a mobile phone that's sending values to the Max Application.

The gameplay is pretty classic, oldschool you could say, it's heavily inspired by old Nokia games like Space Impact or Snake. The right hand steers a purple square (it's a spaceship of course), and has to catch incoming red squares, that are generated by the tipping fingers of the left hand. If the right hand fails to catch less than 5 enemy-squares, the game's over.

It's possible to count the score, to reset/restart the game at any moment and to choose from three different levels of difficulty, easy, normal and hard, changing the speed of the incoming values.

To make it easy to try out the patch quickly, without having to setup the sensors etc., I added five bang objects and a slider to simulate the sensors. These can only be used by one hand and not simultaneously, so you can test the patch with them, but the idea of playing against yourself doesn't work out this way.

Here's a video of me playing.

{{#ev:youtube|youtu.be/Md7uMxYgF60}}

In the video below, you can find a detailed explanation on the patch, and how you setup the data inputs

{{#ev:youtube|youtu.be/5jJLMSbgWjs}}

To setup the piezo sensors, you need to connect them to your Max apllication using an Arduino and USB serial. You'll need the following

- 1 Arduino Uno (or Mega etc.) including USB connection
- 5 piezo sensors
- 5 resistors each ~100 ohms
- 10 jumper wires (male)
- some tape to attach the piezos to a surface like your desk

You will have to connect them like this: (made with tinkercad.com)

[[File:Circuit2.jpg|400px]]

The positive wire of the piezo has to be put to the A0-4 inputs, the negative wire to the ground.

It should look like this in the end

[[File:Bildschirmfoto 2021-02-03 um 13.38.44.png|400px]]

For the slider control (for the purple square) you will need an OSC application on your mobile phone. I used the "Mrmr OSC Controller" app by "10base-t interactive", made for OS. You can find it here https://apps.apple.com/de/app/mrmr-osc-controller/id294296343

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

File:Bildschirmfoto 2021-02-03 um 13.38.44.png

2021-02-03T12:39:18Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-02-03T12:38:30Z

Jice8745: /* THE PROJECT */

== THE PROJECT ==

'''The game "Catch Yourself If You Can"'''

The idea of my project was to create a simple game in Max MSP, that will be played by only one player using both hands to play against each other. So one hand is the others opponent. The player has to decide to let one hand win over the other, or try to balance the game. Both works.

To make this difference between the hands a bit clearer I decided to use two different interfaces/controllers. For the left hand piezo sensors track the tipping of each individual finger, on the other hand (literally) there's a slider on a OSC application on a mobile phone that's sending values to the Max Application.

The gameplay is pretty classic, oldschool you could say, it's heavily inspired by old Nokia games like Space Impact or Snake. The right hand steers a purple square (it's a spaceship of course), and has to catch incoming red squares, that are generated by the tipping fingers of the left hand. If the right hand fails to catch less than 5 enemy-squares, the game's over.

It's possible to count the score, to reset/restart the game at any moment and to choose from three different levels of difficulty, easy, normal and hard, changing the speed of the incoming values.

To make it easy to try out the patch quickly, without having to setup the sensors etc., I added five bang objects and a slider to simulate the sensors. These can only be used by one hand and not simultaneously, so you can test the patch with them, but the idea of playing against yourself doesn't work out this way.

Here's a video of me playing.

{{#ev:youtube|youtu.be/Md7uMxYgF60}}

In the video below, you can find a detailed explanation on the patch, and how you setup the data inputs

{{#ev:youtube|youtu.be/5jJLMSbgWjs}}

To setup the piezo sensors, you need to connect them to your Max apllication using an Arduino and USB serial. You'll need the following

- 1 Arduino Uno (or Mega etc.) including USB connection
- 5 piezo sensors
- 5 resistors each ~100 ohms
- 10 jumper wires (male)
- some tape to attach the piezos to a surface like your desk

You will have to connect them like this: (made with tinkercad.com)

[[File:Circuit2.jpg|400px]]

The positive wire of the piezo has to be put to the A0-4 inputs, the negative wire to the ground.

It should look like this in the end

[[File:testaaa|400px]]

For the slider control (for the purple square) you will need an OSC application on your mobile phone. I used the "Mrmr OSC Controller" app by "10base-t interactive", made for OS. You can find it here https://apps.apple.com/de/app/mrmr-osc-controller/id294296343

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

File:Testaaa.jpeg

2021-02-03T12:38:23Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-02-03T12:37:43Z

Jice8745: /* THE PROJECT */

== THE PROJECT ==

'''The game "Catch Yourself If You Can"'''

The idea of my project was to create a simple game in Max MSP, that will be played by only one player using both hands to play against each other. So one hand is the others opponent. The player has to decide to let one hand win over the other, or try to balance the game. Both works.

To make this difference between the hands a bit clearer I decided to use two different interfaces/controllers. For the left hand piezo sensors track the tipping of each individual finger, on the other hand (literally) there's a slider on a OSC application on a mobile phone that's sending values to the Max Application.

The gameplay is pretty classic, oldschool you could say, it's heavily inspired by old Nokia games like Space Impact or Snake. The right hand steers a purple square (it's a spaceship of course), and has to catch incoming red squares, that are generated by the tipping fingers of the left hand. If the right hand fails to catch less than 5 enemy-squares, the game's over.

It's possible to count the score, to reset/restart the game at any moment and to choose from three different levels of difficulty, easy, normal and hard, changing the speed of the incoming values.

To make it easy to try out the patch quickly, without having to setup the sensors etc., I added five bang objects and a slider to simulate the sensors. These can only be used by one hand and not simultaneously, so you can test the patch with them, but the idea of playing against yourself doesn't work out this way.

Here's a video of me playing.

{{#ev:youtube|youtu.be/Md7uMxYgF60}}

In the video below, you can find a detailed explanation on the patch, and how you setup the data inputs

{{#ev:youtube|youtu.be/5jJLMSbgWjs}}

To setup the piezo sensors, you need to connect them to your Max apllication using an Arduino and USB serial. You'll need the following

- 1 Arduino Uno (or Mega etc.) including USB connection
- 5 piezo sensors
- 5 resistors each ~100 ohms
- 10 jumper wires (male)
- some tape to attach the piezos to a surface like your desk

You will have to connect them like this: (made with tinkercad.com)

[[File:Circuit2.jpg|400px]]

The positive wire of the piezo has to be put to the A0-4 inputs, the negative wire to the ground.

It should look like this in the end

[[File:circuit3|400px]]

For the slider control (for the purple square) you will need an OSC application on your mobile phone. I used the "Mrmr OSC Controller" app by "10base-t interactive", made for OS. You can find it here https://apps.apple.com/de/app/mrmr-osc-controller/id294296343

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

File:Circuit3.jpeg

2021-02-03T12:34:59Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-02-03T12:34:10Z

Jice8745: /* THE PROJECT */

== THE PROJECT ==

'''The game "Catch Yourself If You Can"'''

The idea of my project was to create a simple game in Max MSP, that will be played by only one player using both hands to play against each other. So one hand is the others opponent. The player has to decide to let one hand win over the other, or try to balance the game. Both works.

To make this difference between the hands a bit clearer I decided to use two different interfaces/controllers. For the left hand piezo sensors track the tipping of each individual finger, on the other hand (literally) there's a slider on a OSC application on a mobile phone that's sending values to the Max Application.

The gameplay is pretty classic, oldschool you could say, it's heavily inspired by old Nokia games like Space Impact or Snake. The right hand steers a purple square (it's a spaceship of course), and has to catch incoming red squares, that are generated by the tipping fingers of the left hand. If the right hand fails to catch less than 5 enemy-squares, the game's over.

It's possible to count the score, to reset/restart the game at any moment and to choose from three different levels of difficulty, easy, normal and hard, changing the speed of the incoming values.

To make it easy to try out the patch quickly, without having to setup the sensors etc., I added five bang objects and a slider to simulate the sensors. These can only be used by one hand and not simultaneously, so you can test the patch with them, but the idea of playing against yourself doesn't work out this way.

Here's a video of me playing.

{{#ev:youtube|youtu.be/Md7uMxYgF60}}

In the video below, you can find a detailed explanation on the patch, and how you setup the data inputs

{{#ev:youtube|youtu.be/5jJLMSbgWjs}}

To setup the piezo sensors, you need to connect them to your Max apllication using an Arduino and USB serial. You'll need the following

- 1 Arduino Uno (or Mega etc.) including USB connection
- 5 piezo sensors
- 5 resistors each ~100 ohms
- 10 jumper wires (male)
- some tape to attach the piezos to a surface like your desk

You will have to connect them like this: (made with tinkercad.com)

[[File:Circuit2.jpg|400px]]

The positive wire of the piezo has to be put to the A0-4 inputs, the negative wire to the ground.

It should look like this in the end

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

File:Circuit2.jpg

2021-02-03T12:30:19Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-02-03T12:24:18Z

Jice8745:

GMU:I and my Max/Felix Geith

2021-02-03T12:17:01Z

Jice8745: /* THE PROJECT */

GMU:I and my Max/Felix Geith

2021-02-03T12:14:26Z

Jice8745: /* THE PROJECT */

GMU:I and my Max/Felix Geith

2021-02-03T12:13:47Z

Jice8745: /* THE PROJECT */

GMU:I and my Max/Felix Geith

2021-02-03T12:13:28Z

Jice8745: /* THE PROJECT */

GMU:I and my Max/Felix Geith

2021-02-03T12:04:31Z

Jice8745: /* THE PROJECT */

GMU:I and my Max/Felix Geith

2021-02-03T12:02:41Z

Jice8745:

GMU:I and my Max/Felix Geith

2021-02-03T11:06:29Z

Jice8745:

THE PROJECT

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

Semester Progress

2021-02-03T11:00:27Z

Jice8745:

== UPDATES ==
27.01.2020

The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.

[[File:Bildschirmfoto 2021-01-27 um 16.04.41.png|400px]]

The patch can be found here: [[:File:Game Demo 2701.maxpat]]
It doesn't include any external data or contents.

This version of the game is called "Catch You If You Can", and it meant to be played with five piezo mics and a slider on a OSC mobile application. To use this you need to setup the OSC connection as well as the Arduino-Piezo connection. So I included a [pictslider] object and five [bang] objects to simulate these setups and make it easy to test the game.

13.01.2020

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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!

Semester Progress

2021-02-03T11:00:10Z

Jice8745: Created page with " == UPDATES == 27.01.2020 The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as t..."

GMU:I and my Max/Felix Geith

2021-02-03T11:00:03Z

Jice8745: Replaced content with " == Weekly Tasks: == /Task 1/ /Task 2/ /Task 3/ Artworks I like Semester Progress"

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

[[Semester Progress]]

GMU:I and my Max/Felix Geith

2021-01-27T15:23:36Z

Jice8745: /* UPDATES */

GMU:I and my Max/Felix Geith

2021-01-27T15:13:25Z

Jice8745:

== UPDATES ==
27.01.2020

The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.

[[File:Bildschirmfoto 2021-01-27 um 16.04.41.png|400px]]

The patch can be found here: [[:File:Game Demo 2701.maxpat]]
It doesn't include any external data or contents.

13.01.2020

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

File:Game Demo 2701.maxpat

2021-01-27T15:12:15Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-01-27T15:08:43Z

Jice8745: /* UPDATES */

== UPDATES ==
27.01.2020

The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.

[[File:Bildschirmfoto 2021-01-27 um 16.04.41.png|400px]]

13.01.2020

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-27T15:08:07Z

Jice8745:

== UPDATES ==
27.01.2020

The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.

[[File:Bildschirmfoto 2021-01-27 um 16.04.41.png|400px]]

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

File:Bildschirmfoto 2021-01-27 um 16.04.41.png

2021-01-27T15:07:58Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-01-27T15:07:27Z

Jice8745: /* UPDATES */

== UPDATES ==

The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-20T16:27:58Z

Jice8745:

== 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.

[[File:Bildschirmfoto 2021-01-20 um 13.13.29.png|400px]]

Here is the newest version of the patch: [[:File:multislider_onetes.maxpat]]

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

File:Multislider onetes.maxpat

2021-01-20T16:27:50Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-01-20T16:27:09Z

Jice8745: /* UPDATES */

== 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.

[[File:Bildschirmfoto 2021-01-20 um 13.13.29.png|400px]]

Here is the newest version of the patch:

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-20T12:14:09Z

Jice8745:

== 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.

[[File:Bildschirmfoto 2021-01-20 um 13.13.29.png|400px]]

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

File:Bildschirmfoto 2021-01-20 um 13.13.29.png

2021-01-20T12:13:42Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith

2021-01-20T12:12:49Z

Jice8745: /* UPDATES */

== 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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-12T22:56:48Z

Jice8745: /* UPDATES */

== UPDATES ==

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.

[[File:piezoo2.jpg|400px]]

[[File:piezo1.jpg|400px]]

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.

{{#ev:youtube|youtu.be/bPNOji0dUDY}}

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: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-12T22:11:49Z

Jice8745: /* UPDATES */

GMU:I and my Max/Felix Geith

2021-01-12T22:10:49Z

Jice8745: /* UPDATES */

File:Piezoo2.jpg

2021-01-12T21:56:11Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

File:Piezo1.jpg

2021-01-12T21:56:06Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

GMU:I and my Max/Felix Geith/Project Idea Stuff

2021-01-12T21:46:07Z

Jice8745: Created page with "My goal this semester is to further develop the Max MSP game I made in Task 3, but to make certain factors in the game be controlled by some random process or variable in our..."

My goal this semester is to further develop the Max MSP game I made in Task 3, but to make certain factors in the game be controlled by some random process or variable in our everyday environment. For example the current weather/temperature or a dripping sink.

I found a nice patch online, that gets weather information from the "McDonald Observatory" at Mt. Locke in Texas website.
find the website: http://weather.as.utexas.edu/cgi-bin/latest_5min.cgi
find the patch: https://cycling74.com/forums/how-to-input-weather-data-in-max/

It works quite well and you get changing data you can use for anything. The problem is, even if the weather information is updated quite often, compared to other weather stations or websites, it's still updated only every five minutes and sometimes the received data isn't altered for an hour or longer. So this might be a bit unfitting to interfere with such a fast going thing like a game, you would need to play for half a day to see any changes.

An idea would be that the weather data changes the way the interface or the opponent looks. This could be a funny surprise every time you open the game. But still, there may be a lot more potential in other ideas.

A dripping sink could also be used to control or alter something in the game. I found a nice sensor that reacts to water being poured on it. It may arrive in the next 1-2 days s let's see what we can do with that!

An idea would for example be, to give a second person a water pistol, and every time they manage to aim and hit the water sensor the game get's harder, so they can both play against each other, but in two very different ways, one digital and the other one analog, but still they can play alongside each other.

Updates

The Weather Sensor arrived, but after some testing I had to scrap the idea.

Even though the sensor is capable of collecting data based on water, the data flow is pretty unreliable and not as dynamic as I hoped. Also, the manual that came with it strongly suggested to only measure data every 5 minutes, or the sensor could break. This means I get the same amount of data at the same rate es before. And idea would be to collect data for a day or so, and to have the game be influenced by it to be played afterwards. But this could also be simulated or faked and would make the data collection kind of obsolete I guess.

I'll come back with a new way of controlling the game later.

GMU:I and my Max/Felix Geith

2021-01-12T21:46:00Z

Jice8745:

GMU:I and my Max/Felix Geith

2021-01-12T21:43:55Z

Jice8745: /* UPDATES */

== UPDATES ==

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.

== Project Idea ==

My goal this semester is to further develop the Max MSP game I made in Task 3, but to make certain factors in the game be controlled by some random process or variable in our everyday environment. For example the current weather/temperature or a dripping sink.

I found a nice patch online, that gets weather information from the "McDonald Observatory" at Mt. Locke in Texas website.
find the website: http://weather.as.utexas.edu/cgi-bin/latest_5min.cgi
find the patch: https://cycling74.com/forums/how-to-input-weather-data-in-max/

It works quite well and you get changing data you can use for anything. The problem is, even if the weather information is updated quite often, compared to other weather stations or websites, it's still updated only every five minutes and sometimes the received data isn't altered for an hour or longer. So this might be a bit unfitting to interfere with such a fast going thing like a game, you would need to play for half a day to see any changes.

An idea would be that the weather data changes the way the interface or the opponent looks. This could be a funny surprise every time you open the game. But still, there may be a lot more potential in other ideas.

A dripping sink could also be used to control or alter something in the game. I found a nice sensor that reacts to water being poured on it. It may arrive in the next 1-2 days s let's see what we can do with that!

An idea would for example be, to give a second person a water pistol, and every time they manage to aim and hit the water sensor the game get's harder, so they can both play against each other, but in two very different ways, one digital and the other one analog, but still they can play alongside each other.

== Updates ==

The Weather Sensor arrived, but after some testing I had to scrap the idea.

Even though the sensor is capable of collecting data based on water, the data flow is pretty unreliable and not as dynamic as I hoped. Also, the manual that came with it strongly suggested to only measure data every 5 minutes, or the sensor could break. This means I get the same amount of data at the same rate es before. And idea would be to collect data for a day or so, and to have the game be influenced by it to be played afterwards. But this could also be simulated or faked and would make the data collection kind of obsolete I guess.

I'll come back with a new way of controlling the game later.

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-12T21:36:05Z

Jice8745: /* Project */

== UPDATES ==

== Project Idea ==

My goal this semester is to further develop the Max MSP game I made in Task 3, but to make certain factors in the game be controlled by some random process or variable in our everyday environment. For example the current weather/temperature or a dripping sink.

I found a nice patch online, that gets weather information from the "McDonald Observatory" at Mt. Locke in Texas website.
find the website: http://weather.as.utexas.edu/cgi-bin/latest_5min.cgi
find the patch: https://cycling74.com/forums/how-to-input-weather-data-in-max/

It works quite well and you get changing data you can use for anything. The problem is, even if the weather information is updated quite often, compared to other weather stations or websites, it's still updated only every five minutes and sometimes the received data isn't altered for an hour or longer. So this might be a bit unfitting to interfere with such a fast going thing like a game, you would need to play for half a day to see any changes.

An idea would be that the weather data changes the way the interface or the opponent looks. This could be a funny surprise every time you open the game. But still, there may be a lot more potential in other ideas.

A dripping sink could also be used to control or alter something in the game. I found a nice sensor that reacts to water being poured on it. It may arrive in the next 1-2 days s let's see what we can do with that!

An idea would for example be, to give a second person a water pistol, and every time they manage to aim and hit the water sensor the game get's harder, so they can both play against each other, but in two very different ways, one digital and the other one analog, but still they can play alongside each other.

== Updates ==

The Weather Sensor arrived, but after some testing I had to scrap the idea.

Even though the sensor is capable of collecting data based on water, the data flow is pretty unreliable and not as dynamic as I hoped. Also, the manual that came with it strongly suggested to only measure data every 5 minutes, or the sensor could break. This means I get the same amount of data at the same rate es before. And idea would be to collect data for a day or so, and to have the game be influenced by it to be played afterwards. But this could also be simulated or faked and would make the data collection kind of obsolete I guess.

I'll come back with a new way of controlling the game later.

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2021-01-06T13:04:37Z

Jice8745:

== Project ==

My goal this semester is to further develop the Max MSP game I made in Task 3, but to make certain factors in the game be controlled by some random process or variable in our everyday environment. For example the current weather/temperature or a dripping sink.

I found a nice patch online, that gets weather information from the "McDonald Observatory" at Mt. Locke in Texas website.
find the website: http://weather.as.utexas.edu/cgi-bin/latest_5min.cgi
find the patch: https://cycling74.com/forums/how-to-input-weather-data-in-max/

It works quite well and you get changing data you can use for anything. The problem is, even if the weather information is updated quite often, compared to other weather stations or websites, it's still updated only every five minutes and sometimes the received data isn't altered for an hour or longer. So this might be a bit unfitting to interfere with such a fast going thing like a game, you would need to play for half a day to see any changes.

An idea would be that the weather data changes the way the interface or the opponent looks. This could be a funny surprise every time you open the game. But still, there may be a lot more potential in other ideas.

A dripping sink could also be used to control or alter something in the game. I found a nice sensor that reacts to water being poured on it. It may arrive in the next 1-2 days s let's see what we can do with that!

An idea would for example be, to give a second person a water pistol, and every time they manage to aim and hit the water sensor the game get's harder, so they can both play against each other, but in two very different ways, one digital and the other one analog, but still they can play alongside each other.

== Updates ==

The Weather Sensor arrived, but after some testing I had to scrap the idea.

Even though the sensor is capable of collecting data based on water, the data flow is pretty unreliable and not as dynamic as I hoped. Also, the manual that came with it strongly suggested to only measure data every 5 minutes, or the sensor could break. This means I get the same amount of data at the same rate es before. And idea would be to collect data for a day or so, and to have the game be influenced by it to be played afterwards. But this could also be simulated or faked and would make the data collection kind of obsolete I guess.

I'll come back with a new way of controlling the game later.

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[Artworks I like]]

Artworks I like

2020-12-06T18:29:11Z

Jice8745:

Here are some artworks of different artists that I really like / inspired me

Sadly I haven't yet found all of them on the internet, so the list will hopefully grow bigger in the near future

Zimoun Sound Art Compilation: https://vimeo.com/7235817

Speaking piano https://www.youtube.com/watch?v=muCPjK4nGY4&feature=emb_logo

Artworks I like

2020-12-02T13:36:07Z

Jice8745: Created page with "Here are some artworks of different artists that I really like / inspired me Sadly I haven't yet found all of them on the internet, so the list will hopefully grow bigger in..."

GMU:I and my Max/Felix Geith

2020-12-02T13:34:06Z

Jice8745:

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[/Project/]]

[[Artworks I like]]

GMU:I and my Max/Felix Geith

2020-12-02T12:31:04Z

Jice8745: /* Weekly Tasks: */

== Weekly Tasks: ==

[[/Task 1/]]

[[/Task 2/]]

[[/Task 3/]]

[[/Project/]]

GMU:I and my Max/Felix Geith/Task 3

2020-11-26T10:28:02Z

Jice8745:

For this week I build a simple game, that you can control with a slider or a simple OSC control setup.

[[File:Bildschirmfoto 2020-11-25 um 14.39.01.png|200px]]

It's a retro game called "Goodbye World". The goal of the game is to save the world, in this case it's actually quite easy :)

All you have to do is move a square with a slider, to prevent other squares from hitting our beautiful planet. You can either control the slider with you mouse or OSC.

Here are videos of me playing. The second and third video feature updated versions of the game.
{{#ev:youtube|youtu.be/teXmnSvEtQI}}

{{#ev:youtube|youtu.be/uukFwfVftM4}}

{{#ev:youtube|youtu.be/9iPx1sgdimM}}

Find the updated patch right here: [[:File:the game.maxpat]]

The sounds used in the patch can be downloaded here: [[:File:GOODBYE WORLD sounds.zip]]
If you need help including the sounds in the patch, you can find an explanation at the end of the video.

I used this OSC App for iOS:
https://apps.apple.com/de/app/mrmr-osc-controller/id294296343

Note that you might have to change the OSC settings in the patch to make the game work on you device!!

File:GOODBYE WORLD sounds.zip

2020-11-26T10:27:55Z

Jice8745: File uploaded with MsUpload

File uploaded with MsUpload

File:The game.maxpat

2020-11-26T10:24:54Z

Jice8745: Jice8745 uploaded a new version of File:The game.maxpat

File uploaded with MsUpload

GMU:I and my Max/Felix Geith/Task 3

2020-11-26T10:24:31Z

Jice8745:

For this week I build a simple game, that you can control with a slider or a simple OSC control setup.

[[File:Bildschirmfoto 2020-11-25 um 14.39.01.png|200px]]

It's a retro game called "Goodbye World". The goal of the game is to save the world, in this case it's actually quite easy :)

All you have to do is move a square with a slider, to prevent other squares from hitting our beautiful planet. You can either control the slider with you mouse or OSC.

Here are videos of me playing. The second and third video feature updated versions of the game.
{{#ev:youtube|youtu.be/teXmnSvEtQI}}

{{#ev:youtube|youtu.be/uukFwfVftM4}}

{{#ev:youtube|youtu.be/9iPx1sgdimM}}

Find the updated patch right here:

I used this OSC App for iOS:
https://apps.apple.com/de/app/mrmr-osc-controller/id294296343

Note that you might have to change the OSC settings in the patch to make the game work on you device!!