Medien Wiki - User contributions [en]

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-30T18:25:44Z

TVischer:

==How to write a Bug report==

===Introduction===

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

===State the facts…===

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

===Be Nice…===

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

===You cant just write “It doesn't work”…===

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

===Asking for general help…===
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

===Show it…===
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:

1. You can make a screen video of you reproducing the bug

2. You can make screen shots and write information into them

3. Write a detailed description of every click you made since you started the PC

4. You could ask them to make a Skype or Teamviewer session with you to share your screen live

5. If you weren't precise enough do it over again as they wish, or try some variations to get to the same point were you actually wanted to be.

6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.

7. If you're loading the data from a specific file you created send them over to them.

8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

===Works for them but not for you…===

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.

1. Provide the information of what your intention was by using the program.

2. Tell them what exactly happened

3. Tell them what you thought it should happen

4. Tell them exactly what Error message you saw

5. Are there unexplainable delays and when

At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

===And then i tried this to solve the Problem…===
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

===Sometimes it works…===
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it. Try different setups several times and write down how many times the bug occurred and what differs to the times it was working.

1. Where you using an extra large file

2. Did some other program access the file at the same time

3. Are you running any other programs you weren't running the last time

4. Do you use another display or beamer then before

5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.

6. What version of the program you are using with wich version of your operating system

===Be specific no matter you're writing in english or german…===

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

===Asking for general help…===
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

===Summary===

1. Let the programmer see what you've seen

2. If they cant see it failing themselves describe what went wrong

3. Describe everything in Detail

4. Tell them what you saw and what you were expecting to see

5. Write down the Error messages

6. When something unexpected happens leave the Situation like that until you're calm

7. Describe the symptoms don't make a diagnosis

8. Provide the programmer with any extra information he needs

9. Tell them you're version numbers

10. Be specific and write in clear language

11. Be sure you're description cant be misinterpreted

===Performance Platform Specific===

You can reach the team of Captury via mail or by calling them:

Nils Hasler:
hasler@thecaptury.com

Tel.: +49 681 302-64931

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-30T18:23:01Z

TVischer:

==How to write an online Tutorial==

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as it should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else wrote about it yet.

==You should use the Wiki to…==

Show us what you have made

Show us how you made something

Show us how to do something

'''You shouldn't use it for…'''

Show us somebody else work

Try and sell us something, without basic understanding of how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==

===Title===
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

===Top Picture===
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

===Instruction===
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

===The Other Steps===
Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

===Materials and Tools===
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

===Preparation===
For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

===How you made it===
Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

===Tips===
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

===Further Ideas===
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

===Layout===
There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

'''Here are some other Wiki commands that will help you formatting your Text:'''

[[File:Screen_Shot_2016-07-30_at_20.02.56.png]]
[[File:Screen_Shot_2016-07-30_at_20.03.11.png]]
[[File:Screen_Shot_2016-07-30_at_20.03.26.png]]
[[File:Screen_Shot_2016-07-30_at_20.03.41.png]]
[[File:Screen_Shot_2016-07-30_at_20.04.06.png]]
[[File:Screen_Shot_2016-07-30_at_20.04.45.png]]
[[File:Screen_Shot_2016-07-30_at_20.04.56.png]]

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

'''Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

File:Screen Shot 2016-07-30 at 20.04.56.png

2016-07-30T18:19:04Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.04.45.png

2016-07-30T18:17:42Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.04.06.png

2016-07-30T18:17:12Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.03.41.png

2016-07-30T18:16:05Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.03.26.png

2016-07-30T18:15:36Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.03.11.png

2016-07-30T18:15:00Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-30 at 20.02.56.png

2016-07-30T18:12:41Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:59:22Z

TVischer:

'''How to write a Bug report'''

==Introduction==

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

==State the facts…==

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

==Be Nice…==

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

==You cant just write “It doesn't work”…==

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Show it…==
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:

1. You can make a screen video of you reproducing the bug

2. You can make screen shots and write information into them

3. Write a detailed description of every click you made since you started the PC

4. You could ask them to make a Skype or Teamviewer session with you to share your screen live

5. If you weren't precise enough do it over again as they wish, or try some variations to get to the same point were you actually wanted to be.

6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.

7. If you're loading the data from a specific file you created send them over to them.

8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

==Works for them but not for you…==

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.

1. Provide the information of what your intention was by using the program.

2. Tell them what exactly happened

3. Tell them what you thought it should happen

4. Tell them exactly what Error message you saw

5. Are there unexplainable delays and when

At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

==And then i tried this to solve the Problem…==
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

==Sometimes it works…==
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it. Try different setups several times and write down how many times the bug occurred and what differs to the times it was working.

1. Where you using an extra large file

2. Did some other program access the file at the same time

3. Are you running any other programs you weren't running the last time

4. Do you use another display or beamer then before

5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.

6. What version of the program you are using with wich version of your operating system

==Be specific no matter you're writing in english or german…==

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Summary==

1. Let the programmer see what you've seen

2. If they cant see it failing themselves describe what went wrong

3. Describe everything in Detail

4. Tell them what you saw and what you were expecting to see

5. Write down the Error messages

6. When something unexpected happens leave the Situation like that until you're calm

7. Describe the symptoms don't make a diagnosis

8. Provide the programmer with any extra information he needs

9. Tell them you're version numbers

10. Be specific and write in clear language

11. Be sure you're description cant be misinterpreted

==Performance Platform Specific==

You can reach the team of Captury via mail or by calling them:

Nils Hasler:
hasler@thecaptury.com

Tel.: +49 681 302-64931

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:59:07Z

TVischer:

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:58:52Z

TVischer:

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:58:22Z

TVischer:

'''How to write an online Tutorial'''

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as it should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else wrote about it yet.

'''You should use the Wiki to…'''

Show us what you have made

Show us how you made something

Show us how to do something

'''You shouldn't use it for…'''

Show us somebody else work

Try and sell us something, without basic understanding of how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==

Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

