Vember Audio Shortcircuit is now open source!

[Halonmusic]

This synthesizer is just out of this world. I have been having so much fun making pathes in it. Just wow! I am sure Shortcircuit will be just as awesome! Fantastic work!

[melomood]

Whatever can brighten up those musty of sfz's. The more the merrier. Looking forward to looking forward & reading the incrementals along the way

[andony]

Surge XT already replaced all my free synths. Can´t wait for Shortcircuit XT to be my only sampler.

[yzcoruhT]

Indeed. It is great synth. I can't wait for updated Surge XT FX with resizable GUI.

[mccy]

Oh, wow, this will be hughe!

[melomood]

Sending love and some toasty good karma your way

[LFO8]

Edit; sorry wrong thread

[audiojunkie]

Does anyone know if ShortCircuit-XT's presets will still be using the .SCM extension? Also, where can one find the sampler's preset format specifications? I'd like to see if the file format can be added to a couple of format converters. And a final question: Does anyone know if ShortCircuit saves presets as monolithic files or if the WAV files are accessible from a folder like .SFZ, .DSPreset, .Talsmpl, and the .tga formats can do? Thank you to whoever it is that knows the answers to these questions!!

[Andreya_Autumn]

As of today, the early alpha can (very minimally) load .sfz, bitwig multisample and .sf2, plus some single file formats. It can save nothing at all. Adding anything of ours to a format converter is months away.

We haven't made any final decisions on what the format will be, but I very much doubt we'll do a monolithic one. The internal messaging from UI to engine is JSON, so most likely the file format will ultimately be any file that can hold said JSON info (possibly .fxp like Surge) + a folder of samples. But this is still TBD.

Also worth mentioning: one of the design goals is "more personal sampler than library sampler". Meaning it's more geared towards creative sample manipulation than loading large sample libraries. Like I understand SC1 also was. With that being said, we will have some support for the latter use case also. And of course, we want it to be possible to share patches.

[audiojunkie]

Thanks for the quick response! And also thanks for the update!

I agree completely that ShortCircuit-XT should not be monolithic. Monolithic and encrypted are things the proprietary companies do to lock everyone out of accessing the samples.

I understand that the design goals are not to be a replacement for a library sampler, but at the same time, there is no other sampler in the open source world that can handle large files and yet still has an accessible interface with ADSR, modulation, and such. It will undeniably be many users main sampler. Without the text coding know-how, non-technical musicians will not be able to access important functionality such as the afore mentioned ADSR, modulation, LFOs, etc. from Sfizz, LinuxSamper, Decent Sampler, etc. So it will be important for ShortCircuit-XT to be able to access and use reasonably large sized presets, even if they aren't the 20Gb - 80Gb sized libraries that come with Kontakt. I would imagine that it would be reasonable to be able to access presets up to 3Gb on ShortCircuit-XT without direct to disk functionality (which I still hope someday you guys will reconsider and add). At any rate, I hope you'll keep that in mind.

[Andreya_Autumn]

Makes sense.

Modulation, FX, etc are already working quite well, and indeed through a GUI!

Not to worry. It's already possible to load decently large sets of samples, though the UI/UX/workflow in that scenario needs work still. Indeed there's no direct-from-disk streaming currently, but this has in fact been discussed for the future, it's just not a high priority before 1.0.

I also wouldn't worry about conversion honestly. Shortcircuit itself will take in common sample formats and at least parse the sample mapping so you can get a starting point. Then you can setup modulations/fx/etc and save. No need for a converter really, I guess? As I said, the first part already kinda works today.

[audiojunkie]

I’m glad it will support large samples and DFD. I don’t know if people are aware of it or not, but ShortCircuit-XT is the most important and game-changing open plugin to come along in 20 years! Think of it: A full featured, modern, open source sampler with a good GUI and an interchangeable format, where the waves are not encrypted and the samples are not unavailable. The GUI allows even the most technically uneducated to create presets. This bypasses the GUI-less failings of .sfz, and even .dspreset. It supports modern features that .sf2 doesn’t. It’s available to everyone, without cost—unlike .talsmpl and .tga. Done properly, the ShortCircuit-XT sampler format WILL BE the defacto standard sampler format that every other sampler will have a a supported import format. Every other sampler in the world will have to be so much better, and offer so much more, because otherwise, there will be no point in its existence. It will be the baseline upon which every other sampler will be compared.

