Puppies, Flowers, Rainbows and Kittens
Sarcasm and vitriol wrapped in a twee bow.
Frequent contributor to the Pixel Bender forums, Royi Avital, has released a new set of After Effects and Photoshop plug-ins written with Pixel Bender under the name Flixel Plugins. The first three are now available on aescripts.com
Flixel Plugins on aescripts.com
ApexVJ is a really beautiful Flash-based music visualizer that uses Pixel Bender
Simo Santavirta, the creator, wrote an article on his blog about it.
After many happy and productive years working on Pixel Bender and the Adobe Image Foundation, I’ve decided to take on some new challenges. I’m still at Adobe, but I’m now building a new team and launching a brand new product in the Photoshop family. I can’t say too much yet, but I will have news soon. I’ll still be posting about Pixel Bender stuff here (I’m still a very enthusiastic user!), but for the newest news, you should now also watch the official Pixel Bender blog.
I’ve been working on a lot of Pixel Bender experiments and wanted a nice UI to allow zooming in to examine the effected pixels. I decided to use the method of having an overlaid box on a scaled version of the image that corresponds to a zoomed separate display. I looked around and found some nice sample code on FLEX{er} written by Stelian Crisan. I mostly added nice UI to adjust the parameters in his code.
So we started this product cycle with two geographically-dispersed mixed-discipline scrum teams on two week sprints. Specifically, the geographical co-mingling was designed to break up some of the silos that had built up on the team due to the existing functional teams being in different cities. By the third sprint, we’ve now switched back to scrum teams that mimic the original functional and geographic splits and are now on four week cycles. This has made cross-team communication more difficult, but has made everyone a lot happier by keeping the scrum meetings more relevant to everyone on the team. I can definitely see why people like this more, it lets people focus on what they are doing, but I do think we are losing something by not spreading the knowledge of the different parts of the project around the team. Also, not having multiple functional areas represented in the scrum meetings means that some fresh perspectives are lost in any of the technical discussions that come up. Over the next few sprints we’ll try this out and see if this is working. I think this will probably be what we stick with, and we’ll need to address the cross-team communication issues separately.
Switching to four week sprints was mostly to reduce the amount of time spent in the scrum meetings themselves relative to the amount of working time. Between planning poker, retrospectives and sprint planning, a lot of time is lost to the process itself in a two week sprint. For a team used to working on 6 week sprints, fitting stories into 2 week chunks was also difficult. I like the idea of two week sprints, but in practice, it was difficult for a team that is new to scrum. We’ll maybe try 2 week sprints in a future product cycle.
We still haven’t switched to our planned internally created scrum tool which itself makes things difficult. Our backlog is an excel spreadsheet and our tracking is all on Wikis. Hopefully, we’ll be converted over to the tool by the next sprint, which should make life a bit easier on me and the scrum master.
The subject of using Pixel Bender for audio processing on the Flash platform comes up a lot. Audio processing is very processor-intensive and math-heavy, so it would seem natural to leverage Pixel Bender to improve performance of audio within a SWF. At some point, last year, I was talking to Justin Everett-Church about doing a demo for Flash Player 10.1 multi-touch features. A synth seemed like a good idea, and it would let me kill two birds with one stone. So I coded up a synth (with a lame Flex UI) and Justin took that and made it pretty and added multi-touch support. That 2nd part of the demo never worked out the way we meant it too (missed the MAX 2009 keynote by this much). After that, I planned on cleaning up the code and posting it, but I got busy shipping CS5 and well, 7 months later, I finally got around to posting it. Right now it is just the playable demo with the crummy Flex UI.
It is a total processor hog, on purpose. I basically wanted to use it to push the limit of what could be done in the player, so I kept adding more filters and processors to it until the audio started to break up on my Core Duo 2 Mac Book Pro and then stepped back just a little. It turns out that you can actually do a ton of audio processing interactively in the player leveraging Pixel Bender. This was also designed to run as an AIR app, which means that if you really want to play with it, close all your other tabs. Really.
Pixel Bender Synth Experiment
Continue reading “Pixel Bender Synthesizer Experiment”
[disclaimer: I am an Adobe employee and an Adobe and Apple shareholder, my opinions are my own and not those of my employer.]
Like the rest of the software industry, I’ve been pondering what the effect section 3.3.1 of the iPhone 4.0 SDK will have. I had fully been planning to make an iPhone application at some point. I had planned to do the initial version with Flex to prototype, but then also spend time doing a Cocoa version to better learn that SDK for myself. This iPhone 4.0 SDK announcement honestly has me questioning if I do really want to develop for the iPhone. Not just because of a higher-minded sense of indignity at Apple’s lack of openness of their platform, but rather because of that combined with their somewhat arbitrary and opaque app store approval process. Could I spend months of my spare time learning ObjectiveC and working on an iPhone application only to have that time be a complete waste if the App store reviewers decide that they don’t want that app in the store?
Thinking about it this morning, I realized that not only was Apple’s move to lock in developers nothing new, but that I’d already written about it before (in fact, I’ve been blogging about it since almost the day I started doing professional development for the Macintosh): iPhone SDK: The carrot for Cocoa, the stick for Flash, The difference between being an Apple developer and a Microsoft developer, Developers Developers Developers Developers.
Gruber had the motivation right, I think, but I also think he got the ramifications wrong. Since Steve returned to Apple, they have been applying the screws tighter and tighter to their developers, trying to get them to lock in. It was somewhat indirect at first, but the long term implication was clear: “We’ll tell you how to develop for our platform, if you do as we say, then you’ll be fine. If you don’t do it the way we tell you, your life will be a never-ending stream of headaches.” The move to Intel (forcing all developers onto X-Code and a big rewrite of any PPC-assembly) was step one, the move to 64-bit (dropping support for Carbon after promising it) was step two. The iPhone 4.0 SDK is just the most obvious move in this process because it basically spells it out. You no longer have a choice: it is Apple’s way or the highway. The problem is the App store. On the Mac, I control my own distribution. On the iPhone platform, Apple does. That means that they no longer have to negotiate with their developers, they can now finally dictate to them.
As a developer, this makes the iPhone platform a lot less attractive because I also can’t be sure that they won’t change the terms again. Once I’m locked in, I’m locked in. Apple can do whatever they want and I’m forced to rewrite my apps or get forced out. As someone who writes software for a living, this scares the crap outta me.
Here are some other blog posts that I thought were good reading around this:
The iPad isn’t a computer, it’s a distribution channel (O’Reilly Radar)
Five rational arguments against Apple’s 3.3.1 policy (37 Signals blog)
The deck is a nice, loose, taxonomy of different design styles (some of the examples seem to have multiple styles to me), the examples are really good and actually pointed out some cool sites that I hadn’t heard about. Definitely worth a flip through if you have an interest in this stuff.
Well, part of the whole idea is that scrum isn’t a hard-and-fast set of rules right? I had some meetings at another office last week which necessitated moving out our first sprint review and retrospective a couple days. So if one of the guiding principals of scrum (and agile in general) is that the dates don’t change, everything else does, that got blown right out of the gate.
Some new stories came up as part of the sprint wrap-up which means that we’ll need to do a new planning poker session. Also, some other things came up which mean that there is a bit of housekeeping to do before we start the second sprint. We’re now in some uncharted zone between two sprints while the product manager and scrum master do some cleanup while the scrum teams do some off-book work for a couple days. Yeah, not ideal, but we’re trying to get it back on track. This sprint was going to be a throw-away anyway as it involved a lot of transition and getting used to the framework.
The retrospective brought up some really good issues and some innovative suggestions from the team on how to handle them. If the suggestions work out, I’ll post them here eventually.
There are still some folks unclear on what we expect to gain by transitioning to a new development process, but most of the team is embracing it as a good experiment and chance to try something new. For the most part, everyone seems to have an open mind and that definitely makes a huge difference as we all try to figure this out together. It hasn’t been the smoothest transition, but so far so good, I think. We’re definitely not as productive as we were before (so far). However, I think that the discipline provided by the product backlog means that we are actually getting the most important things done first. That makes a huge difference.
That could have gone a lot better.
I had originally prepared the product backlog with stories that were way too large. I think that I was confusing the role of the Scrum Product Owner and the XP Customer a bit. I was worried about “being polluted.” After reviewing the Scrum planning process again, I realized that I really needed to break up the top priority stories. I took the top dozen and broke them up into around 40 smaller stories. Some I left for the team to break up as an exercise. I needed input from the team leads to break up a few of the stories, so I left them as epics. There were a few stories that defied division. These were large design tasks. We have to interface with a couple other teams and get some customer feedback, so we need to have some initial designs to present that are somewhat comprehensive. I knew that this would be difficult to incorporate in an Agile process, but it is a part of our work and I wanted to try and assimilate it. We also had some carry-over work from the previous release and some open-ended consulting that we needed to account for in our estimations. The carry-over work was interrupt-based, basically bugs found by other teams that we would need to turn around quickly. To incorporate this into the planning, I created a story at upmost priority to account for this possible work.
Given the distributed nature of the team, I decided to do the planning poker on-line. I booked some video conference rooms, but also a phone conference. Since physical cards would not work for us, we used Adobe Connect (‘natch) with a polling pod for each person to put in their card choice. I figured that most of the team would hang out in their offices and dial in to the meeting, but everyone came to the conference rooms and that actually worked really well.
I’d budgeted about 2 hours for Planning Poker. I figured that this would give us time to get into the process and go through a few sprints worth of stories. Turns out that my estimating skills on planning poker needs some work itself.
The hard-to-estimate high priority stories derailed us for a long time. Especially the open-ended consulting and bug fixing tasks. The team got stuck on estimating an unknown. It took a lot of time and a lot of frustration, but we finally reached a rough consensus and moved on to the difficult-to-split design tasks. We tried a zillion ways to split them up or come up with better estimates. In the end they got a high estimate and were tabled to the sprint planning meeting. In retrospect, even though these stories were the highest priority, I probably should have started us on the concrete tasks and come back to these later in the session. For a team’s first planning session these were some pretty tough tasks to work through.
Once we got past these tasks, it got a bit better, but it was still difficult. The team got too caught up in the details of each story, unable to make an estimate before digging deep. If there was uncertainty, we got really deep in the weeds. The 2 minute timer didn’t help. The more concrete stories that needed to be broken up took a lot more time than I expected too. Members of the team kept wanting to discuss details on each story. The scrum master and I kept trying to bring us back to the sprit of estimation, but it was a slog. After almost three hours, we had only gotten through a dozen stories, not even enough to get us through our first sprint. I’m going to look for better ways to explain the spirit and intent of Agile estimation to the team. It is difficult to grasp sometimes for detail-oriented folks.
Even though we were short of estimated stories, we went ahead with our first planning meetings anyway. One team was able to take on stories and create tasks and estimates from them. They may be a bit short of work, but they made some progress. The other team had difficulty pulling stories given the paucity of choices.
We learned some useful things today. We separated the teams to do the sprint planning, pulling from the backlog. The teams were in separate video conference rooms. I and the scrum master moved between them. We realized afterwards that we really need to have both teams together to figure out how the stories would be divided and then the teams should have separated to create their tasks and do their estimations. I was also too eager to jump into the poker session itself, Â and I didn’t spend enough time going through the backlog with the team and discussing my priorities. We’ll fix these issues next time.
We’ll do a second planning poker session tomorrow. Before then, I’ll take in the new stories we created in the backlog, make sure that they are prioritized correctly, and try to break up some more of the stories so that we don’t have to spend time doing that in the poker session.
I knew the first planning poker session was going to be a bit rocky as we felt our way through the process, but for me it was brutal. I know that as we gain experience it will get progressively easier and so I’m more worried about the team’s morale right now than I am concerned about the process. We’ll see how it goes.
On one hand, our super short sprints play to our advantage as it lets us try stuff out in a sprint without a huge commitment. On the other hand, it makes breaking stories up into sprint-sized chunks really difficult. It feels a bit like we’ve jumped into the deep end because of this. We’re open to making a lot of changes, but we’re hoping to keep a consistent sprint length through the cycle since modifying the duration of our sprints will make it difficult to establish a rhythm. Again, we’ll see how it goes.
