Announcement

Collapse
No announcement yet.

Midrange and Tweeter Selection Guide

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Midrange and Tweeter Selection Guide

    I find the Parts Express Woofer Selection Guide extremely helpful when looking for a driver to meet a particular requirement. It would be great if Parts Express provided a guide for midranges and tweeters. For instance, when I try to find a tweeter to fit my needs I end up opening nearly every tweeter page and scrolling through the data to see if it fits. Right now I am looking for a high-efficiency 8-ohm tweeter. It would be great to just go to a guide and sort by SPL and then compare the frequency response, just like you can with the Woofer guide. It would be nice to have the same sort of guide for the guitar and bass speakers too, some of them are killer midbass drivers if you are into high efficiency. The framework is already there and the data available. Please add this to your website. While I am thinking about it and I am asking for the sky, I would ask for a modification to the response curves column - adding ±3 dB and ±6 dB qualifiers to the selection guide would be super helpful. These new guides would save me hours and I would guess I am not the only person with this experience.

  • #2
    I'd be happy if the woofer guide was updated. While it seems like an impossible task to keep it current, just a date it was last updated would be helpful.
    John H

    Synergy Horn, SLS-85, BMR-3L, Mini-TL, BR-2, Titan OB, B452, Udique, Vultus, Latus1, Seriatim, Aperivox,Pencil Tower

    Comment


    • #3
      Lookie here:

      http://techtalk.parts-express.com/fo...11-to-mikev-pe

      Not sure if this was my 1st request (it IS from 2006 !), but back 12 yrs ago they still had an annual paper (complete) catalog - which IIRC was only terminated about 4 yrs ago? 5-10 yrs ago they DID have a few pages for the printed Woofer (Hi-Fi) Selection Guide, and well as a (Pro Sound) Woofer Selection Guide. The online version was (is) sooo cool, 'cause you can sort data by column headers (and it's got the hot links).

      Anyway, I've been trying to get PE to start a TSG for at least 12 yrs it seems; usually I'll make an attempt maybe every other yr. or so - always falls on deaf ears I guess. The last 10 yrs has seen the number of tweeter choices increase by a magnitude making selection a LOT more difficult. Even the variety of types (domes, planars, ribbons, waveguides, CDs) has increased significantly.

      Comment


      • #4
        One small criticism of the woofer selection guide. I wish the column labels were visible no matter where one is in the list. When you get down a little ways, the labels disappear, and its easy to get the columns confused or simply not know what you are looking at.

        Comment


        • #5
          I don't know, if you have friends in the forums, get them to hop on this thread so it gets some attention. I've been a PE customer since 2000, I just never felt compelled to post. I've kind of missed out on the community.

          Comment


          • #6
            Hey P.E - can that part of the site have separate access controls which you could assign / delegate to a member here? You might get a volunteer to maintain it.

            Comment


            • #7
              Originally posted by Dave Bullet View Post
              Hey P.E - can that part of the site have separate access controls which you could assign / delegate to a member here? You might get a volunteer to maintain it.
              +1 and frankly, it should be able to automate fairly easily, updating itself by reading the backend data files.

              Even if a basic (crude) foundation was built it could then be extended to cover every single component anywhere and become a sustainable solution.

              Having it use common components where those components are shared across modules, 1 change (or fix, or enhancement) to such a module, like fixing an 'update" algorithm would automatically be picked up and used by all other code using it on its next load.

              Just another 2c added.
              Feel free to rip my assumptions apart when wrong, or fix if close.

              Passive Radiators:
              All PR(s) Vd must be at-least double all woofer(s) Vd. Calc = Sd x Xmax to get Vd for all PR(s) and all woofer(s). A combined PR(s) Vd equal or > than a combined woofer(s) Vd is usable.
              Woofer(s) with large Xmax vs Sd, all PR(s) with Xmax at-least double all woofer(s) Xmax is usable.
              A PR max weight is said to be its Mms x3

              PR Systems - tight focus with key parameters.
              PR Speaker Design - thorough coverage.

              Comment


              • #8
                And now the guide is just broken. Unless it's just me, my laptop, my ipad, and another pc on a totally separate network...........I've resorted to popping it all into LibreOffice Calc.

                Comment


                • #9
                  Originally posted by Thump View Post

                  +1 and frankly, it should be able to automate fairly easily, updating itself by reading the backend data files.
                  I'm pretty sure I remember someone doing just this, but with an external web site. No clue what it was called, but it scraped the PE site to make search far easier.

                  Comment


                  • #10
                    Originally posted by Zach C. View Post

                    I'm pretty sure I remember someone doing just this, but with an external web site. No clue what it was called, but it scraped the PE site to make search far easier.
                    Ahh man that's a bummer if it went obsolete / abandoned or was eventually prevented access for some reason!

                    The community of developers around the planet love doing precisely that type of work. It can be a tremendous benefit to customers and the vendor (PE).

                    Customers get refined, dedicated searching capabilities to find stuff they're actually after fast, PE doesn't have to maintain it (spend money) and PE gets paid because the actual purchase process and everything else is done at PE.

                    The community driven site is simply helping the vendor by providing a more robust, dedicated search UI to locate a few items easier from the hundreds, or thousands of items provided by the vendor.

                    I doubt PE has (or exposes) a REST (API). That'd be a key question if an external site were to be discussed.

                    That's all it would need to do though. Json packets (ultra tiny simple text-based, delimited blocks of data) contain everything about an item relevant to what a customer needs to know about it. The details can get extreme - a wonderful thing - vs what the vendor provides on its own site too.

                    An example would be let's say PE has a typical item page. The amount of information they provide about "item x" is all up to how much work and time the PE (or site developers) decided to spend. I don't find the current information about "item x" at PE to be particularly deep, although deeper than others.

                    To the contrast, a community driven site could pull incredible, extreme amounts of details from multiple sites about "item x" and make it all available. For the (nature of the) items PE sells, technical data is absolute king. A community site could embed all kinds of different technical data about "item x" with multiple sources all presented in a unified "item x" page result.

                    For exposing "item x" data some sites still use XML as the stack for payload. However, the overhead - the structure of XML nodes, attributes and the stack to support it - is far larger than Json, therefore the bandwidth savings is usually gigantic between Json vs XML even though the item itself is the same item.

                    Json doesn't waste space. It's dedicated to providing "item x" data in the smallest most efficient packet of information possible. This is a core reason it became a defacto with REST and started replacing XML very quickly. The underlying stack (typically including SOAP) for XML is another reason. It's a lot of plumbing and only makes sense (now) when very highly structured output is required or where the structure and embedded structure is a better candidate (because of some existing parser) than using Json.
                    Feel free to rip my assumptions apart when wrong, or fix if close.

                    Passive Radiators:
                    All PR(s) Vd must be at-least double all woofer(s) Vd. Calc = Sd x Xmax to get Vd for all PR(s) and all woofer(s). A combined PR(s) Vd equal or > than a combined woofer(s) Vd is usable.
                    Woofer(s) with large Xmax vs Sd, all PR(s) with Xmax at-least double all woofer(s) Xmax is usable.
                    A PR max weight is said to be its Mms x3

                    PR Systems - tight focus with key parameters.
                    PR Speaker Design - thorough coverage.

                    Comment


                    • #11
                      The guy that runs hificompass which lists driver T/S params and I think large parameters allows sorting. It wouldn't take much to add a filter.

                      I'd actually allow people to upload driver data and then possibly signed up members to vote or validate so you could associate confidence in the data. That way one admin doesn't become a bottleneck.

                      A bit of PHP would do the trick on a mysql DB. Easy enough then to add a REST/JSON API to allow people to pull down and filter on data. Even an upload API however I think a web UI would get most use.

                      Comment

                      Working...
                      X