There will still be commercial competitors, but they will have to find ways to innovate beyond ShortCircuit-XT’s capabilities in order to do so. It is not outside of the realm of believability for the cliched, overused term, “game-changer” to be used in this case.

I suspect most people don’t realize the importance of this project.

[Andreya_Autumn]

Hehe... I'm glad you're excited and we are too!

I think the prediction that our format becomes a standard is a bit of a stretch though. Not every sampler today needs to reach feature parity with existing options to justify its existence. At the very least, there's room for smaller and/or more niche ones things. And that'll still be true when SCXT is done.

And honestly I expect Sforzando, Decent Sampler et al. to more or less retain their relevance thereafter. Lots of folks just want to load up a sample instrument and go, for which purpose SCXT is absolutely overkill.

Same for the main commercial library samplers (Kontakt, Falcon, Spitfire, Vienna Synchron etc etc). Their main selling point is commercial-grade sample libraries. Such libraries cost €€€ to produce that the FOSS community typically don't have, and will have the same commercial value once SCXT is out (even if the aforementioned players lack some of SC's features).

We're not really looking to replace or compete with anything else that's out there currently. You've hit the nail on the head when you say nothing quite like it exists yet (though I reckon TAL is the closest), we're going in a pretty empty niche. And with all that in mind, it doesn't seem that important to me to save a format that's adoptable by other samplers. Said samplers would have to be going for feature-parity with us (==implement lots of niche stuff) in order for that to be reasonable. We're open source so they'd be free and welcome to, of course. But why'd they do that when SC already exists? So again, I'm guessing we'll end up going for a SCXT-specific .fxp with sample paths, not something we'd expect others to load directly.

But hey, I could be wrong, and these are my thoughts and not the whole team's. We'll see how it turns out. Either way thanks for raising the concern!

[baconpaul]

I love your enthusiasm and continual support of our projects audiojunkie!

But I also agree with Andreya! Our goal is definitely to have a fantastic instrument which supports loads of unique features. But the 'format' we are using to stream the internal state is, by design, closely tied to that internal state. You will certainly have files you can share which SCXT will load, but they would be pretty inscrutable to other synths and, most importantly, we don't want to have the burden of 'streaming format' maintenance beyond doing it at load time.

We instead have import from sfz, sf2, and the open bitwig/presonus multisample (which works today) and will almost definitely have a (fidelity reducing) export to those formats also (and maybe to decent also).

And I say fidelity reducing because, as Andrea points out, there are going to be some things SCXT does which isn't really a standard, it's a feature. I'm (right now - or would be right now if I wasn't typing on KVR instead ) working on the inline zone and group processors and, for instance, the weird custom pitch shifting / phasing / modulating thingy we have is certainly not something you'd expect in sfizz or decent or so on.

But anyway I do agree it is a cool and exciting project, and we have some other adjacent ideas for sample-initiated synthesis which will complement it will this year. But we aren't designing an interchange format. Just another fun and cool open source instrument, which in this case starts with a sample.

[baconpaul]

Oh and to your first question

The way we are serializing everything is using https://github.com/taocpp/json taocpp's excellent json library to serialize our c++ objects directly (with versioning etc...) to either JSON or msgpack files. When we finally do 'save a part as a patch' or 'save a synth state as a multi' my guess is we will use something akin to decent or multisample, namely, the json or msgpack file with a well defined name in a directory and either references to files which have to be resolved on load or files in a subdirectory. We will probably also, like both decent and bitwig/presonus, allow that to be zipped into a single file so zip would let you get the individual files out.

Bit that json or msgpack file will not be anything other than 'streamed internal state'. Certainly not 'interchange format'. That's what the (unimplemented) exporters are for. (And they are in the milestone)