By way of clarification, I was angling for a job at a local small-AM cluster that was described as "board op with strong IT background"; when I asked the hiring engineer for clarification on the phone; "strong IT background" sort of evaporated. I'm taking the interview, but...
----- Original Message ----- > From: "James L. Stewart" <[email protected]> > Although I agree jocks shouldn't normally be consulted on the choice of > automation systems, I think they do need to be consulted (or at least > observed) about what they are trying to do, and how they are doing it to > produce the product they are producing. The observer (you) then need to > think outside-of-the-box a little and consider how all this might be > done better. Indeed. Everyone needs to be pulling their ropes in the same direction... > Compared to Simian, I find how many functions are broken out into > separate programs in Rivendell leaves the on air part (rdairplay) to > have a nice clean interface that leads to less on-air mistakes and > problems with staff tampering. Well, that can cut both ways. A buddy of mine ops there already, and while I was visiting him last week, he had to make some manual changes to the air log to make a prerecorded show and it's local breaks time out correctly. See more later. > The built in "music scheduler", though > primitive, might avoid needing to purchase a 3rd party one (are they > using one on Simian?). Newstalker; other station is sportstalk; I'm assuming their logs are hand built, though Simian's manual didn't make that sound easy; I don't see that there need to be as many degrees of freedom in the object tree as Simian provides. But then, I've never had to do it for-real. > Other programs like "rdcatch" simply don't exist > in Simain (last I checked, although you can schedule batch files from > the main log to do things, but that is a little scary). I used to have > "database" ("Soundhound") problems with Simian too, but things might be > better debugged by now. Oh, and I've had to get viruses off of Simian > systems before, of course NOT Rivendell ones. Simian systems do have > things like "rdpanel" and "rdcartslots" and a CD ripper, but typically > at an added cost. Finally with Rivendell, you never have to worry about > your software getting "unregistered" for various reasons like you do > with Simain. Absolutely; always a big selling point. > Related to this, I might ask the question of what "problem" are you > trying to solve that switching from Simian to Rivendell is meant to > fix? I've personally seen many automation systems (including BSI > Simian) work just fine for people. So if you can identify some things > where Simian simply can't do that Rivendell can, in areas that matter to > the operation of the station, then there would be your selling point. > It seems to me that they may not be using Simian to fullest extent > anyway and perhaps it would work just fine if it was deployed better? That's entirely possible. The specific thing I saw that irked me was that Simian wasn't displaying scheduled end times for clips it knew the start and duration for, requiring the op to calculate in his head. Often. I hate doing wallclock math; that's what frickin' computers are for. I gather from the manual that it *knows* how to do that math, so perhaps that column's hidden and no one realizes it. My background is systems analysis, so figuring out problems and solutions is in my wheelhouse; I wasn't going to try to sell Riv until I knew it was a good answer. > As I've been in management/technical positions over many automation > system deployments, I'll offer my insight on comparing them to > Rivendell. Most of the current bread of systems out there I've seen > seem to work just fine (in many cases, "very well") when properly > deployed. I feel Rivendell compares to most of these at least > feature-wise. It also at least compares to some in terms of system > stability. This is unfortunate as I'd like to say that it is superior > to others (after all it runs on Linux), but it is not. Granted I use > Rivendell on Debian (from Tryphon binaries, usually), so my deployment > is not an officially supported Paravel system. Also I've done a lot of > unusual things to and with our deployment that might be a contributing > factor in some cases. In any case I don't consider Rivendell to be "bug > free" or even as "bug free" as many (but not all) of the other systems > out there. Just kind of typical, or a slightly below. That's about the view I'd gathered from watching the mailing list. > Next it comes down to "support". Granted this community can be very > helpful at times, but it falls short of some of the "top notch" support > I've seen some of the other companies provide to their customers > (granted: at a price! $$$). It is not uncommon for me to see them > "remote in" to their customers systems on a 24-hour basis, then diagnose > and fix things with little end-user involvement. If you choose to use > the Appliance CD (or a turnkey Paravel system), you can at least be > eligible to purchase Paravel support. I do not know how this support > compares to others that are similarly priced. Indeed. That would, of course, have been an item I'd have looked at; I hate going barefoot. > The reason for the above paragraph is that this should be a major > concern to an organization wanting to migrate to Rivendell. With my > Rivendell deployment, we were originally tied in with ownership of the > station, and thus "I wasn't going anywhere", so it was deemed safe for > me to be the support person for our custom installation. We've since > sold our interest in the station (we might be good at building them, but > not so good at running them, especially when they are out of town!), so > now the new owner has found himself more or less "married" to me which > is beginning to worry him because he considers my rates out of his > budget. I'm not in any way trying to rip him off, but the point is, one > needs to worry about who is going to offer continuing support on the > system, which ever system is chosen. All the more reason to go with a > Paravel supported system just in case you have to buy some Paravel > support someday. In my case I couldn't get the Appliance to easily do > some of the things I'm doing with our system, and even if I had, it > might have disqualified it for support anyway. That said, I see the > possibility of the current owner of my Rivendell deployment considering > either redeplolying on the Appliance, or worse yet, migrating to > something like Simian or iMediatouch (or some other "lower cost" system) > if he is serious that he thinks I am too expensive for him (I'm not > really, he just needs to budget a few dollars for "engineering" which > he isn't at all right now). Not uncommon. And yes, better is often the enemy of "Everyone knows this", though that's probably less helpful in radio automation, there are enough systems that *lots* of them aren't First tier. For the record, while I'm a newbie, I've been around Riv, and kibitzing on the mailing list, for years; back into 0.x at least. > I am not in any way blaming Fred at Paravel for not supporting systems > like mine that are installed on Linux distributions foreign to him. I > also don't blame him for any outstanding bugs in the current Rivendell > system, as bugs exist in all systems. The difference is that many of > the other bigger companies have much larger support staff that can be > more responsive to their paying customers. In fact, as not even being a > Paravel customer, Fred has personally fixed many issues I've found with > Rivendell totally free of charge (Thank you Fred!), but he is under no > obligation to do so, and I totally understand that. He rightly considers them actual bugs that everyone else should get the benefit of fixes too as well, no doubt. > In summary: I'd consider "fixing" issues with the Simian system if you > can (since they already bought it, unless it is an older version that > needs upgrading for more money), It is 2.2.something; 2.3.0 is current. So not too bad. > otherwise the previously recommended > process of building up a "test" system on some old hardware (not even > one of those expensive ASI sound cards unless they have one laying > around from an old broken Simian system) and let them see how life could > be on Rivendell would be a good direction to go. I would also test your > ability to actually deploy a Rivendell system, which is NOT all that > easy as well. Absolutely on all points. An excellent recap, which I wanted to reply to both to assure I wasn't going off half-cocked, and for archive purposes on a couple points. Cheers, -- jra -- Jay R. Ashworth Baylink [email protected] Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ Rivendell-dev mailing list [email protected] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
