Spring 2018
I succeed to translate my sketch to p5js. I put image file and sound track.
Most hard thing was putting sound track. ‘noloop’ makes the sound goes well.
I hope I will make interaction with specific part of picture for the next project.
For example, If you click on the cherry blossom tree, you will make the leaves of cherry blossoms fall off, or you can click the track to make a sound effect, etc.
In his project “Malwarez”, Romanian Visual Artist, Designer and Programmer Alex Dragulescu creates a visual Encyclopedia of computer threats that include viruses, spyware, malware and other forms of menacing code.
Dragulescu tracks elements of each entities’ disassembled code “API calls, memory addresses and subroutines”; after which the variables of frequency, density and grouping are mapped using an algorithm that generates a virtual 3D likeness for each different “species” of code. These “Artificial Organisms” thus become constructed from the components of the code they represent; creating a visual reflection that uses both the artist’s interpretation, and the direct source of inspiration. Additionally, Dragulescu directly cites the sources of each individual code/organism; giving a date and online address to the original malicious code that was broken down and analysed to fuel the 3D visualisation.
I found this project particularly interesting because it looks towards computing for the subject matter as well as the medium. As someone new to the world of coding and computation, I find the mysticism as something that sands as a barrier between those interested and those involved. However, in taking that and using the medium to communicate concepts in a creative way, Dragulescu demystifies the medium while also dismaying the idea that these concepts are in any way dry and uninteresting. The 3D models generate a wealth of questions and intrigue into what elements differentiate each “organism” from each other and made each of the resulting pieces so visually captivating and intriguing; with depth and detail that brings to life concepts that exist primarily and only in coding languages only known to those familiar with computing.
Since i was a child, I used to watch night sky and constallation. It is one of my hobby. When i was in high school, I lived in upstate New York. The nights of upstate New York were always filled with bright stars. As a enthusiastic star-gazer, this was another blessing from heaven. For my presentation, I initially attempted to associate my fervor for star-gazing with coding; yet, when I dug more deeper into these fields, I rather found out a more interesting instrument: the telescope-controller.
Arduino is just an easy to program hardware and you can attach motor to it and control it with codes.
Arduino reads the Constellation map
And gathers latitude longitude, and time information and accordingly turns the motor to adjust the telescope and have it follow Constellation near by.
Top is the board for Arduino where you can attach motors and other sensors. Bottom is where you can program to receive input and create output through programming.
I felt like reading chapters 10 and 11 validated some of the lessons that I began to learn over the course of working on the midterm. At the start of the project, my code was deeply disorganized. I was thinking of the whole project as one still image and not thinking more seriously about how to make the individual components work best. That said, as I continued working, I began to see the importance of organizing my code, which is underlined in chapter 10. I created way too many classes as a means of keeping my code clean, which is not quite what the book meant, but is along the same lines. If I had read the chapters before my project, I would’ve thought more about the individual components of the matchmaker, and I would have thought to do things like create a loop for lines instead of drawing 40 individual lines.
Reading these chapters, I began to think about how I might want to practice planning out my code more systematically. Until the mid-term sketch, I would just throw in a bunch of ideas into a long set of main code and organize them as I am revising the code. This method worked for me because I never start my code with a clear idea of what I want to create, probably because I am still getting myself used to Processing. However, I think I should start getting in the habit of beginning object-oriented sketches with multiple classes rather than a single tab of codes since that will help me in the future when I write more complicated code.
The debugging chapter was interesting, especially the use of println(). Separating the code into smaller sections, commenting out, and testing with a new sketch are steps that I naturally followed whenever I was faced with a problem. Indicating the location, color, array and etc. is something that I should keep in mind when some objects do not appear on the sketch. Previously, when this happened, I would just copy the code for the specific object on to a new sketch and play around with it until it works.
After reading both chapters, I realized for my past two assignments instead of looking at the assignments as a whole and if I started to break things down it would have been much easier. Instead of trying to focus on all aspects at once working on one aspect at a time is something I need to work on. This would have prevented me getting stuck so many times. I liked chapter 11 alot it helps to know that every coder gets bugs and its not just me.
After reading chapters 10 and 11 I have realized how complicated I have made my coding thus far. Whenever I have an idea, I’ve never really organized it in any way. Breaking my idea into parts is a good way to simplify my idea so that it seems less overwhelming. Going from idea to parts would probably be the most difficult part for me, just because I wouldn’t know how to separate my big idea into little parts. I guess it will take some practice. Overall, I think creating some sort of algorithms with parts will make my code more organized and less overwhelming. It will also help in the debugging process.
In chapter 11 I loved reading about how everyone who does coding always has some sort of problem with bugs in their code. I honestly thought it was just me. It’s super frustrating when my code doesn’t work as intended, and then how I have to search my (unorganized) code for a bug. I guess I should probably make my code simpler and more organized. Also making comments throughout my code could be helpful as well. The troubleshooting process that they talked about in chapter 11 was really helpful.
While I do feel proud of how far I’ve come in my understanding of computation and coding as a whole, I’m exited to focus more in my free time and use this increased confidence to expand my understanding of how to apply coding to my own artistic interests.
Reading chapters 10+11 gave interesting insight into a more structured approach to coding than I had used in the past. It’s fascinating to see how computation simultaneously agrees and conflicts with my natural and learned ways of thinking as an artist. I’ve always veered away from a concrete structure at the start of any project due to a fear that it would stifle the possibility of improvisation. However I now feel as though it would be far more beneficial in terms of keeping track of the code and various structures at work. Chapter 11 also yielded a lot of guidance, some of which I’d previously applied by asking a friend of mine for help on my midterm. I find myself debugging projects most of the time, but the puzzle-like nature of computation makes is what makes it a really interesting and engaging exercise for me, even when its frustrating.
These articles were interesting to me. I have about two years of experience with Java and have competed in UIL competitions using Java, and until last semester I was majoring in Computer Science. Technically I still am since I haven’t officially filled out the major change form. Part of me revolts against the order and technicality of OOP techniques, and writing clean code when it comes to art. I can totally see the value in utilizing these techniques and how much easier it can make everything, but it does feel very technical to me. Perhaps this is why I have not used much of my prior knowledge in any of my sketches. Art feels like a different world, but in reality, you need both order and freedom of expression. There is freedom within constraints. The iPhone is beautifully designed and ingeniously programmed. Great products utilize both, and I suppose art is anything that guides us to wonder. Nevertheless, it is a challenge for me to abstract “a brush stroke”, or to create a class for each object I want to use, but I suppose it’s like a painter pre-mixing their paints to be able to use them during the painting process.