jdybnis is currently certified at Apprentice level.

Name: Josh Dybnis
Member since: 2000-02-19 00:53:47
Last Login: N/A

FOAF RDF Share This

Notes:

Just another coder.

I can be reached by email, at my yahoo account with the same user name as I have here.

Books I've been reading:

  • Peirce. Types and Programming Languages. (for 6 months)
  • Abiteboul, Hull, Vianu. Foundations of Databases. (for 1 year)
  • Mitchell. Foundations for Programming Languages. (for 5 years)
  • Prospects on my shelves:

  • Lang. Algebra.
  • Pearl. Causality.
  • Recent blog entries by jdybnis

    Syndication: RSS 2.0
    18 Dec 2003 (updated 18 Dec 2003 at 06:43 UTC) »

    It takes a long time to say anything in Old Entish, and we never say anything unless it is worth taking a long time to say

    -Treebeard the Ent, The Lord of the Rings: The Two Towers

    If you s/say/do/g it sums up my philosophy of life pretty well.

    12 Nov 2003 (updated 12 Nov 2003 at 20:56 UTC) »
    A Better Soundcard

    MichaelCrawford:

    I recommend going with an external USB soundcard. I have not seen an internal only soundcard that matches the audio quality of even a cheap external soundcard. Unlike the soundcards I recommend below, professional soundcards are not usually USB devices because the latency going through USB is a problem for them.

    $75 - Soundblaster Extigy - It was one of the first USB soundcards on the market. Get one used on ebay. (has a remote control)

    $125 - Soundblaster Audigy NX - New USB soundcard from Creative. I haven't listened to it yet, but by the specs it should be a bump up in quality from the Extigy. Get one new on ebay or via froogle. (has a remote control too)

    $160 - M-Audio Audiophile USB - Get one new via ebay. (big step up in audio quality, but no remote control)

    $300 to $???? - the best sound will come from using a soundcard with a digital output, plus an outboard digital-to-analog converter (DAC) - The soundcard I recommend with a digital out is the PCI version of the M-Audio Audiophile, for reasons I will explain below. Get one used for $90 on ebay. Like professional soundcards, the DAC will cost as much as you care to spend. Starting at about $200 you will see a clear improvement over the USB soundcards. I would look for a DAC in the classifieds of Audiogon.com. For buying high-end audio components Audiogon is awesome. It has more sellers than ebay, and it's not an auction so you are more likely to get a great deal if you send in a quick offer. Some recommendations on a DAC: For a little over $200 you can get an MSB Link DAC III. That will sound way better than any consumer soundcard. If you want to improve on that, for another $200 you can add a Monarchy DIP to the MSB Link DAC, or buy MSB's upgraded power supply. The downside of this approach (other than the cost of the DAC) is that if you want to digitize analog input, you will have to buy another separate piece of equipment.

    A word of warning, many soundcards have a digital out, but not all of them are what you want to hook up to an external DAC. For example the Extigy has a digital out, but it will only output at 48kHz or 96kHz. That means for CD (or mp3) audio, which is at 44.1kHz, it has to resample the signal. This creates some artifacts. Going from 44.1kHz to 48kHz is kind of like scaling up a digital image by a fractional value, at best the picture will end up a bit blurry. It is really hard to find out if a soundcard does this from a manufacturer's website. If it doesn't resample the signal they might say something like 'true bit-for-bit digital', but most of the time they won't say anything either way. I know the M-Audio Audiophile can output at multiple sample frequencies and hence doesn't resample the signal.

    Conclusion

    All of the options I mentioned will sound really good. Even the Extigy, the cheapest, will be completely free from the crackle and buzzing you describe.

    21 Oct 2003 (updated 22 Oct 2003 at 17:04 UTC) »
    Re: What Customers Want

    This is an interesting comparison. It's a bit hard to establish what really makes people love your software (as opposed to what they say they want). You might be able to figure it out via introspection. Here's my list.

    What will make people hate your software.

    1. instability, causing lost user input
    2. bad interface
    3. poor perceived performance

    Some Explanation

    1. Instability is not inescapably damning. If a software failure does not result in lost context or lost user input, then it hardly amounts to more than a delay while the software restarts and/or recreates the pre-failure context. On the other hand, users hate to have to repeat themselves. If the user has to manually recreate context after a crash, or re-enter some input, then they will (rightfully) hate the software. Conversely, I believe users will love your software when they recognize that it saves them from repeating the same input.

    2. What constitutes a good software interface and ease of use is not agreed upon, even among experts. But there are some interfaces that are universally despised. I won't say more.

    3. Performance problems actually fall into two categories. One is poor perceived performance, the other is poorly performing features. Poor percieved performace is actually a symptom of bad design, not a bad implementation. Even objectively slow software can be pleasant to use. If software always provides a quick acknowledgment of user input, and performance is predictable (even if it is not fast), then users can adapt and work around absolute deficient performance. Poorly performing features will not make users hate your software. Users simply won't use those features if they don't have the time. Unpredicatable performance will frustrate users. Users won't hate your software just because some features are slow. Given sufficiently expressive tools, users will always want some features to be faster. That is unavoidable. And anyway, users will eventually try to do things that are impossible to make as fast as they want. Impossible to make fast because the problem is computationally intractable, or because of the volume data they are working with is just too large. It will not be naturally obvious to the users which things are inefficiently implemented and which things are impossible to make fast.

    11 Oct 2003 (updated 11 Oct 2003 at 16:03 UTC) »
    Damn those Red Dots

    I just saw Kill Bill. It was excellent. But damn, those Red Dots pissed me off! For those who aren't aware yet, many new movies coming out contain brief flashes of Red Dots, randomly placed, every few minutes. The theory is, these Red Dots will foul up video encoders like DivX, thus making the movies harder to pirate. What pisses me off is that 1) this is completely boneheaded from a technical perspective. Anyone with half a clue can see that this won't do squat to stop pirates. The encoders will work around the problem in the next versions. And the movie studios can't create new problems, because there is a limit to how messed up the picture can get before people stop going to see them. 2) the Dots are already totally distracting; they are visible even when you're not looking for them.

    The Red Dots must have been put on the movie after production, like when the prints were being made for the theaters. I cannot believe that Tarantino or anyone with creative control of Kill Bill has watched a reel with the Red Dots in place. If they had, they would never have let it go out to the public. The Red Dots are even flashing during the scenes that are in black and white.

    29 Sep 2003 (updated 30 Sep 2003 at 05:01 UTC) »
    mwh: I share your irritation with C. There is no standard way of discovering the type of a library function at runtime. What is even more irritating to me is that even if you do somehow discover the type of a function at runtime (say by parsing the headers, or the debug information), I know of no way to construct a call to the function. Meaning that even if you've got the address of a function, and you know what type of arguments it expects, there is no way to call it, unless you've got a precompiled stub function of exactly that type. But you don't have that of course, because you only just discovered the function's type at runtime. But GDB can do it, so it's not impossible, it probably just involves some low-level non-portable work. One thing on my todo list for a while has been to break this functionality out of GDB into a nice little library. Anybody writing an interpreted language could use this to allow calls into precompiled C libraries, and leverage the porting work that GDB has done to all the platforms it supports. But it's a pretty low priority for me because I don't have much use for a GPL'ed library right now.

    Update: via email, Pierre points me to libffi. It does pretty much what's described above. It lives in the gcc source tree, but its license is less restrictive than the GPL. Free software rocks!

    23 older entries...

     

    Others have certified jdybnis as follows:

    • burtonator certified jdybnis as Apprentice
    • sh certified jdybnis as Apprentice
    • ade certified jdybnis as Apprentice
    • AlanShutko certified jdybnis as Apprentice
    • ebf certified jdybnis as Apprentice

    [ Certification disabled because you're not logged in. ]

    New Advogato Features

    New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

    Keep up with the latest Advogato features by reading the Advogato status blog.

    If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

    X
    Share this page