Re: samtupy camlorn audio wrapper usage
Angelscript is technically suitable if someone adds the things that need to be added, but Angelscript has so close to zero market share as to be inconsequential. Everyone uses better and faster things for their actual scripting engines. V8 and Luajit are very popular
The only platform I've ever heard of that uses Angelscript for something standalone is BGT. For that matter, it's the only thing I know of that uses it at all. The problem is that BGT fails to support threads and the ability to be called from C (you can call out. C can't call back in). I designed Libaudioverse in such a way that it can integrate with a garbage collector, but this means that a proper abstraction needs these things for object deletion. It looks something like the flyweight pattern and the proxy pattern, for anyone familiar with those terms. Other libraries will have more problems than mine, honestly; BGT's FFI falls short of binding half
the software, at least as it's documented in the help file. Maybe there's more that just never got written down, but everyone else these days uses Libffi for it and therefore supports basically everything (and if they don't, someone has probably written a libffi package for it, i.e. Java).
I don't use the Visual Studio IDE. I don't use Jaws because Jaws does all sorts of weird things to me on a regular basis, so I'm on NVDA. I prefer NVDA for lots of other reasons, but needing to use a dongle with Jaws and being told it was my fault was the last straw. I've been complaining loudly at Microsoft for a long time about VS accessibility on Twitter, but nothing ever happens; the reason Jaws works is because jaws has a mirror display driver and does who knows what to get around the fact that MS can't be bothered to properly expose their own product through their own accessibility APIs. It's good that you'
re reporting, as Visual Studio is very important for employment, but the debugger is probably the biggest problem and they've known for at least 2 years at this point (their response to me was that they didn't have time). Since I'm doing nominally cross-platform development, the IDE is fortunately not that important, and I hold out some hope that they're changing.
My workflow is CMake via the jom generator. Jom is a makefile thing from the QT project, and CMake can output files for it. Unlike MSBuild, it gives much less spammy output and, ironically, builds about twice as fast. This is a completely command line setup. I use CDB, the little-known Microsoft command line debugger. CDB is cryptic but insanely powerful considering, and gets the job done; in DSP land, debuggers aren't overly important anyway. I think it's a nice setup, though CMake can be a bit different when you first learn it (but o, is it powe
rful). CMake has some preliminary support for Windows 8/10 apps, Swift on OSX, etc; I'm not sure on the state of all of it, but they have tests in the official repository for them. Not to mention working the same on Linux and Mac. CMake is what LLVM uses for one, and that's probably one of the biggest projects out there now. Because of the science stuff and the custom bindings generation, the Libaudioverse build process also uses custom build steps to call out to Python scripts for a good chunk of stuff, but that's not really general to all projects.
I need to put up side-by-side Libaudioverse to OpenALSoft demos soon. I suspect Libaudioverse is better by a significant margin, but I've never done the listening tests. We'll see, I guess. If I can spin a Kickstarter or a Patreon or something, I want to take Libaudioverse MPL; I have to get money for it somehow if at all possible, as it's already taken a year
and a half and it's probably got another year to go before I can nominally call it done (there is a lot of stuff I want to add. HTTP streaming, Midi and soundfont support, etc). But I don't see making more than $50k from it if I go commercial, and if I go MPL then I can quite possibly get all sorts of contributors who do DSP as their research area and whatnot, who knows. Believe it or not, there are not that many things like Libaudioverse, not even for researchers.
If you do go OpenALSoft, you need to figure out what you're doing about the ini, but as you know some C that may not be a problem. It used to respect the ini before anything, which caused no end of trouble. If I had to summarize, the problem is that the developer would not concede that OpenALSoft is anything but a software replacement for a souind card, and expects you to program to the same constraints the "real" OpenAL wants you to, now long dead for all intent
s. That is, as opposed to being able to drive it completely as a library and specify everything yourself, etc.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
