Scott Wheeler

Are they still in the same location on your drive? i.e. you're sure that you haven't reorganized your samples (renamed folders, moved them to a different drive, etc.) since you created your Cakewalk project? Is this Sitala 1 or 2?

We do, but the symbols file for the VST managed to not get checked into our repo for build artefacts (just the standalone symbols got checked in, which isn't useful here), so don't have function names. We sent the user a debug build from the same tag, but didn't hear back.

One of the Sitala developers here: unfortunately the crash log didn't contain enough information to be useful; we sent @GCizza a debug build a couple weeks ago to see if we could help diagnose what was happening here, but haven't heard back, so there's unfortunately not much more we can do. Sitala's actually been around for 5 years and has had 7 public releases in that time (and more than 150,000 downloads). On KVR it's the most popular drum sampler after the Native Instruments ones, and MT Power Drum Kit: https://www.kvraudio.com/plugins/drum-sampler/most-popular

So the error message is dumb there. I just pulled up the code for that and it shows that message any time the kit saving fails, but there's another case where it can fail that isn't obvious from the error message: it can't find some of the samples referenced in the kit. I assume that's what you're hitting: there are still some samples in that kit that can't be found (I'm still too much in just-woke-up-on-Saturday-morning mode to try to reproduce it by creating a project and moving things around myself, but I added a to-do list item for our next release). Can you go through and see if every pad can currently play its sample? If there are any that can't, even if you're not using that pad in your project, saving will fail. Just clearing said pad should get it to work. There are two different lists of kits there: one just recently used, and the second is "User Kits". If you have things in your user kits, Sitala does look in your user kits directory if it can't find something referenced. You can find the actual folder for that by clicking on the little icon next to "User Kits" in Sitala: There if something was in the user kits on the old machine, and is still in the user kits on the new machine, Sitala should find it there. But again, that only works for whole kits, not individual samples. Does that make any sense?

I'm not sure I understand the question: Sitala doesn't use any extra directories to save info about kits -- everything is either included in the data saved into the Cakewalk project, or is in a .sitala kit (and our kits are just a zip file with a bunch of wav files and an XML description). Having a suggested locations probably won't be optional, but you won't be forced to accept our suggestion. We'll also have some logic in there to try to avoid temporary locations. And yeah, assuming that all of the other samples (at least checking for them) are in the same place as one specified manually is something we intend to do. I even have some vague memory of us having already written that code, though my brain's a bit fuzzy on that since we've been working on the iOS version for the last few months. Full skinability is very unlikely (honestly, both me and the other Sitala developer are huge skinning haters), but there is a dark mode that just made it into our last release of the iOS version that will also make it into our next desktop release. There's a screenshot of that here: https://twitter.com/decomposermusic/status/1544777181187932160

Do you have the same issue with saving with the Sitala standalone? Sitala kits are self-contained -- i.e. they contain the samples they use -- but the state used inside of a saved Cakewalk project isn't. We tried embedding the samples into the saved state, but it caused problems with a number of DAWs. The next update to Sitala (later this year) will include an automagic sample finder that uses the Windows Search functions in the background to find missing samples quickly. (We store enough info about the files in the stream to know if we've found the same one, even if it's been moved.)

We don't have any plans to make a melodic sampler at the moment. That doesn't mean that it won't ever happen, but there's almost no chance it'll happen in the next couple years.

I thought I'd go ahead and drop in slightly more technical details in case @Noel Borthwick or others are interested. The API for this is very small -- basically the 4 functions that have to be implemented. I just posted the current version (which we're using for Reaper at the moment) in a Github Gist: https://gist.github.com/scotchi/4066f56b71b7b3b112b05df26d52034c There are a couple core ideas here: We want create several very small interfaces, so that DAWs can pick and choose which extensions to implement We want to keep the interfaces very generic so they can be implemented frictionlessly by other plugins

There are various ways that a poorly written service could take resources even when doing nothing, but a well-written service won't. It will however take a little bit of CPU time when the system is started up. What's confusing in the Windows system monitor is that it shows which resources have been allocated; that's only part of the picture though: system memory can be swapped out to disk when it's not in use, and that will usually happen for a service that's not doing anything.

I don't quite understand what you're suggesting here, so to be clear: in our first couple of alphas, there was a background service that ran and didn't actively do anything. (Being pedantic, a background service that isn't doing anything doesn't actually consume system resources: its memory will be swapped out, and it doesn't take CPU time.) When you start up Sitala, then and now, it checks for updates. You can't upgrade an app from inside the app itself, so you have to start a second process to perform the upgrade. In our first couple of alphas, we did that with a background service. Now it just temporarily starts a second upgrader process that automatically exits when the upgrade is finished (and upgrading automatically removed that service). There was never anything nefarious or advertising related, just some inexperience with Windows programming (the two of us that work on Sitala primarily come from macOS and Linux backgrounds).

That went away ... I think after the second alpha? Anyway, hasn't been the case for more than a year at least.

Great, thanks! Reaper has a pretty extensive (though a bit craptastic) API, so it makes deeper integration possible in a lot of ways. The things we have in the upcoming release are automatic multi-out routing, and synchronized track names (so the pad name is automatically reflected in the pad name). We already had note names working in Reaper in our last release. sitala-reaper-automatic-multi-out.mp4 The planned API doesn't do that at the moment, but interestingly, you don't need to have an extension to the VST API to do that. Reaper has a modifier that you can hold when dragging things like that that simply creates a temp file for a few seconds with that content. I even think it should be possible to simply correctly set the encoding of the dragged content to PCM and it should be possible to get it working without any real magic (just using normal desktop drag and drop protocols), but when I went spelunking a year or two back to see if any DAWs actually did that, I didn't find any. But that's something I'm open to exploring for future releases if we get more DAWs on board.

While that's something that we're definitely open to (and say so explicitly on our website), there's also a middle path: in a release that's coming out in a couple of days we've got tighter integration specifically with Reaper, and that's something that we're very open to expanding out to other DAWs. If there are any Cakewalk developers that happen to be reading this and find it interesting, please get in touch with us at info@decomposer.de. We've got an API that we're planning on opening soon that will make it possible for other hosts to integrate more deeply to Sitala (or any other plugin -- we're planning on open sourcing the code) that papers over a lot of the shortcomings of the VST format.

Yeah, I'd noticed that that was the default when we don't set a value (in the screenshot above I'm actually setting the names to a single space), and found that a bit ugly (note names would have been less so), but it's probably worth doing what the others do just for consistency. I assume that they (at least BFD3) have the same issue of things not updating in the step sequencer?