'''Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:57:58Z

TVischer:

'''How to report a bug'''

==Introduction==

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

==State the facts…==

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

==Be Nice…==

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

==You cant just write “It doesn't work”…==

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Show it…==
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:

1. You can make a screen video of you reproducing the bug

2. You can make screen shots and write information into them

3. Write a detailed description of every click you made since you started the PC

4. You could ask them to make a Skype or Teamviewer session with you to share your screen live

5. If you weren't precise enough do it over again as they wish, or try some variations to get to the same point were you actually wanted to be.

6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.

7. If you're loading the data from a specific file you created send them over to them.

8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

==Works for them but not for you…==

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.

1. Provide the information of what your intention was by using the program.

2. Tell them what exactly happened

3. Tell them what you thought it should happen

4. Tell them exactly what Error message you saw

5. Are there unexplainable delays and when

At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

==And then i tried this to solve the Problem…==
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

==Sometimes it works…==
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it. Try different setups several times and write down how many times the bug occurred and what differs to the times it was working.

1. Where you using an extra large file

2. Did some other program access the file at the same time

3. Are you running any other programs you weren't running the last time

4. Do you use another display or beamer then before

5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.

6. What version of the program you are using with wich version of your operating system

==Be specific no matter you're writing in english or german…==

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Summary==

1. Let the programmer see what you've seen

2. If they cant see it failing themselves describe what went wrong

3. Describe everything in Detail

4. Tell them what you saw and what you were expecting to see

5. Write down the Error messages

6. When something unexpected happens leave the Situation like that until you're calm

7. Describe the symptoms don't make a diagnosis

8. Provide the programmer with any extra information he needs

9. Tell them you're version numbers

10. Be specific and write in clear language

11. Be sure you're description cant be misinterpreted

==Performance Platform Specific==

You can reach the team of Captury via mail or by calling them:

Nils Hasler:
hasler@thecaptury.com

Tel.: +49 681 302-64931

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:57:22Z

TVischer: /* Performance Platform Specific */

How to report a bug

==Introduction==

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

==State the facts…==

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

==Be Nice…==

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

==You cant just write “It doesn't work”…==

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Show it…==
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:

1. You can make a screen video of you reproducing the bug

2. You can make screen shots and write information into them

3. Write a detailed description of every click you made since you started the PC

4. You could ask them to make a Skype or Teamviewer session with you to share your screen live

5. If you weren't precise enough do it over again as they wish, or try some variations to get to the same point were you actually wanted to be.

6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.

7. If you're loading the data from a specific file you created send them over to them.

8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

==Works for them but not for you…==

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.

1. Provide the information of what your intention was by using the program.

2. Tell them what exactly happened

3. Tell them what you thought it should happen

4. Tell them exactly what Error message you saw

5. Are there unexplainable delays and when

At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

==And then i tried this to solve the Problem…==
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

==Sometimes it works…==
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it. Try different setups several times and write down how many times the bug occurred and what differs to the times it was working.

1. Where you using an extra large file

2. Did some other program access the file at the same time

3. Are you running any other programs you weren't running the last time

4. Do you use another display or beamer then before

5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.

6. What version of the program you are using with wich version of your operating system

==Be specific no matter you're writing in english or german…==

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Summary==

1. Let the programmer see what you've seen

2. If they cant see it failing themselves describe what went wrong

3. Describe everything in Detail

4. Tell them what you saw and what you were expecting to see

5. Write down the Error messages

6. When something unexpected happens leave the Situation like that until you're calm

7. Describe the symptoms don't make a diagnosis

8. Provide the programmer with any extra information he needs

9. Tell them you're version numbers

10. Be specific and write in clear language

11. Be sure you're description cant be misinterpreted

==Performance Platform Specific==

You can reach the team of Captury via mail or by calling them:

Nils Hasler:
hasler@thecaptury.com

Tel.: +49 681 302-64931

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:56:58Z

TVischer: /* Performance Platform Specific */

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:56:14Z

TVischer:

How to write an online Tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as it should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else wrote about it yet.

'''You should use the Wiki to…'''

Show us what you have made

Show us how you made something

Show us how to do something

'''You shouldn't use it for…'''

Show us somebody else work

Try and sell us something, without basic understanding of how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==

Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

'''Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:53:31Z

TVischer:

How to write an online Tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as they should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else write about it yet.

'''You should use the Wiki to…'''

Show us what you have made

Show us how you made something

Show us how to do something

'''You shouldn't use it for…'''

Show us somebody else work

Try and sell something without basic understanding how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still probably read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==
Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

'''Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:50:47Z

TVischer:

How to write an online tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as they should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else write about it yet.

'''You should use the Wiki to…'''

Show us what you have made

Show us how you made something

Show us how to do something

'''You shouldn't use it for…'''

Show us somebody else work

Try and sell something without basic understanding how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still probably read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==
Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

