Flash question: how to automate creation of multiple .SWFs

I tried asking multiple Flash-specific boards before coming here; I really did. As usual, though, their denizens are far more focused on telling me I don’t really want what I think I want than answering my question. I’ll probably start a Pit rant about that attitude later, but for right now, if I seem a bit miffed, that’s why. On to my question…

I have a template that consists of a small .jpg of a speaker, with code that plays a .wav file on load and on click. That code is as follows:


OnLoad(){
playSound("WAV_1.wav");
}
on (press){
playSound("WAV_1.wav");
}

I also have about 3000 .wav files. What I am trying to do is find a way (application, scripting, or anything really) to automate putting each of these .wavs into the above template, and exporting a .SWF of each, with the same filename as the .wav file. In other words, if I had only two .wav files, “SoundOne.wav” and “SoundTwo.wav”, I want something that will automatically create “SoundOne.swf” and “SoundTwo.swf”, with the corresponding .wav file imported into the template code.

[Me Being Angry At Other Boards]I assure you, I really do need 3,000 files. I do. One file that can play every sound dynamically via user actions, passed variables, PHP, ancient incantations, or anything else, will not work. I will not explain why, because it’s a long story, wholly irrelevant to my question, and I don’t care to argue the point.[/MBAAOB]

The Flash dev application I have is SWiSHmax, but if there’s a freeware or <$100 application out there that can do this for me, I’ll be all over it. Anyone have any ideas? All advice (except that which advises me not to create 3,000 separate files, because I frigging need 3,000 separate files) is greatly appreciated. :slight_smile:

I don’t have an answer but have you looked in to getting the 30-day free trial of Flash from the Adobe site? It’s a full version.

No idea if you can use it to automate (I know you can automate stuff in Photoshop…but that’s not really relevant), but it’s out there for your perusal.

Well, the closest thing I’ve gotten to a useful reply on the other boards is that I can use something called “JSFL” to do this. Looking into it, it appears to be a scripting language usable with Adobe’s Flash dev suites; I imagine CS3 would qualify, so your suggestion is a step in the right direction.

Problem is, I don’t know anything about Flash development. I am, in various capacities and skill levels, a VB/C++/SCORM 1.2 developer, so I understand the basics of programming and scripting, but I have no idea where to start with an oddball proprietary meta-script in an environment I’ve never used.

Anyone here fluent in this stuff, by any chance?

swfc will do what you want; it’s a free, open-source command-line tool for compiling text-file scripts into SWF files (part of swftools; binary and source downloads available from that link). Here’s an example script for embedding a WAV file, which I think is almost what you want to do. You’d just write a script to autogenerate 3000 of these files (each with the appropriate SWF and WAV filenames) and then compile each one.

I am curious to know why the single-player-with-WAV-parameter won’t work for you, though. I don’t see what this does that that doesn’t.

  1. These sound-SWFs are going to be used in different places for different purposes, and in the application they’re being used in, using a SWF large enough to amalgamate all of them is precisely the cause of the problem I’m trying to fix by splitting them up. This has been tested and proven multiple times, with every audio compression format under the sun; splitting them up is the only way to solve this problem. And no, I can’t load the player without loading all the files at once, because…

  2. The aforementioned application is proprietary, and given that “Sound1426.swf” is accessed with the press of a predetermined (not by me) button from a predetermined (also not by me) page using prewritten (yet again, not by me) linking protocol that I have no way to alter, I have no way whatsoever to pass a variable through to this hypothetical player that would tell it which file to load and play. I can aim it at a particular SWF, but that is the extent of my control without making alterations to the application, which I cannot legally do.

There are other reasons why it wouldn’t work in various specific situations, but those two alone dictate that I cannot use a single player.

I’ll look into your suggestion, but at first glance, figuring out what I’m doing with that wouldn’t be significantly faster than just loading my template into SWiSHmax and clicking “Import Audio” and “Export SWF” three thousand times, which is what I’m trying to avoid doing. I was rather hoping for something similar to this, which would be absolutely perfect, except that I can’t customize the button to be my speaker icon (which it needs to be, for equally tedious reasons).

Did you try compiling the example I linked? I ask because it seems to be exactly what you want apart from the two extra buttons and the fact that the speaker button is not the one you want, both of which are easy to change without knowing anything much about the scripting language. If you describe more precisely what needs to be changed from the example, I might be able to help.


Feel free to ignore this, but I’m still curious…

I agree that putting all the sounds in one file is ugly.

So you can change the link target from “Sound1.swf” to “Sound1426.swf”, but not to “/player.php?soundfile=1426” or some dynamically-generated page? And these link requests give no Referer information? … Bizarre. Still, if you have some control over the HTTP server that holds these SWFs, you could make a HTTP “GET …/Sound1426.swf” redirect to (e.g.) “GET /player.php?soundfile=1426” or some other dynamic content generator.

Heh. As you guessed, I hadn’t actually tried compiling the code before commenting on it; you’re right, it was easy to reconfigure to my parameters once I took a breather and looked at it with fresh eyes. Problem solved, thanks.

“Bizarre” is the right word, yes. The thing about what I’m using these SWFs for is that it isn’t web development per se; it’s development of educational material in a Learning Content Management System (LCMS) using Online SCORM 1.2, which is essentially HTML as reconfigured by sadists for instructional design purposes.

If we could count on each of our clients to use the same LMS (LMS is to SCORM as web browser is to HTML), I could jigger the linking parameters in our content a bit more. Unfortunately, not only does everyone under the sun use a different LMS – all of which claim to be fully SCORM-compliant but some of which lie – but some of our clients import our content into something different altogether (SharePoint or some godforsaken internal e-learning app). SCORM objects export as zip archives containing text, media, and code files, and XML mapping files to instruct the LMS how to put everything together. Some of these applications extract this stuff and “organize” it (read: move it around a lot) on import, as well as allowing the client to customize the aesthetics of the learning content on the back end.

That means that instead of linking using HTML protocols, which SCORM allows but which does not play nice if the client reconfigures the layout, order or location of our learning objects, I must link to a particular object using its object ID, which is traceable by SCORM no matter how the content ends up being organized on the client’s system. With this sort of “link”, you can’t pass variables, or do much of anything else for that matter; you just create a static button that pops up your preselected media object. So, no PHP, and no dynamic flash players that rely on information from a link to make decisions.

This explanation is admittedly an oversimplification (though hopefully semi-comprehensible), but the long version of this stuff is pretty boring even to fellow dev geeks. If I haven’t confused and/or bored you to tears yet, feel free to drop me an email and I’ll gladly talk your ear off. Thanks again for the help! :slight_smile:

OK, now I understand the problem. Glad you got it to work.