Writing a Cross-Platform, Free Software Modeling Tool and TS-Parameter DB

[justinzane]

Intro
I'd really, really love some feedback about this. Like would you like to use this tool, would you be able to provide tech expertise, would you be able to provide programming or design input, etc. Even if you think it is stupid, please tell me why you think so.

Background
For a long time, I've been making and fixing stuff for others -- new floors, new walls, etc. for my wife (and soon, the bank 🙁 ); networks, servers and apps for employers -- you get the picture. So when I became fed up with the quality of the sound in our house, I decided that I would like to make something just for myself for fun.

That led me to the land of DIY audio. There are loads of great vendors and parts. There are an endless range of project complexities from the $20 + 2 hour quick-n-cheap to the 6-figure expensive and PhD-thesis complicated. There are boatloads of great people from those brilliant E.E. and PhD types to enthusiastic amateurs to happy wackos that provide help, inspiration and entertainment.

The one thing that I cannot find is any good, comprehensive software tool to help with the basic of speaker and system design. There is a plethora of little bits, from 15yo Excel spreadsheets through simple javascript calculators and a heap of proprietary software.

The Goal
I would love to, with the help of those who are more knowledgeable than I, to develop a reasonable comprehensive toolset for speaker design, likely including a web-based Thiele-Small database, that is free and open-source.

I've considered both traditional desktop/mobile application design and web-based design as an implementation strategy, and have yet to understand to true demands from a computational perspective.

What I Need
The simple coding aspect of this does not seem overwhelming, but I am simply to ignorant of the math and physics of acoustics to be able to do this independently. I also kinda suck at UI design, tending to spend most of my life with a bash prompt in front of me.

That means I would need significant help from others who share the same goal -- free and easily accessible tools for anyone interested. Please let me know what you might be able to help with and how much time you might have to lend to the project.

Thanks!

Notes
- I do most development in Python with Numpy/Scipy and Cython for the numerical stuff. I also prefer to keep code on GitHub.
- By cross platform, I mean minimally supporting major Linux / BSD distributions, Windows XP-8 and Mac OSX. Ideally support would also include Android and iOS. My personal priority order is this: Linux[Debian-based] > Linux[Other] > BSD > Windows > Android > OSX > iOS.
- For cross-platform traditional development, I would prefer Qt4 or Qt5 since I know that Qt works well on a variety of platforms and looks good.
- For web UIs I prefer either Dojo or ExtJS as a core.
- For the speaker T-S database, it seems like a NoSQL variant like MongoDB or Google's AppEngine Datastore would be a good fit.
- I'm interested in opinions about the most appropriate simulation libraries.

 

[hochopeper]

Hi Justin,

I am not the expert you're looking for but I do find myself nodding in agreement with your goals!

I think web based UI would be my preference.

For NoSQL stuff I have always wanted to try something with CouchDB.

I am also familiar with the Python numpy/scipy suite of tools (I am a HUGE fan of the new iPython Notebooks for interactive work)

I would happily contribute to a project like this on github if this gets off the ground 🙂

Cheers,
Chris

 

[justinzane]

@hochopeper: I don't know why it took me so long to discover iPython, but I'm addicted now. It is only behind the browser and bash (normally via yakuake) in my list of most used tools.

As far as CouchDb goes, I just started playing with MongoDB since it seems to be developed with less of an Apache/Java focus. My experimentation is severly limited, though. In what little experience I have, I enjoy NoSQL much more tha SQL. For anything outside financial and rigid technical data, i.e., human generated data, NoSQL seems ideal.

I sure hope that someone with acoustics technical knowledge can help.

 

[stochastic]

Intro
I'd really, really love some feedback about this. Like would you like to use this tool, would you be able to provide tech expertise, would you be able to provide programming or design input, etc. Even if you think it is stupid, please tell me why you think so.

I'm interested in helping. I've developed/tested some open source software before and would love to get a nice speaker design app built for Linux. I'm also doing a systems engineering degree currently so I might be able to help with some of the math - or at least find others who can.