'''Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:48:17Z

TVischer:

How to write an online tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as they should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else write about it yet.

You should use the Wiki to…

Show us what you have made

Show us how you made something

Show us how to do something

You shouldn't use it for…

Show us somebody else work

Try and sell something without basic understanding how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still probably read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==
Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

'''Screenshot''' pressing''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)
'''
Screen recording''' pressing '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:47:22Z

TVischer:

How to write an online tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as they should be. So in this tutorial i want to explain what you can do to make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else write about it yet.

You should use the Wiki to…

Show us what you have made

Show us how you made something

Show us how to do something

You shouldn't use it for…

Show us somebody else work

Try and sell something without basic understanding how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still probably read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==
Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:

[[File:Screen_Shot_2016-07-01_at_18.16.09.png]]

Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.

[[File:Screen_Shot_2016-07-01_at_18.44.20.png]]

You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

Screenshot using''' ctrl+ shift+ alt + s''' (wich will be saved in the images folder)

Screen recording '''alt+ cmd+ v''' (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

File:Screen Shot 2016-07-01 at 18.44.20.png

2016-07-01T16:44:49Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-07-01 at 18.16.09.png

2016-07-01T16:43:38Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

GMU:Tutorials/Documentation/Tutorial How-To

2016-07-01T16:42:58Z

TVischer: Created page with " How to write an online tutorial Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as you could reima..."

How to write an online tutorial

Tutorials are one main reason the Medienwiki exists, but not everything is as well documented as you could reimagine them. So in this tutorial i want to explain how you can do make it better.

==Subject Matter==

You should write about anything, but it helps if you're feeling passionate about you're project. You should also preferably wrote about something original, there are not that many projects online here but you should first check if no one else write about it yet.

You should use the Wiki to…

Show us what you have made

Show us how you made something

Show us how to do something

You shouldn't use it for…

Show us somebody else work

Try and sell something without basic understanding how you accomplished it

Write inappropriate things

You should preferably write in english if not otherwise stated in your course description, so that every foreign student has a chance to understand the things that you've made. Also you should watch your language, you don't need to write a scientific masterpiece of a research but you're Professor will still probably read it.

==What kind of Tutorial should i do==

Basically using the current version of the wiki only allows you to make a step by step instruction. You could also film what you're doing and setting up a link to the video into the wiki. (youll find a good guide for making a video tutorial [http://www.creativebloq.com/video-production/make-tutorial-video-2131915 here])
The step by step tutorial consists of one step followed by some photos at a time.
You could split it up like this:

Preparation

What you need for it

Start

Some small explanatory steps

End result with some photos or a video

==Photos==

For making a good online Tutorial its essential that you're taking good photographs.
You should always try to make your own photos and illustrations of your work, cause the wiki isn't meant to be hosting content from content that you found on the internet.
Use a proper scanner to digitalise drawings and schematics.
You should also think of using a proper camera for taking photos of your work rather than quickly taking a snapshot with your mobile phone, you will thank yourself later for having your work properly documented.
Make sure the image is sharp and the object is in focus use macro settings if you need to. Take photographs from different angles of your object and try to light your object even. You should use a white background for it and lots of daylight, if it isn't available try using a desk lamp. (you can also build you're own [http://www.instructables.com/id/Photography-Light-Box/ lightbox] )
Take more photos than you need, you can upload them into a gallery function.

==Structure==
Title
You need to be aware of the way your reader encounters your work.
The first thing the reader sees is unfortunately just the title of the work and the description of the course it was made in.
So you need to have a good catchy title that wakes up the readers interest.

Good title: How to make a ### to help you ###

Good title: Improve your ### by ### and ###.

Bad title: The Widget by Name!

Bad title: What everyone has been waiting for: the AWESOME PROJECT!!!!!

Bad title: Yet Another ……

Top Picture
For the Top of your page choose a picture that shows your work in its best light. This is the first time the reader is going to encounter your work by actually seeing it, so it has to make a good impression.

Instruction
Position an instruction underneath the top image. The instruction itself should be reasonably short, and doesn't need to include any details of how you made the project. Throw in a little history of how you came up with the project if you like. If the back-story is long, it might be worth a whole step to itself.
Assuming the title and course description has persuaded the reader to start reading the next thing they see is a photo of your work and the instruction. This is the last chance to convince wavering readers to continue reading, so take a few minutes to get it right

The Other Steps

Theres no rule how you want to structure your tutorial every tutorial/presentation differs from the other, but there are some essential steps you should keep in mind:

Materials and Tools
Make a list to help others to get organised before rebuilding you're project in real or in they're minds especially if there are special uncommon items they need to borrow or buy.

Preparation

For projects that have to do with electronics for example do you need to prepare something? Anti static mat, preheating your soldering iron, 3D printing some parts etc.

How you made it

Make a step by step description of how you made and better take it slow. No one knows better what you've did than you yourself but for others it maybe isn't that easy to follow your lead.

Tips
Have you been confronted with some issues that were hard to figure out how to do but you solved it somehow using a clever trick. Then share it with you're readers they will be thankful about that.

Further Ideas
Now after finishing your projecting and reflecting onto it while writing about it. Do you have plans for the future, do you think theres more potential in it or do you want to do something different than you did. You'll readers will be excited to hear about it especially if you've done some really vague project wich doesn't have an clear outline yet.

Layout

There are some things you should mind using the wiki, it has some shortcuts for lay outing the text that you need to quote into you're text.
Also theres a sidebar above the text window wich contains shortcuts for lay outing:
Writing bold

Writing cursive

Writing underlined

Linking a Website

Writing an Headline Text

Implementing an Image

Linking a file

Writing an formula

Ignore the wiki specific preset lay outing rules

Add a signature and a timestamp

Adding a line

You will find the option to upload images to the wiki on the left side underneath the Bold Headlines in the sidebar.
You can then choose a picture to upload from your PC but mind two things

1. Upload a .png file (.jpg files cant be uploaded to the wiki)

2. Compress your image as much as you can (the wiki wont show to big files either)

==Performance Platform specific==

The PC in the Performance lab is running Debian you can make a:

Screenshot using ctrl+ shift+ alt + s (wich will be saved in the images folder)

Screen recording alt+ cmd+ v (you can start and stop with this command. There is a red dot appearing in the Top bar of the Dektop to indicate that youre currently recording. The video will be saved in your video folder)

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T16:24:24Z

TVischer:

How to report a bug

==Introduction==

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

==State the facts…==

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

==Be Nice…==

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

==You cant just write “It doesn't work”…==

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Show it…==
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:

1. You can make a screen video of you reproducing the bug

2. You can make screen shots and write information into them

3. Write a detailed description of every click you made since you started the PC

4. You could ask them to make a Skype or Teamviewer session with you to share your screen live

5. If you weren't precise enough do it over again as they wish, or try some variations to get to the same point were you actually wanted to be.

6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.

7. If you're loading the data from a specific file you created send them over to them.

8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

==Works for them but not for you…==

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.

1. Provide the information of what your intention was by using the program.

2. Tell them what exactly happened

3. Tell them what you thought it should happen

4. Tell them exactly what Error message you saw

5. Are there unexplainable delays and when

At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

==And then i tried this to solve the Problem…==
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

==Sometimes it works…==
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it. Try different setups several times and write down how many times the bug occurred and what differs to the times it was working.

1. Where you using an extra large file

2. Did some other program access the file at the same time

3. Are you running any other programs you weren't running the last time

4. Do you use another display or beamer then before

5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.

6. What version of the program you are using with wich version of your operating system

==Be specific no matter you're writing in english or german…==

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Summary==

1. Let the programmer see what you've seen

2. If they cant see it failing themselves describe what went wrong

3. Describe everything in Detail

4. Tell them what you saw and what you were expecting to see

5. Write down the Error messages

6. When something unexpected happens leave the Situation like that until you're calm

7. Describe the symptoms don't make a diagnosis

8. Provide the programmer with any extra information he needs

9. Tell them you're version numbers

10. Be specific and write in clear language

11. Be sure you're description cant be misinterpreted

==Performance Platform Specific==

You can reach the team of Captury via mail or by calling them:
Nils Hasler hasler@thecaptury.com
Tel.: +49 681 302-64931

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T14:33:08Z

TVischer:

GMU:Tutorials/Documentation/Bug Report How-To

2016-07-01T14:25:49Z

TVischer: Created page with """How to report a bug"" ==Introduction== On this Wiki-page I'll try to explain how you can write a good bug report. The aim of a bug report is to enable the programmer to see ..."

""How to report a bug""

==Introduction==

On this Wiki-page I'll try to explain how you can write a good bug report.
The aim of a bug report is to enable the programmer to see the program failing in front of them. You should give them careful and detailed instructions on how to make it fail. If they can reproduce the error, they will try to get as much information until they know the cause. If they can’t reproduce the error, you need to get that information for them.

==State the facts…==

In a bug report you should try to state clear facts what was happening to you when you used
the program.
Example: I was using the program to do this but this happened.
If you have some speculations what might have happened you can include that but if you aren't sure about it just leave it out, it may cause more confusion than necessary.

==Be Nice…==

When you're writing the report you should write it in a friendly and polite form, it wont help if you insult them or anything in that direction. They may have programmed/developed it but they don't want it too fail when you're using it.

==You cant just write “It doesn't work”…==

Like i said above they don't want you to fail while using the program, since they haven't noticed the potential bug the program was running fine for them in their setup.
So that in mind give them detailed information on how your setup is like cause its most likely different from the one they have.
More clear information is always better then less.
On What System are you running the Software
What are the specs of your PC
What Version/distribution of the Program/Software do you have

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Show it…==
The best way to report the bug is to show it to the programmer since for example Mr. Hasler cant be here in Person every time you need to figure out another effective way to show them. They need to see how you start the PC, run the Software, see how you interact with it and how the Software responses. This step is very important so that they can try to reproduce the bug by themselves in order to fix it.

There are several possibilities:
You can make a screen video of you reproducing the bug
You can make screen shots and write information into them
Write a detailed description of every click you made since you started the PC
You could ask them to make a Skype or Teamviewer session with you to share your screen live
5. If you weren't precise enough do it over again as they wish, or try some variations to get
to the same point were you actually wanted to be.
6. If its a graphical problem you're confronted with tell them exactly in wich order you
pressed the buttons, if its a problem writing commands they need to know exactly what
commands you typed and what the computer outputted as response.
7. If you're loading the data from a specific file you created send them over to them.
8. If you're using the program to talk to another via Network Computer you also need to
send them the specs of the other on too

==Works for them but not for you…==

If the programmer recreated your commands/inputs/actions/… and it works for them you may haven't given them enough information. Maybe the error doesn't appear on every Computer.
Or you have got it wrong what the program is should do and is able too, so it maybe that you got it right but for your opinion its turning out wrong.
1. Provide the information of what your intention was by using the program.
2. Tell them what exactly happened
3. Tell them what you thought it should happen
4. Tell them exactly what Error message you saw
5. Are there unexplainable delays and when
At this point the programmer still wants to reproduce your failure, they need to know what and where it has gone wrong. Write the errors down message and number are equally important, even if the computer cant give you out the information in words theres still important information in numbers or signs he's outputting.

==And then i tried this to solve the Problem…==
You probably have done some things after the bug showed up too you to fix it yourself, these action may have made things worse or changed something the programmer cant easily reproduce. Try to remember what you did afterwards and also give detailed information about that.
If you're not sure what you're doing, don't do anything after the bug shows up you will make it worse!
When something goes wrong, immediately stop doing anything. Don't touch any buttons at all.
Just look at the screen and try to write down everything that isn't ordinary.
The only things you can do by yourself is closing the program or rebooting the computer.
Even if you're good at programming don't try to do things you don't know anything about, you aren't the person who has written the code so you can never be a hundred percent sure of anything what the company actually there.
You describe the symptoms, don't assume a diagnosis it will only lead to general confusion.
Even if you think the commands/changes etc. the programmer provides you with will not work cause you know it better, still try it there will be some reason he wants you to try that.

==Sometimes it works…==
If you're confronted with a bug that just occurs from time to time try to search for a pattern in it.
Where you using an extra large file
Did some other program access the file at the same time
3. Are you running any other programs you weren't running the last time
4. Do you use another display or beamer then before
5. Maybe you're just stressed cause of a deadline and weren't using the software carefully
enough.
6. What version of the program you are using with wich version of your operating system
Try different setups several times and write down how many times the bug occurred and
what differs to the times it was working.

==Be specific no matter you're writing in english or german…==

Don't just tell them i loaded that file into it, tell them how you loaded it by pressing keys, typing a command line or using graphical buttons. This can matter too. Write more than they actually need to know they're willing to ignore the information that isn't needed over getting to less information.
If you write them to less information they need to come/mail back to you and ask you those things and the process will therefore take longer as giving them a good specific description in the first place.
Dont use “it”: I used it then it opened a file and then it crashed.
What did crash here, the opening of the file or the whole program. You also need to be careful while using pronouns, the programmer cant see into your setup unless he's standing right behind you.
Read what you've written before you send it off to the programmer, go through your own steps and recreate the situation while using you're instructions as a guideline. Thats the best way to assume that the programmer will get to the same situation as you did.

==Asking for general help…==
If you are just asking for help and don't want to report a bug, you should tell the programmer where you already looked for information. They may can use this information to make they're own documentation better.

==Summary==

1. Let the programmer see what you've seen
2. If they cant see it failing themselves describe what went wrong
3. Describe everything in Detail
4. Tell them what you saw and what you were expecting to see
5. Write down the Error messages
6. When something unexpected happens leave the Situation like that until you're calm
7. Describe the symptoms don't make a diagnosis
8. Provide the programmer with any extra information he needs
9. Tell them you're version numbers
10. Be specific and write in clear language
11. Be sure you're description cant be misinterpreted

GMU:Digital Puppetry Lab/Group B0XJUMP

2016-05-31T14:42:47Z

TVischer:

In our little game a boxer fights a '''battle of life or restart''' against an army of boxing gloves. To have the ability of jumping and escaping his enemies, he needs your support: Every time you clap our little boxer jumps out of the way!!

== Blender ==
Models used in Blender:

<gallery>
image:BlenderB0XJUMP1.png|
image:BlenderB0XJUMP2.png|
</gallery>

== Processing ==
<gallery>
image:B0XJUMPpro1.png|
image:B0XJUMPpro2.png|
image:B0XJUMPpro3.png
</gallery>

We used the Minim Library in Processing to adapt the sound of clapping through the microphone to send a Osc command, the sketch can be viewed [http://www.openprocessing.org/sketch/373821 here!]

== Unity ==

[https://www.uni-weimar.de/medien/wiki/Unitycode Unity Code]

<gallery>
image:Screen_Shot_2016-05-31_at_16.24.16.png|
image:Screen_Shot_2016-05-31_at_16.24.33.png|
image:Screen_Shot_2016-05-31_at_16.24.48.png
image:Screen_Shot_2016-05-31_at_16.25.02.png|

</gallery>
[[File:Screen_Shot_2016-05-31_at_16.35.48.png]]

GMU:Digital Puppetry Lab/Group B0XJUMP

2016-05-31T14:42:12Z

TVischer:

In our little game a boxer fights a '''battle of life or restart''' against an army of boxing gloves. To have the ability of jumping and escaping his enemies, he needs your support: Every time you clap our little boxer jumps out of the way!!

== Blender ==
Models used in Blender:

<gallery>
image:BlenderB0XJUMP1.png|
image:BlenderB0XJUMP2.png|
</gallery>

== Processing ==
<gallery>
image:B0XJUMPpro1.png|
image:B0XJUMPpro2.png|
image:B0XJUMPpro3.png
</gallery>

We used the Minim Library in Processing to adapt the sound of clapping through the microphone to send a Osc command, the sketch can be viewed [http://www.openprocessing.org/sketch/373821 here!]

== Unity ==

[https://www.uni-weimar.de/medien/wiki/Unitycode Unity Code]

<gallery>
image:Screen_Shot_2016-05-31_at_16.24.16.png|
image:Screen_Shot_2016-05-31_at_16.24.33.png|
image:Screen_Shot_2016-05-31_at_16.24.48.png
image:Screen_Shot_2016-05-31_at_16.25.02.png|
image:Screen_Shot_2016-05-31_at_16.35.48.png
</gallery>

GMU:Digital Puppetry Lab/Group B0XJUMP

2016-05-31T14:41:14Z

TVischer:

In our little game a boxer fights a '''battle of life or restart''' against an army of boxing gloves. To have the ability of jumping and escaping his enemies, he needs your support: Every time you clap our little boxer jumps out of the way!!

== Blender ==
Models used in Blender:

<gallery>
image:BlenderB0XJUMP1.png|
image:BlenderB0XJUMP2.png|
</gallery>

== Processing ==
<gallery>
image:B0XJUMPpro1.png|
image:B0XJUMPpro2.png|
image:B0XJUMPpro3.png
</gallery>

We used the Minim Library in Processing to adapt the sound of clapping through the microphone to send a Osc command, the sketch can be viewed [http://www.openprocessing.org/sketch/373821 here!]

== Unity ==

[https://www.uni-weimar.de/medien/wiki/Unitycode Unity Code]

<gallery>
image:SCREEN SHOT 2016-05-31 AT 16.24.16.PNG|
image:Screen_Shot_2016-05-31_at_16.24.33.png|
image:Screen_Shot_2016-05-31_at_16.24.48.png
image:Screen_Shot_2016-05-31_at_16.25.02.png|
image:Screen_Shot_2016-05-31_at_16.35.48.png
</gallery>

GMU:Digital Puppetry Lab/Group B0XJUMP

2016-05-31T14:40:56Z

TVischer:

In our little game a boxer fights a '''battle of life or restart''' against an army of boxing gloves. To have the ability of jumping and escaping his enemies, he needs your support: Every time you clap our little boxer jumps out of the way!!

== Blender ==
Models used in Blender:

<gallery>
image:BlenderB0XJUMP1.png|
image:BlenderB0XJUMP2.png|
</gallery>

== Processing ==
<gallery>
image:B0XJUMPpro1.png|
image:B0XJUMPpro2.png|
image:B0XJUMPpro3.png
</gallery>

We used the Minim Library in Processing to adapt the sound of clapping through the microphone to send a Osc command, the sketch can be viewed [http://www.openprocessing.org/sketch/373821 here!]

== Unity ==

[https://www.uni-weimar.de/medien/wiki/Unitycode Unity Code]

<gallery>
image:FILE:SCREEN SHOT 2016-05-31 AT 16.24.16.PNG|
image:Screen_Shot_2016-05-31_at_16.24.33.png|
image:Screen_Shot_2016-05-31_at_16.24.48.png
image:Screen_Shot_2016-05-31_at_16.25.02.png|
image:Screen_Shot_2016-05-31_at_16.35.48.png
</gallery>

File:Screen Shot 2016-05-31 at 16.35.48.png

2016-05-31T14:36:16Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-05-31 at 16.25.02.png

2016-05-31T14:35:23Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-05-31 at 16.24.48.png

2016-05-31T14:34:57Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-05-31 at 16.24.33.png

2016-05-31T14:34:29Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:Screen Shot 2016-05-31 at 16.24.16.png

2016-05-31T14:33:51Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

Unitycode

2016-05-31T14:33:07Z

TVischer: Created page with "==Jump Script listening to Osc commands== using UnityEngine; using System.Collections; public class jump : MonoBehaviour { public float jumpForce; public AudioClip[] audioCl..."

==Jump Script listening to Osc commands==

using UnityEngine;
using System.Collections;

public class jump : MonoBehaviour {

public float jumpForce;
public AudioClip[] audioClip;

public float moveForward;

private Rigidbody myRigidbody;

public static bool canJump = false;

public string RemoteIP = "127.0.0.1";

// the port IanniX is listening on (we send messages to)
public int RemotePort = 1234;

// the port that Unity is listening only listening port matters for receiving
public int LocalPort = 12001;

private Osc osc;
private Udp udp;
//->might use these instead!
Animator myAnimator;
OscMessageHandler AllMessageHandler;

// define the audio clips
public AudioClip clipGround;
public AudioClip clipHandschuh;
public AudioClip clipSuccess;
public AudioClip clipFailure;

private AudioSource audioGround;
private AudioSource audioHandschuh;
private AudioSource audioSuccess;
private AudioSource audioFailure;

GameObject handschuh;

private bool succeeded;

void OnCollisionEnter (Collision other){
if (other.gameObject.tag == "ground") {
canJump = true;
Debug.Log ("collision with ground");
audioGround.Play();

if (handschuh.transform.position.x < transform.position.x) {
if (!succeeded) {
audioSuccess.Play ();
succeeded = true;
}
if (handschuh.transform.position.x + 4 < transform.position.x) {
Application.LoadLevel (0);
}
}

}
else if (other.gameObject.tag == "boxhandschuh") {
audioHandschuh.Play ();
}
}

// Use this for initialization
void Start () {

myRigidbody = GetComponent<Rigidbody> ();
myAnimator = GetComponent<Animator> ();

// Verbindungen über Udp und Osc laden
udp = (Udp) GetComponent("Udp");
osc = (Osc) GetComponent("Osc");

udp.init(RemoteIP, RemotePort, LocalPort);
osc.init(udp);

osc.SetAllMessageHandler(AllMessageHandler);

handschuh = GameObject.FindGameObjectWithTag("boxhandschuh");

}

void Awake(){
//from http://answers.unity3d.com/questions/240468/how-to-play-multiple-audioclips-from-the-same-obje.html
audioGround = AddAudio(clipGround, false, false, 0.2f);
audioHandschuh = AddAudio(clipHandschuh, false, false, 0.4f);
audioSuccess = AddAudio(clipSuccess, false, false, 0.8f);
audioFailure = AddAudio(clipFailure, false, false, 0.8f);
}

// Update is called once per frame
void Update () {

if (Input.GetKeyDown (KeyCode.Space) || Osc.MessageWas) {

Osc.MessageWas = false;

if (canJump == true) {
myRigidbody.velocity = new Vector3 (0, jumpForce, 0);
canJump = false;

}
}

if (transform.position.y < -3) {
audioFailure.Play ();
}
if (transform.position.y < -7) {
//SceneManager.LoadScene (0);
Application.LoadLevel (0);
}
}

void OnDisable()
{
Debug.Log("Closing UDP socket");
osc.Cancel();
osc = null;
}

public AudioSource AddAudio (AudioClip clip, bool loop, bool playAwake, float vol) {

AudioSource newAudio = gameObject.AddComponent<AudioSource>();

newAudio.clip = clip;
newAudio.loop = loop;
newAudio.playOnAwake = playAwake;
newAudio.volume = vol;

return newAudio;

}

}

GMU:Sensor Hacklab

2016-05-24T20:45:32Z

TVischer:

===.·:·.iMaginIng.·:*¨*¨*aNd*¨*:·.iNvEntiNg.·:*¨nEw*:·.¨*:·.M3cHaniSms·:*¨*:f0r·.*:·.iNterPreTinG*:·.·:*¨*Th3·:*¨3nVironMenT*!.·:===
[[:Category:Fachmodul|Fachmodul]]/[[:Category:Werkmodul|Werkmodul]] 
''Lecturer:'' [http://katihyyppa.com/ Kati Hyyppä] 
''Credits:'' 6 [[ECTS]], 4 [[SWS]] 
''Date:'' Blockmodul (see timetable below) 
''Venue:'' [[Marienstraße 7b]], Room 201 
''First meeting:'' 13.05.16, 13:00 
''Course Hashtag:'' #wemakemachinesnotart

===.·:*¨*:·.DeScRiPTioN.·:*¨*:·.===
imagining and inventing new mechanisms for interpreting the environment

Sensor HackLab proposes an art-making methodology where concept and aesthetics emerge through hands-on investigation of electricity and the materiality of technology. Here, we will focus on building devices and prototypes that consider alternative ways of sensing and responding to the environment. We aim to go beyond the capabilities of consumer electronics made to measure the world by imagining technology that connects us to the environment (and the environment to us) in adventurous ways.

This course takes a bottom-up approach to the electronic medium through techniques such as deconstruction; experimental circuit design; pattern recognition and reverse-engineering. By employing processes that make the hidden inner world of machines accessible, it also seeks to critique the economic systems embedded throughout electronic media and its impact on humans and nature.

This course is best suited for students that have already taken an introduction to electronics course. 
We will explore different kinds of sensors mainly using Arduino microcontroller boards. No prior experience of Arduino is required.

~~

Sensor HackLab schlägt den Pfad einer Kunstmethodik ein, aus der Konzept und Ästhetik aus einer haptischen Untersuchung voN Elektronik und der Materialität von Technik erwächst. Wir konzentrieren uns hier darauf Geräte und Prototypen zu bauen die alternative Möglichkeiten bereitstellen die Umwelt zu erfahren und darauf zu reagieren. Wir zielen darauf ab uns auf ein Abenteuer einzulassen die Grenzen und Möglichkeiten von Geräten, die gemacht sind die Welt zu quantifizieren, hinter uns zu lassen in dem wir Technologien entwickeln die uns mit der Umwelt (und die Umwelt mit uns) verbinden.

Dieser Kurs basiert auf einem bottom-up Ansatz sich dem elektronischen Medium durch Dekonstruktivismus, experimentellem Schaltungsdesign, Erkennen von Mustern und Reverseengineering zu nähern. Der Kurs strebt auch nach einer Kritik in wirtschaftlichen Systemen integrierter elektronischer Medien und deren Einfluss auf Menschheit und Natur mittels Prozessen, die die verborgenen inneren Welten von Maschinen offenbaren.

Wir experimentieren mit unterschiedlichen Sensoren. Hauptsächlich verwenden wir dabei das Arduino Mikrokontroller Board. 
Vorerfahrungen mit dem Arduino sind für diesen Kurs nicht notwendig.

==.·:*¨*:·.ImP0RtaNT.·:*¨*:·.==

1 - This is a studio course where students are given time and space in class to develop their work. Presence is taken very seriously. Late arrivals and absence are not tolerated.

2 – Students taking the GMU Project Module (GMU) have priority for this course, because this course is a requirement for those modules.

3 – Register via email before 15.04.2016

'''To:''' khyyppa@gmail.com 
'''Subject:''' Sensor HackLab /// Application 
'''Content:'''
* Name, Surname
* program and semester (Studienprogramm und Fachsemester)
* matriculation number (Matrikelnummer)
* Valid email address @uni-weimar.de
* Your project module
* Students must also acknowledge that they have read the course description online and that they can commit to the class schedule (http://www.uni-weimar.de/medien/wiki/GMU:Sensor_Hacklab).

4 – There is at 20€ material fee for this course

==.·:*¨*:·.GraDiNg.·:*¨*:·.==
* 1. Assignments 60%
* 2. Attendance 20%
* 3. Participation/work in progress 20%

==.·:*¨*:·.C0uRs3 TiMetaBLe.·:*¨*:·.==

{| class="wikitable"
|-
| 13.05.16
| 13:00 - 18:00
| BLOCK 1
|-
| 14.05.16
| 11:00 - 16:00
| BLOCK 1
|-
| 15.05.16
| 11:00 - 16:00
| BLOCK 1
|-
| 20.05.16
| 13:00 - 18:00
| BLOCK 2
|-
| 21.05.16
| 11:00 - 16:00
| BLOCK 2
|-
| 22.05.16
| 11:00 - 16:00
| BLOCK 2
|-
| 03.06.16
| 13:00 - 18:00
| BLOCK 3
|-
| 04.06.16
| 11:00 - 16:00
| BLOCK 3
|-
| 05.06.16
| 11:00 - 16:00
| BLOCK 3
|}

==.·:*¨*:·.mAiLinG liSt.·:*¨*:·.==

Once you are registered for the course you must sign up for the GMU mailing list: http://www.uni-weimar.de/medien/wiki/GMU:Mailinglist

==.·:*¨*:·.ELiGibl3 PARTIciPANTS.·:*¨*:·.==

BA + MA:
* Medienkunst und Gestaltung
* Medienarchitektur
* Visuelle Kommunication
* Productdesign
* Medienwissenschaften

'''Note:''' Applications from students that have signed up for the project module at GMU, will be favoured, because this course is a requirement for those modules.

GMU is interested in projects that bridge notions of Sensing and Performance.
Priority for this course will be given to students enrolled in the GMU project module or one of the GMU Werk- and Fach-modules dedicated to bridging notions of sensing and performance together.

== .·:*¨*:·.L4ngUaGe.·:*¨*:·. ==

The course will be taught in English

[[Category:SS16]]
[[Category:Darsha Hewitt]]

==.·:*¨*:·.ParTiciPants.·:*¨*:·.==

* [[/Amy Barnett/]]
* [[/Christian Doeller/]]
* [[/Maike Effenberg /]]
* [[/Aline Martinez/]]
* [[/Anna Pfannstiel/]]
*[[/Azucena Sanchez /]]
*[[/Philipp Schmalfuß /]]
* [[/Rachel Smith /]]
* [[/Tim Vischer/]]

GMU:Digital Puppetry Lab

2016-04-15T10:01:12Z

TVischer:

[[Image:Digital-puppetry.png|thumb|left|200px|''Chinese Shadows'' by Ferdinand du Puigaudeau]]

'''Digital Puppetry Lab''' — Introduction to the ''Interactive Performance Platform''

[[:Category:Werkmodul|Werkmodul]]/[[:Category:Fachmodul|Fachmodul]] 
''Lecturer:'' [[Martin Schneider]] 
''Credits:'' 6 [[ECTS]], 4 [[SWS]] 
''Date:'' Tuesday 19:00 - 20:30 (weekly) + Wednesday 17:00 - 20:30 (biweekly)          '''Blockmodul (15. - 17. April)''' 
''Venue:'' [[Performance Platform]], Digital Bauhaus Lab 
''First meeting:''' TUESDAY, 12. April, 19:00h'''

 

'''This is a hands on course that is required for project modules by GMU and EXPTV.'''

Note:
'''Application is now closed.'''
'''All applicants are invited to the Kickoff meeting at the DBL is on TUESDAY, 19:00h.'''

== Weekend Workshop ==

=== Be Prepared ===

Please make sure to install the software on your laptops at home. 
We will start using it right away and have no time for installation during the course.

* [https://www.blender.org/download/ Blender]
* [https://unity3d.com/get-unity/download?ref=personal Unity]
* [http://www.iannix.org/en/download-iannix/ Iannix]
* [https://processing.org/download/?processing Processing] (Version 3.0.2)
* [https://puredata.info/downloads/pd-extended/releases/0.43.4 Pure Data Extended] (0.43.4)

=== Schedule ===

{| class="wikitable"
! colspan="3" | FRIDAY
|-
!11:00 - 11:45
|Intro to the Wiki
|Martin
|-
!11:45 - 12:30
| Intro to OSC, Iannix and Processing
| Martin
|-
| colspan="3" style="text-align:center"| ''Lunch Break''
|-
!13:30 - 14:15
| Intro to MAX-MSP + Puredata
| Martin, Benjamin
|-
!14:15 - 15:00
| Intro to Blender + Unity
| Luca, Miga
|-
!15:15 - 16:00
| Intro to Unity I
| Luca
|-
!16:00 - 16:45
| Intro to Unity II
| Luca
|-
! colspan="3" | SATURDAY
|-
! 10:00 - 12:30
| Hands-On Blender
| Su-Li, Benjamin, Stephan, Luca
|-
| colspan="3" style="text-align:center"| ''Lunch Break''
|-
! 13:30 - 16:00
| Hands-On Blender
| Su-Li, Benjamin, Stephan, Luca
|-
! 16:00 - 18:30
| Hands-On Blender
| Su-Li, Benjamin, Stephan, Luca
|-
! colspan="3" | SUNDAY
|-
!10:00 - 12:30
| Hands-On Blender
| Su-Li, Stephan, Luca + X
|-
| colspan="3" style="text-align:center"| ''Lunch Break''
|-
!13:30 - 16:00
| Hands-On Blender
| Su-Li, Stephan, Luca + X
|-
!16:00 - 16:45
| Demo in the DBL
| Martin, Luca
|}

== Beschreibung ==

Das Modul vermittelt die nötigen Grundkenntinisse um interaktive Performances mit Hilfe der Performance-Plattform des Digital Bauhaus Labs zu erstellen.

Nach einem einführende Blockmodul (15. - 17. April) geht es im Rahmen der wöchentlichen Veranstaltung um den praktischen Umgang mit den entsprechenden Software-Werkzeugen und Programmier-Umgebungen.

Am Ende des Moduls sollen die Studierenden in der Lage sein, eigene Setups zu erstellen, die aus menschliche Bewegung, Interaktion, und Tanz immersive visuelle und akkustische Umgebungen erzeugen.

== Description ==

This course will teach you basic skills required to create interactive performances, using the Peformance Platform of the Digital Bauhaus Lab.

By the end of the course you will be able to create your own immersive setup for generating live audio and visuals from human motion, interaction and dance.

== Language ==

The course is in English, because not all participants are speaking German.

== Eligible Participants ==

Undergraduates and graduates enrolled in the faculties of:

* Media Art + Design
* Media Architecture
* Visual Communication
* Product Design

== Participants ==

* [[/Martin Schneider|Martin Schneider]]
* [[/Fiona Mortimer|Fiona M]]
* [[User:EmilioAguas|''Emilio Aguas'']]
* [[/Jessica Hüttig|Jessica Hüttig]]
* [[/Kan Feng|Kan Feng]]
+ [[/Priyanka Srinivasagopalan|Priyanka Srinivasagopalan]]
* [[/Tim Vischer|Tim Vischer]]

*[[/FANXZ|Xiangzhen Fan]]

== Application ==

Applications from students that have signed up for the project modules at GMU or EXPTV, will be favoured, because this course is a requirement for those modules.

'''To:''' [[User:ms|Martin Schneider]] 
'''Subject:''' Digital Puppetry Lab /// Application 
'''Content:'''

* Name, Surname
* program and semester (Studienprogramm und Fachsemester)
* matriculation number (Matrikelnummer)
* Valid email address @uni-weimar.de
* Your project module

== Syllabus ==
* First Meeting 12. April (Tuesday)
* Block-Weekend 15. - 17. April

The syallbus includes:
* Introduction to the Tracking System
* Basics of Networking with OSC
* Basics of 3D-Modelling and Rigging
* Programming Interactive 3D Graphics
* Programming interactive Sound in Space

== Evaluation ==
* 20% Presence and active participation
* 50% Creation of an interactive setup
* 30% Documentation on the wiki

== Books ==
''to be done''

== Links ==

* [[www.thecaptury.com|The Captury]]
* [[www.blender.org|Blender]] (3D Modelling)
* [[www.unity3d.com|Unity]] (3D Game Engine)
* [[www.iannix.org|Iannix]] (Visual Synthesizer for OSC)
* [[www.sojamo.de/libraries/oscP5/|OSC for Processing]]
* [[trippylighting.com/teensy-arduino-ect/touchosc-and-arduino-oscuino|TouchOSC + OSCuino]]
* [[Pure Data]]
* [[Max MSP]]

[[Category:SS16]]
[[Category:Werkmodul]]
[[Category:Fachmodul]]
[[Category:Martin Schneider]]

[[Category:Tracking]]
[[Category:OSC]]
[[Category:Blender]]
[[Category:Dataflow]]

GMU:BioArt WS15/Tim Vischer

2016-04-07T17:00:28Z

TVischer:

==WoodenRecord==

I want to produce a vinyl record out of a piece of tree trunk using a Lasercutter for engraving a .wav file playing recorded natural noises into it. Later on i want to expose a second trunk after the cutting part back again into nature for half a month to give it back to it and see how that influences the sounds. 

<gallery>
image:woodrecord1.png |
</gallery>

==Process==

First im sending an edited .wav file into an wav to text editor using an Python Code, the .wav file needs to be amplified and high sounds needs to be pitched otherwise they are not recognisable in the cut for the needle. The .wav to .txt code analyses the soundwaves and recreates it into coordinates that would build an round spiral with the sound information readable for an Vinyl player on it.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.49.png | Python code
image:Screen_Shot_2016-04-07_at_17.53.50.png | .txt file
</gallery>

With this .txt file full of coordinates im feeding an Processing code wich is turning them in an actual Vector file. Cause of the big amount of data the path gets split into 7 separate .pdf files.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.01.png | Processing code
</gallery>

Here you see the vector file from the original .wav converted through Python and then Processing.

<gallery>
image:woodrecord3.png | Vector file
image:Screen_Shot_2016-04-07_at_17.59.07.png| Detail
image:Screen_Shot_2016-04-07_at_18.02.15.png| Detail
</gallery>

== Test results==

<gallery>
image:IMG_8100.png |Test with mdf plate
image:IMG_81021.png |Detail
</gallery>
<gallery>
image:IMG_8095.png | Test on Vinyl Player
image:IMG_80971.png| Test on Vinyl Player
</gallery>

You can view a video of the first test with amplified audio [https://www.youtube.com/watch?v=lGxN1MoKIOA&feature=youtu.be here].

==Current State==

At the moment im fine tuning the audio quality, also some problems with cutting on a rougher surface than mdf plates needs to get fixed.

One big problem of cutting the file into an real slice of an tree trunk are the different degrees of hardness of the year rings of the tree, the laser will cut into weaker areas deeper than into harder and older ones.

<gallery>
image:IMG_8103.png | Wood i want to cut in: Oak
image:IMG_8104.png | Wood i want to cut in: Birch
</gallery>

After fixing these problems i can finally expose them back to nature, to see how the sound reacts to being rotten.

GMU:BioArt WS15/Tim Vischer

2016-04-07T16:57:26Z

TVischer:

==WoodenRecord==

I want to produce a vinyl record out of a piece of tree trunk using a Lasercutter for engraving a .wav file playing recorded natural noises into it. Later on i want to expose a second trunk after the cutting part back again into nature for half a month to give it back to it and see how that influences the sounds. 

<gallery>
image:woodrecord1.png |
</gallery>

==Process==

First im sending an edited .wav file into an wav to text editor using an Python Code, the wav. file needs to be amplified and high sounds needs to be pitched otherwise they are not recognisable in the cut for the needle. The .wav to .txt code analyses the soundwaves and recreates it into coordinates that would build an round spiral with the sound information readable for an Vinyl player on it.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.49.png | Python code
image:Screen_Shot_2016-04-07_at_17.53.50.png | .txt file
</gallery>

With this txt. file full of coordinates im feeding an Processing code wich is turning them in an actual Vector file. Cause of the big amount of data the path gets split into 7 separate .pdf files.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.01.png | Processing code
</gallery>

Here you see the vector file from the original .wav converted through Python and then Processing.

<gallery>
image:woodrecord3.png | Vector file
image:Screen_Shot_2016-04-07_at_17.59.07.png| Detail
image:Screen_Shot_2016-04-07_at_18.02.15.png| Detail
</gallery>

==Current State==

At the moment im fine tuning the audio quality, also some problems with cutting on a rougher surface than mdf plates needs to get fixed.

One big problem of cutting the file into an real slice of an tree trunk are the different degrees of hardness of the year rings of the tree, the laser will cut into weaker areas deeper than into harder and older ones.

<gallery>
image:IMG_8103.png | Wood i want to cut in: Oak
image:IMG_8104.png | Wood i want to cut in: Birch
</gallery>

After fixing these problems i can finally expose them back to nature, to see how the sound reacts to being rotten.

== Intermediate result==

<gallery>
image:IMG_8100.png |Test with mdf plate
image:IMG_81021.png |Detail
</gallery>
<gallery>
image:IMG_8095.png | Test on Vinyl Player
image:IMG_80971.png| Test on Vinyl Player
</gallery>

You can view a video of the first test with amplified audio [https://www.youtube.com/watch?v=lGxN1MoKIOA&feature=youtu.be here].

File:IMG 81021.png

2016-04-07T16:56:37Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 80971.png

2016-04-07T16:54:33Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 8097.png

2016-04-07T16:53:06Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 8095.png

2016-04-07T16:52:09Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 8100.png

2016-04-07T16:49:16Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 8102.png

2016-04-07T16:48:49Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

GMU:BioArt WS15/Tim Vischer

2016-04-07T16:45:22Z

TVischer:

==WoodenRecord==

I want to produce a vinyl record out of a piece of tree trunk using a Lasercutter for engraving a .wav file playing recorded natural noises into it. Later on i want to expose a second trunk after the cutting part back again into nature for half a month to give it back to it and see how that influences the sounds. 

<gallery>
image:woodrecord1.png |
image:IMG_8103.png | Wood i want to cut in: Oak
image:IMG_8104.png | Wood i want to cut in: Birch
</gallery>

==Process==

First im sending an edited .wav file into an wav to text editor using an Python Code, the wav. file needs to be amplified and high sounds needs to be pitched otherwise they are not recognisable in the cut for the needle. The .wav to .txt code analyses the soundwaves and recreates it into coordinates that would build an round spiral with the sound information readable for an Vinyl player on it.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.49.png | Python code
image:Screen_Shot_2016-04-07_at_17.53.50.png | .txt file
</gallery>

With this txt. file full of coordinates im feeding an Processing code wich is turning them in an actual Vector file. Cause of the big amount of data the path gets split into 7 separate .pdf files.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.01.png | Processing code
</gallery>

Here you see the vector file from the original .wav converted through Python and then Processing.

<gallery>
image:woodrecord3.png | Vector file
image:Screen_Shot_2016-04-07_at_17.59.07.png| Detail
image:Screen_Shot_2016-04-07_at_18.02.15.png| Detail
</gallery>

==Current State==

At the moment im fine tuning the audio quality, also some problems with cutting on a rougher surface than mdf plates needs to get fixed.

One big problem of cutting the file into an real slice of an tree trunk are the different degrees of hardness of the year rings of the tree, the laser will cut into weaker areas deeper than into harder and older ones.

After fixing these problems i can finally expose them back to nature, to see how the sound reacts to being rotten.

Test with mfd plate.

<gallery>
image:Screen_Shot_2016-04-07_at_17.56.01.png | Processing code
</gallery>

You can view a video of the first test with amplified audio [https://www.youtube.com/watch?v=lGxN1MoKIOA&feature=youtu.be here].

File:IMG 8104.png

2016-04-07T16:42:03Z

TVischer:

== Summary ==

== Copyright status: ==

== Source: ==

File:IMG 8103.png

2016-04-07T16:41:31Z

TVischer: