OK, I'll add you tomorrow when I'm back at my workstation with crates.io credentials.

Yeah, you don't want to read position right now.  I eventually plan to optimize that property specifically.  But even if I do, you still run into another problem: you might get a value slightly in the past.  That's true of almost any audio library in existence.  At the moment there's no way to sync a bunch of BufferGenerators together because that's a rarely needed feature.  Usually it doesn't need to be sample accurate and you can just start them all in a loop and manipulate them through gain (i.e. silent ones are gain=0, and you fade them in and out).  As long as you're not doing it for literally everything in your game, the cost of having a few silent BufferGenerators playing here and there is negligible.

If you truly need sample accurate BufferGenerator syncing, you'll probably get it eventually.  Just not now, and not through BufferGenerator.  The goal, after reverb, is to cover the common use cases with generators specific to those use cases.  SO for example you might get MultibufferGenerator or something like that out of it.  Libaudioverse tried the "be incredibly general" approach, and it's not possible to do that well without more resources than I have (thus me not continuing it and starting over).

There's internal support for it, but it looks like I never exposed it.  I can probably get you that this weekend.  It's the kind of thing that should take 10 minutes being as it's already there.

Probably not very hard.  It can be called from anything that can call C stuff and the API is relatively straightforward and likely as not to stay that way. But I don't know enough about Lua to write bindings or something, in fact Lua doesn't really even exactly have a concept of bindings in the first place, so you're on your own when it comes to actually doing it.

There's at least two ways of doing it that I know of, and the standard one is that the embedder embeds dependencies as the embedder, so you'll need to figure out what if anything the thing you want to use it in offers for binding C stuff.  There's a lot of options and no real standard, so it quickly turns into "Lua bindings for Synthizer that work with only these 5 apps" or whatever.  The only "cross-platform" way is to write a C module, which maybe I'll do that eventually, but it's time-consuming and I don't think it can be automated, so you'll have to find out what's available in the environment you're in and go from there.

Synthizer will be fine, as long as you have CFFI aboard, and MUSHclient lua with CFFI embedded is working fine, so thats not a problem. For non-CFFI solutions though, a C wrapper will be required, as was already explained earlier.

You are allowed to sell such products, but you'll have to purchase a shareware license from BASS first, which costs a few hundred bucks. Not that expensive IMHO, since you're going to get quite a few bucks back from your own product as well.

Sure, as can be seen in this thread, the docs are located under https://synthizer.github.io.

thanks @262! This thread is so huge, that searching anything in it is impossible.
now about the C API, I think I slowly grasp the thing, it's actually easy enough to use. If I didn't know better, I'd honestly say this was made from the start to be compatible with the horible dll support implemented in bgt, but we all know it can't have been made so by design since every developer who knows what he's doing, like @camlorn here, knows enough to stay away from bgt like the plague.
As I read the documentation, I maybe will find something I don't understand, so I need to post somewhere. So what do you guys think, should I make a new topic, or post in this one?

@camlorn: No, no, surely I won't do that. In fakt, why the hell would I want to sell an audiogame engine that's...just made for the blind? I won't get any money worth my efforts anyway, so might just offer it for free, and open source as well! I only said that, as an example with bass and the part of the license I didn't quite understand. Yeah, of course I'll give you credit for it, as will, I think, any dev in this community competent enough to use the lib, we know it's not our work, so I see it only as bad fate for someone not crediting you, as I'd say if someone would use my as yet non-existing engine without at least saying they used it, just bad fate.
yeah, I knew in a way that the more advanced things in the API would be more complicated, but I really hope there won't be too many structs and such, since those constructs are abit hard to bind, or at least for languages that don't have that concept or if they do, most of them don't pack them correctly in memory so that they are understandable by C. From what I herd, even rust, though it uses structs and compiles to native code, doesn't respect C conventions for field alignment by default, unless you prepend the struct with some attribute I forgot the name of. Python, for example, needs a class with a dictionary inside denoting the fields of the struct or something like that, what I know for sure is that it uses the struct module and has...quite enough boilerplate to deal with for a binder.
the .net, however, must do almost nothing for that, because, like in rust, you just have to specify an attribute from the System.Runtime.InteropServices namespace since the struct type already exists in the cls, so an attribute in front of the declaration. Well, it seems I don't need to fight with the language so much with those structs, but please, if you can, try to keep the API as simple as possible.
btw, is it supported to load in a decoded byte array of samples and have it played, as if the decoder had already ran and it's output would be those bytes? because if so, you won't need to integrate all file formats directly into synthiser, rather aditional formats besides the core ones would be considered pluggins, then you could decide whether or not they would be included in the main repo or create a new pluggins section in your documentation. Bass does this, too, and now they have all sorts of weird formats and stuff, even midi, made by the community, I think?
and yeah, it seems that bass doesn't have that buffer cashing/sharing capability directly implemented, but one could create a channel with the file loaded, then use BASS_ChannelGetData to get the buffer data, then you could, I suppose, cash that. Though for that buffer to be complete and ready for cashing, e.g. the channel handle is not a streamming channel, the file must completely be loaded into memory, so BASS_SampleLoad needs to be used, but that has limitations regarding file sizes, encoding, and samplerate, obviously. So, if nothing changed since I last used it, then I don't think such a thing exists in bass, perhaps with an add-on?
so yeah, I think that, with alittle time, synthiser will become the next bass, if not better, and I could see that happening in the near future.
now, to another thing:
how many platforms has this support to build against out of the box? windows, what else? mac OS, linux? uwp? android, iOS, wach OS, XBOX?
for example, monogame, the basis for my future engine, is able to deploy games on android, iOS, uwp(through xamarin), as well as several consoles, including the play station, dreamcast, nintendo switch(I believe), and Dk others off the top of my head, I'd have to look them up to find all of them out. Thing is, I really could care less about those weird consoles and stuff, but I'd like to not include anything that would make the game unbuildable on platforms monogame would run on, even though I won't support them explicitly, that's why I'm trying to put on the list as close to only .net core libs, if not only microsoft components and nuget packages, like grpc for networking, for example, since there's a nuget package that's inheritly cross-platform, because it says it runs on .net standard. Another such thing would be the bullet sharp library, a wrapper around the bullet physics engine. That, too is written in c++, but I hope it builds at least on android, iOS, and uwp(x64/arm).
so, how easy is it to compile and link synthiser against new platforms? for example, any part that I know it's cross platform as far as compilers go, and any single one where I know most of the platform specific stuff resides, like playing sounds and stuff? if it's too hard to port to consoles and such, I sincerely could not care less, since I don't have one anyway, but I'd like to know if such portings are possible and what platforms are already supported

BASS has buffering support built-in, they're called samples over in BASS' infrastructure. They get loaded and decoded in-memory and you can create up to X independent channels of those, where X can be specified freely by the application using BASS. Changing data on the sample will then again influence all channels, which allows for quite flexible data management.

@269, can you explain your rationale for contributing that to rust where it doesn't follow C conventions for structs?

@269
Great, thanks for the change, but it does seem to be a little broken haha.

It seems that values >= 1.002 and <= 0.991 start distorting. I haven't had chance to test it on my proper speakers yet, but I've never heard that on my laptop speakers before.

BTW, is there any facility within Synthizer to record the output like there was on libaudioverse? Thinking it might be useful for you to be able to get direct recordings of our outputs. No worries if not, there's always alternative recording solutions.

Thanks again for all your hard work.

@272
I was testing with quite large values here. I will investigate.  Maybe there's an issue with fractional values or something.  As I said, it was never heavily tested: I wrote it to prove a design, and then put it on the back burner with the intent to pick it up again later when I'm ready to do the doppler effect.

Adding something to record data is doable, but not going to do it now because it's fiddly.  I forgot Libaudioverse even had that, but probably it was done wrong, because back then I was doing things just right enough to work but just wrong enough to be dead ends.

@273
Still have to have an Xbox, but you're right, I forgot that one didn't have a dev kit now.

Getting this going on Linux or Mac isn't something I think will be very hard.  It's just an issue of priorities: I effectively have one C++ dev working on the project, but if I hypothetically had more then I'd effectively only have one "I can write synthesis stuff" dev, so no matter how you slice it getting to having a good one-OS story is more important to me.  And work isn't leaving me with enough energy for 8 hour Saturday coding sessions right now (it's a great job, just a very busy one for the last month, and probably for a few weeks yet, but hey--I'm getting paid to do Rust).