Medien Wiki - User contributions [en]

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:22:15Z

Soci8217: /* - Playing */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

===- Preparing the Instruments===
[[File:2019-10-04 17.30.jpeg|400px]]

Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

===- Training===
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|400px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|400px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

===- Clustering===
[[File:clustering.png|400px]]
[[File:window.png|400px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

===- Playing===
[[File:2019-10-05 19.18.mov|600px]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|400px]]

To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:21:48Z

Soci8217: /* Playing */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

===- Preparing the Instruments===
[[File:2019-10-04 17.30.jpeg|400px]]

Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

===- Training===
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|400px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|400px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

===- Clustering===
[[File:clustering.png|400px]]
[[File:window.png|400px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

===- Playing===
[[File:2019-10-05 19.18.mov]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|400px]]

To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:21:20Z

Soci8217: /* Implementation */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

===- Preparing the Instruments===
[[File:2019-10-04 17.30.jpeg|400px]]

Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

===- Training===
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|400px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|400px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

===- Clustering===
[[File:clustering.png|400px]]
[[File:window.png|400px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|400px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:20:17Z

Soci8217: /* Preparing the Instruments */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

====Preparing the Instruments====
[[File:2019-10-04 17.30.jpeg|400px]]

Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

====Training====
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|200px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|200px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

====Clustering====
[[File:clustering.png|200px]]
[[File:window.png|200px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|200px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:19:43Z

Soci8217: /* Initial Idea */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

====Preparing the Instruments====
[[File:2019-10-04 17.30.jpeg|200px]]
Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

====Training====
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|200px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|200px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

====Clustering====
[[File:clustering.png|200px]]
[[File:window.png|200px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|200px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T22:19:07Z

Soci8217:

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|200px]]
[[File:small-drum-set.png|200px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.

As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.

1. The user taps on the drum.

2. The piezo mic grabs the sound.

3. The program detects the unique frequency of the sound.

4. An equivalent drum sound is produced.

Following challenges immediately arose.

- How to ensure the sounds being fed are unique enough to be classified into different patterns?

- How to realize pedal movements?

- How to allow multiple drums to be detected and played?

- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

====Preparing the Instruments====
[[File:2019-10-04 17.30.jpeg|200px]]
Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

====Training====
video link: [[:File:training-final.mp4]]

To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|200px]]

What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.

[[File:bark.png|200px]]

One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

====Clustering====
[[File:clustering.png|200px]]
[[File:window.png|200px]]

After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]

Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.

[[File:sampleswap.PNG|200px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.

Here is the final audio file: [[:File:drum-kit.wav]]

This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

File:Training-final.mp4

2019-10-05T22:18:08Z

Soci8217: Soci8217 uploaded a new version of File:Training-final.mp4

File uploaded with MsUpload

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T17:48:24Z

Soci8217: /* =Limitations */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.
As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.
1. The user taps on the drum.
2. The piezo mic grabs the sound.
3. The program detects the unique frequency of the sound.
4. An equivalent drum sound is produced.

Following challenges immediately arose.
- How to ensure the sounds being fed are unique enough to be classified into different patterns?
- How to realize pedal movements?
- How to allow multiple drums to be detected and played?
- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

====Preparing the Instruments====
[[File:2019-10-04 17.30.jpeg|400px]]
Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

====Training====
[[:File:training-final.mp4]]
To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|400px]]
What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.
[[File:bark.png|400px]]
One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

====Clustering====
[[File:clustering.png|400px]]
[[File:window.png|400px]]
After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]
Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.
[[File:sampleswap.PNG|400px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.
Here is the final audio file: [[:File:drum-kit.wav]]
This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

===Limitations===

- Limited Timbral Differences

Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.

- Lack of Pedal Movements

This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.

- Singularity of an Input Sound

Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.

- Lack of Ubiquity

Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T17:47:37Z

Soci8217: /* A tiny little drum made by clustering and mapping the sounds */

= Mini Electronic Drum Set =
== A tiny little drum made by clustering and mapping the sounds ==

===Motivation===
The idea was to recreate a small and simple version of a drum kit, where the sounds are processed electronically to be mapped to a corresponding drum sounds. The motivation came from the fact that I have recently started to learn to play drums and potentially use this small set to practice drumming at home with headphones on, while not having to disturb anyone (which turned out to be a naive speculation).

===Initial Idea===
[[File:real-drum-set.png|400px]]
[[File:small-drum-set.png|400px]]

The picture on the right is the initial sketch of the drum set. Each piece is color-coded to its equivalent drum in a set depicted in the left picture; all toms and the snare in red while all cymbals and the hi-hat in yellow. The two blue circles were drawn to represent the tap buttons for pedal movements which manipulates the bass drum and the hi-hat.
As shown in the sketch, I planned to recycle the materials that can be found easily. For example, wine corks for toms and the snare, and beer caps for cymbals and the hi-hat, and finally a metal box with a piezo mic attached inside which becomes the platform for all the drums.

Here are the steps how I thought it should work in the beginning.
1. The user taps on the drum.
2. The piezo mic grabs the sound.
3. The program detects the unique frequency of the sound.
4. An equivalent drum sound is produced.

Following challenges immediately arose.
- How to ensure the sounds being fed are unique enough to be classified into different patterns?
- How to realize pedal movements?
- How to allow multiple drums to be detected and played?
- How to map the intensity and lasting of each output sound to the input sound? Would the texture of materials matter?

===Implementation===
I used the timbreID[https://github.com/wbrent/timbreID], a library for analyzing audio feature in Pure Data(Pd). In particular, its drum kit example already had the function to map the sample drum sounds to the real-time input sounds.

====Preparing the Instruments====
[[File:2019-10-04 17.30.jpeg|400px]]
Before the playback, the timbreID must be trained with sounds that are timbrally different to one another. In the initial setup, there were only 4 classifications available, but I added two more. To produce timbrally different and sounds, I used various materials from beer caps to wine corks as planned. Also to make sharp and short-duration sounds, I decided to use the metal chopsticks to tap with, rather than with fingers which was my original plan. With some experiments, I found the combination that worked somewhat well.

====Training====
[[:File:training-final.mp4]]
To train, “train” spigot should be turned on. Input sounds are made by tapping on different objects for 5-10 times. Here I am tapping each instrument about 10 times. Each input are shown in the Pd’s window.
[[File:2019-10-05 19.10.gif|400px]]
What happens here is that they are detected by ‘bark~’ in the ‘pd onsets’ sub-patch, which measures the amount of growth in bands of an input’s spectrum. Here I lowered the debounce setting to 50 ms for which it will be deaf. It was set as high as 200ms initially to prevent the sample playback to retrigger the playback, but it could be lowered to play in a bit quicker rythme by using the headphones.
[[File:bark.png|400px]]
One more thing to note here is that the master volume should be mute as the feedback sample output will be included in the training input. After training, the ‘train’ spigot should be turned off again.
The training dataset can be saved with the ‘write’ message and can be read again with the ‘read’ message. I added additional write and read messages for backup.

====Clustering====
[[File:clustering.png|400px]]
[[File:window.png|400px]]
After training, the input sounds should be grouped by different timbral sounds with the ‘cluster’ message. Here I changed the number of cluster items from 4 to 6. Each cluster can be printed out in the Pd’s window with the radio buttons connected to the ‘cluster list’. The numbers represent the members based on the input order, starting from 0.

====Playing====
[[File:2019-10-05 19.18.mov]]
Finally you can play the instruments by hitting one by one. This is because there is only one input channel at the moment. Notice how different instrument lead to playback of different sample. Here what happens is that the program tries to find the set of data previously trained that best matches the input sound. When the ‘id’ spigot is turned on, the cluster number will be printed out on the Pd’s window whenever the sample is played back.
For the playback, I loaded my own drum samples to fit my mini drum set-up.
I got each audio sample from the SampleSwap[https://sampleswap.org/filebrowser-new.php?d=DRUMS+%28FULL+KITS%29%2FDRUM+MACHINES%2F], an audio sample sharing site. Then I put them together into one audio file with even 1s interval, for it to be processed in the Pd.
[[File:sampleswap.PNG|400px]]
To add sample items, I also had to change the array ‘drum-kit-times’ as such.
Here is the final audio file: [[:File:drum-kit.wav]]
This example also has a functionality to record sequences. It is pretty straightforward to use; toggle recording by ‘record-on-off’ button and adjust tempo with the slider while playing it.

====Limitations===
- Limited Timbral Differences
Even with an effort to find materials with different enough textures to produce unique audio when tapped, some materials tend to fall into the same category of sounds. For example, the aluminium lid and the plastic gum container that I used for crash cymbal and open hi-hat respectively, sometimes were recognized to be in the same category. Obviously, classification gets more accurate as the number of audio items reduces. For this reason, I had to reduce the number of items, omitting the kick sound.
- Lack of Pedal Movements
This drum set, while being cute, cannot fully be used for practice because its missing pedals. I initially thought of introducing them by thumb tapping, but noticed that two thumb tap sounds would have exact same timbral sound and cannot be distinguished with the current single input setting. In the end, I realized it by attaching a wide aluminium juice lid onto the slipper and register the sound by tapping on the foot, but it cannot be used with the piezo mic setting which is a huge disadvantage.
- Singularity of an Input Sound
Obviously, one of the biggest limitation when it comes to practicality is the fact that it can only process one sound at a time. Because you cannot play multiple drums at a time with some inherent latency in playback, it cannot quite produce useful beat in the end. This problem can be solved by introducing multiple piezo mics and feeding the inputs into different Pd programs.
- Lack of Ubiquity
Due to the lack of time and technical issues, I had to process the patch on my laptop. It could have better fit the overall purpose of the course if I could utilize the Raspberry Pi, in the sense of ubiquity and collaboration of embedded systems. This can been done by installing the pd patch in a Raspberry Pi where the piezo mic is connected to its sound card, along with some sort of sound output device.

File:Drum-kit.wav

2019-10-05T17:46:41Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Sampleswap.PNG

2019-10-05T17:46:02Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

GMU:Autonomous-Collaborative/Hiyeon

2019-10-05T17:44:53Z

Soci8217: Created page with " = Mini Electronic Drum Set = == A tiny little drum made by clustering and mapping the sounds == ===Motivation=== The idea was to recreate a small and simple version of a dru..."

File:2019-10-05 19.18.mov

2019-10-05T17:42:59Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Window.png

2019-10-05T17:41:36Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Clustering.png

2019-10-05T17:40:50Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Bark.png

2019-10-05T17:39:46Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:2019-10-05 19.10.gif

2019-10-05T17:38:30Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Training-final.mp4

2019-10-05T17:37:40Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:2019-10-04 17.30.jpeg

2019-10-05T17:36:02Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Small-drum-set.png

2019-10-05T17:30:32Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

File:Real-drum-set.png

2019-10-05T17:29:00Z

Soci8217: File uploaded with MsUpload

File uploaded with MsUpload

GMU:Autonomous-Collaborative

2019-10-05T17:21:41Z

Soci8217: /* Documentation */

''Lecturer:'' [[GMU:Max Neupert|Max Neupert]] 
''Credits:'' 6 [[ECTS]], 4 [[SWS]] 
''Date:'' Weekly: 08.04.-17.06. Mondays, 09:15-12:30, and extra block: 07.+08.06. 10:00-16:45 
''Venue:'' [[Marienstraße 7b]], [[Marienstraße 7b/204|Raum 204]] 
''First meeting:'' April 8th 09:15

==Description==
'''Autonomous — Collaborative. Auditory interaction on embedded systems'''

From the ubiquity of smart phones, the internet of things to Eurorack synthesizers: Linux running on miniature computers is playing an ever extending role and is present in every day life as well as in obscure special interest scenes.
In the class "Autonomous - Collaborative" we design conceptual and applied interactions with microphones and speakers. The units based on a RaspberryPi can interact and communicate with itself, with other units or a human user.
While working on our project we gather experience and knowledge in the fields of electronics, Linux, Pure Data and concepts of sound synthesis, interaction as well as machine learning and software agents.

A RaspberryPi will be lent to you for the class. In addition we will build an universal USB audio interface with preamp for contact microphones. Costs: about 35 EUR.

The class ends on June 18th it is a weekly class with a block module at the end.

==Kursbeschreibung==
'''Autonom — Kollaboration. Audio-Interaktion auf eingebetteten Systemen'''

Von der Ubiquität der Smartphones über das Internet-der-Dinge zum Eurorack-Synthesizer: Linux auf Minicomputen spielt eine immer wichtigere Rolle und ist sowohl im Alltag als auch bei Spezialinteressen präsent.
Im Kurs "Autonom - Collaboration" gestalten wir konzeptuelle und angewandte Interaktionen mit Mikrofon und Lautsprecher. Die Einheiten basierend auf einem RaspberryPi können so untereinander als auch mit sich selbst oder einem Nutzer interagieren und communizieren.
So sammeln wir Erfahrungen und Kenntnisse auf den Gebieten der Elektronik, mit Linux, Pure Data und Konzepten der Klangsynthese, Interaktion sowie Maschinellem Lernen und Agentensystemen.

Ein RaspberryPi wird zur Verfügung gestellt, wir bauen dazu ein universelles USB Audiointerface mit Vorverstärker für Kontaktmikrofone, Kosten: ca 35 EUR.

Kurs geht bis zum 18.6. als wöchentlicher Termin, in der letzten Woche gibt es ein Blockmodul.

[[Image:piezopreamp.jpg|750px]]

==Attendance and grading==
Strict attendance rule: no more then 3 missed classes accepted. 3 times late counts like one missed class. Late is >15 min after class begun. Presentation of result at the last day of class. Delivery of detailed project documentation (paper, artwork, video, wiki-entry etc.) until the end of the semester. Evaluation: Presentation 40%, documentation 60%
Deadline for Documentation : October 1st.

==Syllabus==

# 04-08
# 04-15
# 04-22 Easter Monday -- no class
# 04-29
# 05-06
# 05-13 -- no class!
# 05-20
# 05-27
# 06-03
# 06-10 NO CLASS
# 06-17
# BLOCK: 06-21+22 (Friday + Saturday) 10-17h
# 06-24 Final Presentation

== Documentation ==

* [[/Joel/]]
* [[/Ludwig/]]
* [[/Luca/]]
* [[/Jad/]]
* [[/Thomas/]]
* [[/Felix/]]
* [[/Tan/]]
* [[/Doreen/]]
* [[/Hiyeon/]]

==Links==
* [http://listserv.uni-weimar.de/mailman/listinfo/autonomous-collaborative Mailinglist for class]
* [[Automation/RaspberryPi]] Some information on this page may apply on how to optimize the RaspberryPi performance

===Audio focussed operating systems for the RaspberryPi===
* [https://blokas.io/patchbox-os PatchboxOS] alternatives:
** [https://ccrma.stanford.edu/~eberdahl/Satellite Satellite CCRMA]
** [https://os.zynthian.org ZynthianOS]
* [https://www.balena.io/etcher Etcher] make SD card

===setup and control patchbox===
* [[/patchbox setup/]]
** [https://www.cyberciti.biz/faq/apple-osx-mountain-lion-mavericks-install-xquartz-server OSX users need to install XQuartz]

==References==

{{Template:PdBooks}}

[[Category:Max Neupert]] [[Category:Fachmodul]] [[Category:SS19]][[Category:RaspberryPi]] [[Category:Pure Data]]

GMU:Autonomous-Collaborative

2019-05-04T15:39:56Z

Soci8217: /* Syllabus */

''Lecturer:'' [[GMU:Max Neupert|Max Neupert]] 
''Credits:'' 6 [[ECTS]], 4 [[SWS]] 
''Date:'' Weekly: 08.04.-17.06. Mondays, 09:15-12:30, and extra block: 07.+08.06. 10:00-16:45 
''Venue:'' [[Marienstraße 7b]], [[Marienstraße 7b/204|Raum 204]] 
''First meeting:'' April 8th 09:15

==Description==
'''Autonomous — Collaborative. Auditory interaction on embedded systems'''

From the ubiquity of smart phones, the internet of things to Eurorack synthesizers: Linux running on miniature computers is playing an ever extending role and is present in every day life as well as in obscure special interest scenes.
In the class "Autonomous - Collaborative" we design conceptual and applied interactions with microphones and speakers. The units based on a RaspberryPi can interact and communicate with itself, with other units or a human user.
While working on our project we gather experience and knowledge in the fields of electronics, Linux, Pure Data and concepts of sound synthesis, interaction as well as machine learning and software agents.

A RaspberryPi will be lent to you for the class. In addition we will build an universal USB audio interface with preamp for contact microphones. Costs: about 35 EUR.

The class ends on June 18th it is a weekly class with a block module at the end.

==Kursbeschreibung==
'''Autonom — Kollaboration. Audio-Interaktion auf eingebetteten Systemen'''

Von der Ubiquität der Smartphones über das Internet-der-Dinge zum Eurorack-Synthesizer: Linux auf Minicomputen spielt eine immer wichtigere Rolle und ist sowohl im Alltag als auch bei Spezialinteressen präsent.
Im Kurs "Autonom - Collaboration" gestalten wir konzeptuelle und angewandte Interaktionen mit Mikrofon und Lautsprecher. Die Einheiten basierend auf einem RaspberryPi können so untereinander als auch mit sich selbst oder einem Nutzer interagieren und communizieren.
So sammeln wir Erfahrungen und Kenntnisse auf den Gebieten der Elektronik, mit Linux, Pure Data und Konzepten der Klangsynthese, Interaktion sowie Maschinellem Lernen und Agentensystemen.

Ein RaspberryPi wird zur Verfügung gestellt, wir bauen dazu ein universelles USB Audiointerface mit Vorverstärker für Kontaktmikrofone, Kosten: ca 35 EUR.

Kurs geht bis zum 18.6. als wöchentlicher Termin, in der letzten Woche gibt es ein Blockmodul.

[[Image:piezopreamp.jpg|750px]]

==Attendance and grading==
Strict attendance rule: no more then 3 missed classes accepted. 3 times late counts like one missed class. Late is >15 min after class begun. Presentation of result at the last day of class. Delivery of detailed project documentation (paper, artwork, video, wiki-entry etc.) until the end of the semester. Evaluation: Presentation 30%, documentation 70%

==Syllabus==

# 04-08
# 04-15
# 04-22 Easter Monday -- no class
# 04-29
# 05-06
# 05-13
# 05-20
# 05-27
# 06-03
# BLOCK: 06-07+06-08 (Friday + Saturday)
# 06-10 NO CLASS
# 06-17 Final Presentation

===Solder time 3===
# 05.04 10:00 Ludwig
# 05-04 15:00 Thomas
# 05-04 16:00 Doreen
# 05-05 10:00 Hiyeon

==Links==
* [http://listserv.uni-weimar.de/mailman/listinfo/autonomous-collaborative Mailinglist for class]
* [[Automation/RaspberryPi]] Some information on this page may apply on how to optimize the RaspberryPi performance

===Audio focussed operating systems for the RaspberryPi===
* [https://blokas.io/patchbox-os PatchboxOS] alternatives:
** [https://ccrma.stanford.edu/~eberdahl/Satellite Satellite CCRMA]
** [https://os.zynthian.org ZynthianOS]
* [https://www.balena.io/etcher Etcher] make SD card

===Control via ssh===
* [https://www.cyberciti.biz/faq/apple-osx-mountain-lion-mavericks-install-xquartz-server OSX users need to install XQuartz]

==References==

{{Template:PdBooks}}

[[Category:Max Neupert]] [[Category:Fachmodul]] [[Category:SS19]][[Category:RaspberryPi]] [[Category:Pure Data]]

GMU:Autonomous-Collaborative

2019-04-28T13:55:48Z

Soci8217: /* Solder time 2 */

''Lecturer:'' [[GMU:Max Neupert|Max Neupert]] 
''Credits:'' 6 [[ECTS]], 4 [[SWS]] 
''Date:'' Weekly: 08.04.-17.06. Mondays, 09:15-12:30, and extra block: 07.+08.06. 10:00-16:45 
''Venue:'' [[Marienstraße 7b]], [[Marienstraße 7b/204|Raum 204]] 
''First meeting:'' April 8th 09:15

==Description==
'''Autonomous — Collaborative. Auditory interaction on embedded systems'''

From the ubiquity of smart phones, the internet of things to Eurorack synthesizers: Linux running on miniature computers is playing an ever extending role and is present in every day life as well as in obscure special interest scenes.
In the class "Autonomous - Collaborative" we design conceptual and applied interactions with microphones and speakers. The units based on a RaspberryPi can interact and communicate with itself, with other units or a human user.
While working on our project we gather experience and knowledge in the fields of electronics, Linux, Pure Data and concepts of sound synthesis, interaction as well as machine learning and software agents.

A RaspberryPi will be lent to you for the class. In addition we will build an universal USB audio interface with preamp for contact microphones. Costs: about 35 EUR.

The class ends on June 18th it is a weekly class with a block module at the end.

==Kursbeschreibung==
'''Autonom — Kollaboration. Audio-Interaktion auf eingebetteten Systemen'''

Von der Ubiquität der Smartphones über das Internet-der-Dinge zum Eurorack-Synthesizer: Linux auf Minicomputen spielt eine immer wichtigere Rolle und ist sowohl im Alltag als auch bei Spezialinteressen präsent.
Im Kurs "Autonom - Collaboration" gestalten wir konzeptuelle und angewandte Interaktionen mit Mikrofon und Lautsprecher. Die Einheiten basierend auf einem RaspberryPi können so untereinander als auch mit sich selbst oder einem Nutzer interagieren und communizieren.
So sammeln wir Erfahrungen und Kenntnisse auf den Gebieten der Elektronik, mit Linux, Pure Data und Konzepten der Klangsynthese, Interaktion sowie Maschinellem Lernen und Agentensystemen.

Ein RaspberryPi wird zur Verfügung gestellt, wir bauen dazu ein universelles USB Audiointerface mit Vorverstärker für Kontaktmikrofone, Kosten: ca 35 EUR.

Kurs geht bis zum 18.6. als wöchentlicher Termin, in der letzten Woche gibt es ein Blockmodul.

[[Image:piezopreamp.jpg|750px]]

==Attendance and grading==
Strict attendance rule: no more then 3 missed classes accepted. 3 times late counts like one missed class. Late is >15 min after class begun. Presentation of result at the last day of class. Delivery of detailed project documentation (paper, artwork, video, wiki-entry etc.) until the end of the semester. Evaluation: Presentation 30%, documentation 70%

==Syllabus==

# 04-08
# 04-15
# 04-22 Easter Monday -- no class
# 04-29
# 05-06
# 05-13
# 05-20
# 05-27
# 06-03
# BLOCK: 06-07+06-08 (Friday + Saturday)
# 06-10 NO CLASS
# 06-17 Final Presentation

===Solder time 2===
# 04-29 13:00
# 04-29 15:00 Felix Hiyeon
# 04-30 13:00 Tan
# 04-30 15:00
# 05-01 10:00 Ludwig
# 05-01 15:00 Joel
# 05-01 18:00
# 05-02 10:00
# 05-02 15:00
# 05-02 18:00

==Links==
* [http://listserv.uni-weimar.de/mailman/listinfo/autonomous-collaborative Mailinglist for class]
* [[Automation/RaspberryPi]] Some information on this page may apply on how to optimize the RaspberryPi performance

===Audio focussed operating systems for the RaspberryPi===
* [https://blokas.io/patchbox-os PatchboxOS] alternatives:
** [https://ccrma.stanford.edu/~eberdahl/Satellite Satellite CCRMA]
** [https://os.zynthian.org ZynthianOS]
* [https://www.balena.io/etcher Etcher] make SD card

===Control via ssh===
* [https://www.cyberciti.biz/faq/apple-osx-mountain-lion-mavericks-install-xquartz-server OSX users need to install XQuartz]

==References==

{{Template:PdBooks}}

[[Category:Max Neupert]] [[Category:Fachmodul]] [[Category:SS19]][[Category:RaspberryPi]] [[Category:Pure Data]]