The one thing that I cannot find is any good, comprehensive software tool to help with the basic of speaker and system design. There is a plethora of little bits, from 15yo Excel spreadsheets through simple javascript calculators and a heap of proprietary software.

I sympathize with this, but as a problem statement it needs to be fleshed out more. Particularly the vague phrase of "help with basic speaker design and system design" causes troubles. What aspect of speaker design are we wanting to work with? Box design, driver design, thiel small measurement, crossover modelling, etc...?

I realize that small tools are sometimes tricky to piece all the project plans together across, but the general design principle of a single large application that does it all can be extremely difficult to do well. I think the project might best start out with one to three features that it does really well and a development plan to expand it into a larger tool set.

Also, we probably want to utilize those antique tools for building this project - provided they're open source as well.

The Goal
I would love to, with the help of those who are more knowledgeable than I, to develop a reasonable comprehensive toolset for speaker design, likely including a web-based Thiele-Small database, that is free and open-source.

I've considered both traditional desktop/mobile application design and web-based design as an implementation strategy, and have yet to understand to true demands from a computational perspective.

I'm heavily in favour of the traditional program design format rather than web-based. Though I might be able to be persuaded to change my mind. I believe that in order to create anything worth more than $50 one will need a tool that is just too complex and computationally intense to host on some server (not to mention costs behind running that server). Also I assume some TS measuring or FR measurement would probably need to be included in the app and gaining access to the user's sound card input can be a complex challenge on web apps.

I'm not sure what use a TS database would be as it would always be incomplete and likely inaccurate. The number of driver manufacturers on the market is immense. The rate of new product design is relatively fast with old models regularly being slightly improved/altered giving different TS numbers. Furthermore the manufacturing TS deviations are always a guarantee rather than the anomaly. Maybe I'm just misunderstanding what the concept is, but I don't think this solves much in the problem statement.

I think the first steps you've taken by brainstorming and writing ideas on this forum are great. Have you considered posting the idea to audio-centric open source software IRC channel or mailing list?

 

[justinzane]

I'm interested in helping. I've developed/tested some open source software before and would love to get a nice speaker design app built for Linux. I'm also doing a systems engineering degree currently so I might be able to help with some of the math - or at least find others who can.

Awesome.

I sympathize with this, but as a problem statement it needs to be fleshed out more. Particularly the vague phrase of "help with basic speaker design and system design" causes troubles. What aspect of speaker design are we wanting to work with? Box design, driver design, thiel small measurement, crossover modelling, etc...? ... I'm not sure what use a TS database would be as it would always be incomplete and likely inaccurate. The number of driver manufacturers on the market is immense. The rate of new product design is relatively fast with old models regularly being slightly improved/altered giving different TS numbers. Furthermore the manufacturing TS deviations are always a guarantee rather than the anomaly. Maybe I'm just misunderstanding what the concept is, but I don't think this solves much in the problem statement.

<sarcasm>Yes. 😉</sarcasm> The real answer is that I would love to see a complete set of FOSS acoustics tools; however, that is far too grand and imprecise a goal for a practical start. As far as I can see, acoustics software as it relates to the DIY Audio crowd consists of:

• Driver Classification: The physical dimensions, Thiele-Small parameters, and optionally vendors, approximate pricing, subjective reviews, etc. This seems pretty simple, though there is the problem of dealing with partial specifications and variant specifications. One of the reasons I think it is important to have a driver database is that it saves users from having to endlessly retype data from spec sheets or vendor sites. The other is that it can help catch typos in spec sheets. I just came across a situation where the specs on a vendor site and on the OEM site differed. It was only a type, but a change in Vas from 7.xx cu.ft. to 2.xx cu.ft. is really pretty significant.
• Enclosures: There are numerous types of enclosure [sealed, ported, TL, horn, etc.] and there are a plethora of mathematical models that correlate with these types. One thing that bothers me from a science geek perspective is that all models make simplification assumptions, but there seems to be little way for an end-user to clearly understand the limitations of any given model for any actual enclosure design. In practice it should be easy to implement the most common enclosure types and their models quickly. My goal would be to enable iterative enhancement of the enclosure models that is at least partially independent of the software development cycle.
  
  This would probably mean providing a method for persisting executable models in some sort of standardized way so that technical experts could contribute without having to clone the main repo and submit pull requests. This is a general goal and not a "requirement". It would need significant definition and clarification from the technical and developer communities to work well.
