Just for a bit of fun, a Pixel Bender powered Mandelbrot set. Not great since the Flash player can’t run Pixel Bender loops. Oh well. We can manage a few iterations by unrolling the loop. However, adding too many causes the thing to slow to a crawl even on the heftiest machine. Click to zoom. Requires Flash player 10.
I was looking into the CCR & DSS Toolkit pages and it looked like I was missing a whole bunch of content by not having Silverlight installed on my machine. Upon downloading and installing the Silverlight 2 plugin, I was pleasantly surprised that I didn’t need to restart Firefox, but simply to refresh the page in order to start viewing Silverlight content. It makes the Flash install process seem a bit cumbersome in comparison. Restarting the browser is old-school, man…
I posted this on StackOverflow.com, but maybe one of out readers knows the answer…
Quite simple really:
var req:URLRequest=new URLRequest();
req.url="http://somesite.com";
var header:URLRequestHeader=new URLRequestHeader("my-bespoke-header","1");
req.requestHeaders.push(header);
req.method=URLRequestMethod.GET;
stream.load(req);
Yet, if I inspect the traffic with WireShark, the my-bespoke-header is not being sent. If I change to URLRequestMethod.POST and append some data to req.data, then the header is sent, but the receiving application requires a GET not a POST.
The documentation mentions a blacklist of headers that will not get sent. my-bespoke-header is not one of these. It’s possibly worth mentioning that the originating request is from a different port on the same domain. Nothing is reported in the policyfile log, so it seems unlikely, but is this something that can be remedied by force loading a crossdomain.xml with a allow-http-request-headers-from despite the fact that this is not a crossdomain issue? Or is it simply an undocumented feature of the Flash Player that it can only send custom headers with a POST request?
We’ve been looking into some inconsistent behaviour across platforms when making socket connections. An application that works fine in Windows and OSX fails for no apparent reason when running on Linux platforms. After running a WireShark network capture, we established that, after correctly fetching a socket policy from port 843 of the remote host, the data sent to the target port was corrupted when using Linux Flash Player.
It turns out that the culprit is the Linux implementation of Socket.writeMultiByte, at least certainly when using the “us-ascii” encoding (it’s late and we can’t be bothered to test other encodings).
So, the line:
socket.writeMultiByte("GET somepath HTTP/1.0 \r\n","us-ascii");
fails completely, with garbage getting written to the socket.
We’ve written a naive (and appropriately named) replacement which works for what we’re doing, but doesn’t handle encodings.
private function writeBetterMultiByte2(msg:String):void
{
for(var i:int=0;i<msg.length;++i)
{
socket.writeByte(msg.charCodeAt(i));
}
}
It appears that we’re not the only ones having trouble with writeMultiByte, but this time it’s with ByteArray.writeMultiByte . Something seems quite broken here.
Over at tunamedia.co.uk, we’ve released a demo of Flash movie playing Shoutcast streams using the new Sound API features available in Flash Player 10. Take a look.
We’ve been doing quite a lot of stuff using the new FileReference API that allows access to local files without server roundtrips. The current official release candidate seems to limit the allowed file size to somewhere in the region of 512k. This thread on the flash player 10 forums summarises the problem nicely. It’s led us on a bit of mission to find a more recent version of the player, which can be found here:
http://opensource.adobe.com/svn/opensource/flex/sdk/branches/3.0.x/in/player/10/
[The contents of this article are now incorrect. We've been using the players in this package and this one for linux now.]
Thankfully, this newer version does not seem to carry this FileReference limitation.
If you look through previous posts on our blog, there are a couple of posts relating to the location of the most recent player. Once again, the most recent version appears in a different location. This rather begs the question as to why new players are being littered around various places on the adobe website with no apparent consistency.
Why aren’t developers being informed of newer releases of the player that can be publicly obtained? Why are they being “hidden” in the various branches of the Flex SVN repository?
Last week, I updated and rebuilt the Flex SDK from Subversion, and was pleasantly surprised to find that new players had been included in the repository. It was followed by disappointment that my pet project, which leans heavily on the new SAMPLE_DATA events in the Sound API stopped working.
It turns out that in player 10,0,0,591, the SAMPLE_DATA event string, which up to this point has been a property of the flash.events.Event class has been moved to now exist upon the flash.events.SampleDataEvent class. I’d always wondered why the Flash Player team had chosen to create a SampleDataEvent class, but to put the string that defines the event on the Event class instead of the SampleDataEvent class. It appears that this inconsistency has now been cleared up.
It does, however, lead to a situation where a software product labelled as Release Candidate is still having significant changes made to it that will break software developed against it. It leaves me with the conundrum of having examples of the new Sound API extensions on our blog that will either work with the latest (but somewhat obscure) version of the player and leave most users with a broken experience, or to develop against the old API in the knowledge that the pieces will eventually break when newer versions of the player are officially rolled out.
I think it’s time to redefine my understanding of the term “Release Candidate”!
I’ve been roadtesting Google Chrome. Maybe it’s just me, but none of the links to posts on Adobe Feeds work. All you get is the mysterious message:
This web page is not available.
The web page at null might be temporarily down or it may have moved permanently to a new web address.
More information on this error
Below is the original error messageError 320 (net::ERR_INVALID_RESPONSE): Unknown error.
This is an example of one of the links. Can any other Chromsters confirm?
[The contents of this article are now incorrect. We've been using the players in this package and this one for linux now.]
The infomation in a previous post about the location of the standalone debug player for Flash Player 10 is now incorrect as Adobe deleted some locations from the Flex subversion repository around the start of the month.
The player 10 debug versions can now be found here:
http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/in/player/10
As far as I can tell (I’ve only checked Windows standalone and Windows plugin, not the activex version), they’re at version 10,0,0,591, released yesterday. The browser plugin installed is a debug version, which will be handy.
I’m really excited by the possibility of using PixelBender filters for audio processing, but at the moment, it seems to be a neglected area of development for the FP10 team, despite the odd mention here and there of its use in operations other than image processing.
I’ve posted several questions to people who might be able to answer, yet no further information has been forthcoming. I’m publishing a digest of these questions below in the hope that somebody might be able to shed a little light on how it is all expected to work…
Issue #1
There has been mention of using the ShaderJob API for non-image related computation. It’s a subject of interest to me as it could be used for processing audio data. However, it seems to be impossible to create PixelBender filters that allow the processing of one dimensional data. I posted a couple of questions on the Adobe forums about this, but have yet to receive a satisfactory answer. Here’s one of the questions that summarises the problem:
The Flash docs say the following:
To process a ByteArray containing a linear array of data (as opposed to image data) set the corresponding ShaderInput instance’s height to 1 and width to the number of 32-bit floating-point values in the ByteArray. In that case, the input in the shader must be defined with the image1 data type.
What must the output be defined as? Float, right? This would mean a simple doNothing filter could be defined as in the attached code below.
<languageVersion: 1.0;>
kernel doNothing
< namespace : "flexiblefactory.co.uk";
vendor : "flexiblefactory.co.uk";
version : 0.1;
description : "do nothing filter"; >
{
input image1 src;
output float dst;
void evaluatePixel()
{
dst = sampleNearest(src, outCoord());
}
}
But PixelBender gives the following error:
ERROR: (line xx): ‘dst’ : cannot have 1 or 2 channel outputs
So, either my assumptions are incorrect, or PixelBender does not support this kind of operation.
Can an Adobe head tell me what’s going wrong here? Am I barking up the wrong tree or are we waiting for a new version of PixelBender that supports 1dimensional data?
Issue #2
The default endian-ness for all audio big endian, but the default endian for the Shader API when using it to operate on ByteArray instances is little endian. The only way to convert the endian of a ByteArray full of floating point numbers is by iterating through each value, and copying to another ByteArray with differring endian. When moving high volumes of data, this conversion limits the usefulness of a Shader to only more complex calculations.
For instance: a simple Shader designed for setting the gain of an audio stream becomes pointless if you first have to iterate the contents of the ByteArray in Actionscript to change the endian, and subsequently convert the output back again for playback. This would negate any performance gains made by using the Shader.
So, all this talk of using the Shader for audio operations comes with a major drawback, right?