@52
You can get the latest artifacts from the CI page. Click artifacts and download the zip, you want synthizer.dll.

But two things.

First, it's probably premature to make bindings.  We're hitting usable in the sense of could technically use it, but if you give me another month or so we should hit usable in the sense of you'd want to actually make a game with it and won't be converting all your files to .wav.  I'm glad to see a lot of enthusiasm from everyone, but at the same time I don't think I've made a secret of this being relatively early development, even if things have sped up enough that I generally have something new once a week.

Second, I won't be accepting PureBasic wrappers upstream because doing so implies that I'm willing to maintain them myself should you or whoever else is involved walk away.  Even if someone else is maintaining them, being in the official repository means I'm responsible for testing/reviewing/otherwise ensuring quality, reviewing pull requests on it, etc.  Getting a binding into the official repository in general is a pretty high bar, being as I then become responsible for making sure it's always up to date.

PureBasic is incredibly niche, commercial, and I can't even get a working CI setup so basically that means I'm out $80 or whatever it is and instead of just getting an e-mail when I break it I have to remember to manually test it by hand anytime I change anything.  For anything else involved here Appveyor just sends me an e-mail "Hey your build failed" and after I put another hour or so of effort into it I'm literally going to be able to do releases by typing two commands at a terminal and having lunch (and just getting an e-mail "hey your release failed" later).  Even if I decided that PureBasic was the most important language in the history of languages, I could literally do 4 or 5 more mainstream languages with the same amount of effort it would take for me to keep up with it.  For what it's worth,  all of this also applies to BGT, though in BGT's case the real issue is that the tooling needs to have a terminal to work in CI.

I'm not saying don't do it.  I'm not saying it's valueless. I'm just being realistic about your chances of getting me to put it in camlorn/synthizer, i.e. that there are none unless I decide to lower the bar for the project, and trying to offer an explanation as to why I'm telling you no.

I'll make a rapper and host it on my site.
Thanks for the link, I can't wait to try this!
Most of my sounds are wav anyway
I also work on tool that allow me convert entire folder sound into wavfile with single click.

Hello camlord

so, what are the last updates of the project?

Maybebe a good idea update the first post with the last major news about the project, if something interesting was updated in the lasts weeks

thanks, sounds... interesting, but well. For the future maybe a interesting project create a small c# engine using this lib

things like directly instance and object and in background set the tables and that, aboid pointers and let the engine handle it, and these things

Sounds interesting

Wow, the new changes are awesome?
Is Go one of the languages you'd be willing to write bindings for eventually?
Also, could you maybe change the name SoundSource to something a bit less misleeding? It can confuse you into thinking that Sound sources, and not generators make the sound. Thanks!

Bleh, and as much as I hate to double post on my own thread, the thing about Synthizer is that unlike Libaudioverse Synthizer can eventually be finished.  Every binding I take on stops that from happening.

I am one of maybe 4 or 5 people on here who can handle writing an audiogame-friendly physics engine, maybe 1 of 10 people on here who can handle solving networking, maybe 1 of 20 or 30 who can solve incremental updates and distribution.  I'm not special, it's just that there's not that many other skilled programmers with an interest in audiogames who are also at the point that their solutions aren't going to be hacky.  I think I'm the only one who's ever even talked about having written a good serialization solution, even though it's project specific and can't be extracted.  All of these things and more are on my project list, and the end goal is either an offline RPG or an MMMO with a lot of solving the lacking audiogames ecosystem along the way, so that even if I never get that far we'll finally have all the pieces where when someone says "What do I do for X" there's a good answer that's not explaining how to invent X from scratch because we can't use Unity or something.

My point being: bindings can be done by people who aren't me.  Synthizer and everything else I listed needs me.  In addition to the above list I am the only person on this site who understands enough math to do Synthizer's audio processing stuff.  I get 8 hours a week at most, very rarely more, usually less.  If it can be done by someone else (as all the bindings can be) I'm not prioritizing it because there's a huge list of audiogames things that only I can do.

@62
Learning to write an HRTF implementation from scratch took learning to read LaTeX and spending months on reverse engineering basics that sighted people get just from seeing a picture.  Learning to do reverb, etc. took maybe a year or two before I could give us a practical implementation.  Learning to write efficient code took all of Libaudioverse to teach me what the mistakes were and an additional year or so after that to get to the point of being able to avoid them (Libaudioverse could be fixed but needs a couple months of full-time effort to undo mistakes and whatnot).  It's a bunch of specialized knowledge on something like 5 different things.  That said, if you've done DSP in college I'll happily accept patches, but I'm betting you haven't because that's not usually included in CS these days (I wanted to take it; it had prerequisites of a bunch of electrical engineering courses that were going to take two or 3 semesters to meet, so I didn't).

@64
Pan (both azimuth and elevation) are exposed through a PannedSource, as is panning scalar, which is what you want for stereo panning.  Stereo panners aren't implemented yet because priorities but are trivial to do, once they are you set the scalar to 0 for all left or 1 for all right.  The scalar works for HRTF too, where it assumes you want panning between -90 and 90.

I'm writing buffers today which are fully decoded in-memory assets. You'll get lengths and seeking from those.  StreamingGenerator will probably also eventually support it, at least where the underlying stream does.

Looks like spatialization_math.hpp doesn't include <math>.  My guess is VS2019 includes <math> somewhere and it's just happening to work, but I'll add this include and merge it in when buffers are done.

Interesting. Didn't realize that. It's worth doing and I'll drop it in, but do note that Synthizer isn't going to remain small because there's a lot of data tables that'll end up getting embedded for efficiency.

@68
Most if not all of that is out of scope and a significant effort, but I may at some point add the ability to specifically record the output.  For anything interesting with the microphone you should just use miniaudio directly.  Eventually there will be a way to shove PCM data samples into a generator, but anything I might write for the microphone would just be an incredibly thin miniaudio wrapper, nothing more.

Buffers are in as far as I can see, so creating sounds from in-memory should be possible, and as soon as that is a thing, you can theoretically add support for OGG and/or FLAC yourself, although I guess camlorn will at least add support for OGG "natively".

Ogg is going to happen but is lower priority because the library I have for it is kind of lame and I may need to fork it.  MP3 and Flac are coming first because the libraries for them were frankly written by someone who has a much better grasp on good API design (and hopefully they won't prove to be buggy), and I can integrate them in such a fashion as to allow all the things people want without reading a few thousand lines of C and potentially forking.  The prioritization here isn't in my hands in the sense that doing it in a different order will cause there to be a long delay until there's something useful, and the main thing is to have *any* lossy format, not a specific one.  My philosophy on that is that this is for games and if you have to convert, you can write a 5 line bash script to run ffmpeg over a directory in parallel in as many minutes.

Yes, buffers are in.  I was going to hold off on talking about that in detail until there's a version on Pypi.  Unfortunately it turns out that writing synthizer properties is 10 times too slow for practical usage and the fix for it needs a custom lockfree MPSC ringbuffer, so that got bumped from last weekend and might be a little bit out.

Decoding from byte strings is easy but not priority because as with many of the other things people are asking for, it's not necessary to have a useful library.