Issue With Chicken Systems Translator 6

[chickeneps]

The list of issues I posted above had all been confirmed to be working features. But instead there are endless excuses [asking] to be their beta user.

All we asked of you was to provide an example file or two that replicated your issues, and you refused.

So, we offered to do a remote session with you, and you also refused.

The files we have in-house worked, so we are at a standstill. It's very easy and quick to supply example files, it's hardly the equivalent of "beta tester" requirements.

[padillac]

Has Sampler Tools been released as a single unified interface yet? Or is it still a bundle of the three main products?

chickeneps can you please provide information about this?

[chickeneps]

The integrated interface was released early last year; see www.chickensys.com/samplertools

[Hink]

thank you chickeneps for your replies

JiveBurner, it seems you have jumped the gun here and should work with their support for a solution before posting a warning like this. I am a mod here, I am going to give you a bit to change the title of your thread to something more along the lines of "issues with" instead of a warning...if you dont I will

[padillac]

The integrated interface was released early last year; see www.chickensys.com/samplertools

Thank you, I must have missed the announcement.

[JamminFool]

If Translator crashes, there can be many reasons the user may not be aware of - corrupted files, system problems, CD-ROM access. Those aren't "bugs" with Translator, it's the natural way of things.

Sorry, I have never used your program but I have to laugh. Any good coder would recognize that an input that crashes their system is exactly a bug.

A well-written program would test for input validity and issue a meaningful error message if that test fails.

just sayin'.

[chickeneps]

Any good coder would recognize that an input that crashes their system is exactly a bug. A well-written program would test for input validity and issue a meaningful error message if that test fails.

This is true in theory - and I recognize it just as you - but it doesn't always apply in the day-to-day world.

First, in the case of mechanical errors (primarily CD, but audio and sound and other) it may not be Translator that is actually crashing, but the OS. Most modern OS's allow reading of disks low-level but they certainly resist it, and this is one of the caveats with the "unnatural" things Translator has to do.

Secondly, since all the formats (over 70 at this point) are reverse-engineered, what is "valid input" isn't exactly clear on many occasions. Otherwise, the opposite problem of "false positives" would be just a great a problem. We have over 25 years of massive research of file formats that were designed over a 35 years period, much of it designed on systems predating even Windows or Macintosh. With that amount of input, explicitly checking that amount of input would cripple the program to a certain degree and be prohibitively redundant.

Regardless, Translator DOES have multitudes of strategic and specific validity checks already and rarely crashes, with the frequency matching the typical professional software program. I think you misunderstood my statement as "excusing crashing" or admitting "crashing is an issue" but I was simply addressing that the computer may be a more volatile environment, especially dealing with older tech, older equipment, older media, than the poster was thinking of.

Lastly, if there is any crash that the user can't figure out, we are here every day happy to help if there is any issue - which there isn't usually anyway. But when there is, we help.

[JamminFool]

I think you misunderstood my statement as "excusing crashing" or admitting "crashing is an issue" but I was simply addressing that the computer may be a more volatile environment, especially dealing with older tech, older equipment, older media, than the poster was thinking of.

Fair enough.

[Jace-BeOS]

Any good coder would recognize that an input that crashes their system is exactly a bug. A well-written program would test for input validity and issue a meaningful error message if that test fails.

This is true in theory - and I recognize it just as you - but it doesn't always apply in the day-to-day world.

First, in the case of mechanical errors (primarily CD, but audio and sound and other) it may not be Translator that is actually crashing, but the OS. Most modern OS's allow reading of disks low-level but they certainly resist it, and this is one of the caveats with the "unnatural" things Translator has to do.

Secondly, since all the formats (over 70 at this point) are reverse-engineered, what is "valid input" isn't exactly clear on many occasions. Otherwise, the opposite problem of "false positives" would be just a great a problem. We have over 25 years of massive research of file formats that were designed over a 35 years period, much of it designed on systems predating even Windows or Macintosh. With that amount of input, explicitly checking that amount of input would cripple the program to a certain degree and be prohibitively redundant.

Regardless, Translator DOES have multitudes of strategic and specific validity checks already and rarely crashes, with the frequency matching the typical professional software program. I think you misunderstood my statement as "excusing crashing" or admitting "crashing is an issue" but I was simply addressing that the computer may be a more volatile environment, especially dealing with older tech, older equipment, older media, than the poster was thinking of.

Lastly, if there is any crash that the user can't figure out, we are here every day happy to help if there is any issue - which there isn't usually anyway. But when there is, we help.

Interesting response. You’re saying that truly universally effective error handling of the reading of reverse-engineered file formats would result in blocking unknown/known desired functionality?

[Freaqpeak]

Fix your program first. Then offer it to others. In that order...

Fix your attitude first.

You clearly don't want any help, so why even bother posting?

[chickeneps]

Interesting response. You’re saying that truly universally effective error handling of the reading of reverse-engineered file formats would result in blocking unknown/known desired functionality?

Well, if it was "universally-effective", it wouldn't block anything. Of course, it would take years to write a "universally-effective" system, if it were even possible. The point was that since the formats are "guessed" and not only that there often are different versions of one format and even "beta-creations", if one wanted to read them "perfectly", the convertor would reject out-of-hand more-than-an-acceptable amount of files that could be read properly given the chance.

This assumes also that such a project would be profitable enough to warrant 10+ programmers that would create this "universally-effective" system. Not in the MI industry.

But this is all theory - Translator and other Chicken Systems product run robustly using the error-handling system they have (likely matching what you suggest), and rarely block any functionality.

[Jace-BeOS]

Interesting response. You’re saying that truly universally effective error handling of the reading of reverse-engineered file formats would result in blocking unknown/known desired functionality?

Well, if it was "universally-effective", it wouldn't block anything. Of course, it would take years to write a "universally-effective" system, if it were even possible. The point was that since the formats are "guessed" and not only that there often are different versions of one format and even "beta-creations", if one wanted to read them "perfectly", the convertor would reject out-of-hand more-than-an-acceptable amount of files that could be read properly given the chance.

This assumes also that such a project would be profitable enough to warrant 10+ programmers that would create this "universally-effective" system. Not in the MI industry.

But this is all theory - Translator and other Chicken Systems product run robustly using the error-handling system they have (likely matching what you suggest), and rarely block any functionality.

Maybe my inquiry makes more sense with this wording: When loading data into a segment of memory, if you rejected illegal data, per one format, you’d be rejecting valid data for a slight variation of the same file format?

[chickeneps]

I still can't quite understand your question (dummy me perhaps). The point I was making earlier is that since we aren't the authors of the formats, it's a bit fuzzy at times what is legal data or not. So in your question, it would depend on what was judged "illegal" about the first set of data. Is that a better answer? Sorry if I'm misunderstanding you.

[AnalogGuy1]

FWIW, I've also purchased and used Chicken Systems Translator. As with others, I found the user interface to be...unusual...and it took quite a bit of time to figure out how to extract the data I need to make the Kontakt patch I wanted. I don't recall it crashing ever, but it wasn't easy to use. However, it did work, and I have the patch I wanted; more than a fair trade for the cost of the software. Not saying that it will work for everyone, but I'm countering the claim made that the company and product is a scam - it worked for me.

[SampleScience]

I've been using Translator for a few years now. I had problems but their support was always friendly and at the end of the day I was able to do the work I wanted it to do.

The thing is, the tasks that the software perform are very complex and with that level of complexity, I don't expect it to be perfect anymore.

It comes with Autosampler, which is great and bug-free.