• Crossovers: The passive type should be easy, at least for the most common designs.
• Amps: ???
• Environments: This seems like the most complex and difficult soft of modelling and simulation to do. Unless one has a purpose built audio room, the number of confounding variables and conssiderations is boggling to my mind. I would think that this would be an excellent component, but one that would need massive amounts of technical and developer contributions. Probably a long-term wish list item for now.
• Testing: Conceptually simple, but in this case, I think that the majority of effort would go into building and maintaining the file and device IO drivers for actual test equipment. I need feedback about the practical difficulties here.
• TBD

I realize that small tools are sometimes tricky to piece all the project plans together across, but the general design principle of a single large application that does it all can be extremely difficult to do well. I think the project might best start out with one to three features that it does really well and a development plan to expand it into a larger tool set.

Also, we probably want to utilize those antique tools for building this project - provided they're open source as well.

Couldn't agree more. I'd like to see a base interface with modular feature funcationality that can be added as skill, manpower and motivation dictate. Seems like the core functionality to start with are drivers, sealed boxes and basic testing.

I've been looking at gspeakers source and found that there is little "acoustic" code, the majority of it is UI stuff.

I'm heavily in favour of the traditional program design format rather than web-based. Though I might be able to be persuaded to change my mind. I believe that in order to create anything worth more than $50 one will need a tool that is just too complex and computationally intense to host on some server (not to mention costs behind running that server). Also I assume some TS measuring or FR measurement would probably need to be included in the app and gaining access to the user's sound card input can be a complex challenge on web apps.

I've been bouncing this back and forth in my brain and really don't have an answer. As I see it, some of the pros and cons:

• Pro Web UI
• HTML5+Javascript+CSS is accessible to just about anyone with just about any device. Worries about Windows/OSX/KDE/Gnome/Android/Tizen... go away. This is a HUGE plus to me.
• Updates are cake. Users do not have to do anything to use the most recent version of the software and bug fixes and be rolled out almost instantly. This makes live development and testing workable for more than a tight group of devs.
• With the explosion of residential bandwidth, virtualization capabilities on commodity PCs and horizontally scaling database and application frameworks, it is possible for a small group to each contribute CPU cycles, disk space and bandwidth during an introductory period. Citing diyaudio's home page: "Most users ever online was 1,612, 2nd January 2013 at 12:10 PM." This means that the likely number of simultaneous users of any web toolkit would be well below a thousand. With proper caching, that should be a minor load, though I'm totally talking out my *** at the moment.
• Referring to the above farting noises, I am assuming that the vast majority of the calculations can be done on the end-user's machine via normal javascript or web-workers or the like. If there are some important calculations that absolutely, positively HAVE to be done in C/C++/OpenCL, then all bets are off. There are tools extant for executing all sorts of odd things in a browser sandbox, but that is beyond my experience.

• Pro Desktop UI
• More calculation capacity than web UI, and much more easily accomplished.
• No reliance on donors to provide or fund server CPUs and bandwidth.
• Much easier to interface with actual sound devices. This is a huge boon for testing and iterative design functionality.

I think the first steps you've taken by brainstorming and writing ideas on this forum are great. Have you considered posting the idea to audio-centric open source software IRC channel or mailing list?

No I haven't, although that is an excellent idea. I'm ignorant of what communities might be interested; do you have any suggestions?

 

[stochastic]

You may want to jump in on discussions in this thread: My first crossover design (yes I've measured things) but I can't find any software... - Page 2

 

[forart.eu]

Dunno if the project is still alive, but i suggest to keep in serious consideration to adopt JUCE for multiplatforming:

JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ class library for developing cross-platform software.

It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound.

JUCE Cross-Platform C++ Library

Hope that helps, or at least inspires !