Vember Audio Shortcircuit is now open source!

[audiojunkie]

I will just add that I do think that saving patches as a monolith is definitely super important for patch portability - self contained and no path resolving shenanigans regardless on which machine you load it. There is nothing wrong with monoliths as a concept, and so we should support that. Especially because the use case is so important.

It can just be a ZIP, though. No further complications.

If it’s just a zip, and the samples are accessible from a folder inside, I’m ok with that.

[audiojunkie]

* No other sampler in existence contains ALL of these features all at once! None!

HISE.

1. HISE is a developer too, and not usable ti normal users.

2. HISE is at best, a rompler. It is not designed to allow a user to build or import a sharable preset.

[audiojunkie]

...
I hope this explains my enthusiastic opinion.

That does make it a lot clearer yeah, thanks!

Like Paul said though, SCXT patch files will let you transfer sample instrument to other shortcircuit users, and Multi-Sample/Decent/sfz will let you transfer it to other samplers (without the glitch gate, oscillators, vowel EQ etc etc etc those samplers don't have). Again, like Paul said. Those formats are open (while you're right that their associated samplers aren't) and suitable for the purpose you have in mind here.

EvilDragon makes a good point about a simple monolith format. When I said we won't do it I was thinking of something encrypted indeed. An (uncompressed) zip with xml and samples is a good idea.

And also like Paul said, any C++ devs reading this are very welcome to join the effort! The team has grown a bit bigger which is exciting, but we certainly could use more hands still.

I’m ok with the zip concept. As long as the samples are easily accessible to any user, it should be ok—maybe even better.

[baconpaul]

Yes the source files when packed in will be easily accessible - it would be more work to encrypt them than not. But we already have the code to read and write zip files in the tool (which is how we read the bitwig multi sample files) and that seems more useful than directory structures on non macOS environments. (On macOS we could use bundles but that’s not portable)

[audiojunkie]

By the way, what is the current highest interpolation rate in SCXT?

It appears that you guys have (at least internally) are calling it SCXT these days.

[audiojunkie]

Also, as I understand it, and to be clear, you guys ARE planning on having export to SFZ and DSpreset. Correct?

That is what I am gathering from the posts above—that SCXT will export a subset of the SCXT format to the (extent capable, leaving out the synth parts that don’t exist in SFZ/DSpreset. Correct?

[baconpaul]

Also, as I understand it, and to be clear, you guys ARE planning on having export to SFZ and DSpreset. Correct?

That is what I am gathering from the posts above—that SCXT will export a subset of the SCXT format to the (extent capable, leaving out the synth parts that don’t exist in SFZ/DSpreset. Correct?

Yup and maybe multi sample too

[baconpaul]

By the way, what is the current highest interpolation rate in SCXT?

It appears that you guys have (at least internally) are calling it SCXT these days.

The tool has 16 and 32 bit amplitude paths and either 1x or 2x oversampling in time. The oversampling controls can be on the full pipeline in a group or dynamically toggled on just the sample render

[baconpaul]

And yes “scxt” is much easier to type than “ShortCircuit XT”

It’s also the namespace in c++ we used so it just kinda stuck

[audiojunkie]

By the way, what is the current highest interpolation rate in SCXT?

It appears that you guys have (at least internally) are calling it SCXT these days.

The tool has 16 and 32 bit amplitude paths and either 1x or 2x oversampling in time. The oversampling controls can be on the full pipeline in a group or dynamically toggled on just the sample render

I’m sorry, I don’t think I was being clear. I was referring to the sample transpose interpolation rate. For example, TAL-Sampler interpolates the sample when transposing the sample up or down a semitone with 8 point sinc interpolation. Bliss has a variable rate of up to 64 point sinc interpolation realtime, and up to 512 point sinc interpolation offline transpose quality. Most modern samplers these days use 128 point sinc interpolation for realtime transposition quality, which is a fair quantity vs performance tradeoff for today’s modern CPUs.

So, I’m curious about what quality of transposition algorithm is being used to transpose the samples per semitone.

[baconpaul]

Spatial reconstruction is done using a 12 point sinc window interpolated with a Taylor approx

https://github.com/surge-synthesizer/sh ... or.cpp#L87

[wikter]

Yes! I’m very excited! ….and hopeful.

But, let me explain my thinking a little better…

As far as true chromatic samplers go, there’s only a handful still in existence—which is beyond me why (but that is a digression for another time).

Of those, there are even fewer that remain with unencrypted formats with the samples available for long term future proofing—the worst thing in the world is to spend hours and hours on a sample set in a closed format, only for that sampler to be discontinued, and those samples lost.

Of the samplers that remain, with unencrypted formats, the most important ones are:

Sfizz
Decent Sampler
Linux Sampler
Tal-Sampler
TX16Wx
ShortCircuit-XT
Apple’s Sampler
Soundfont players

Well, there are other "propietary samplers" like the ones included in Studio One (Presence, Impact + Sampler) that can export samples in files that use ZIP compression and an XML descriptor (you can open the files exported with 7zip or any other app that supports ZIP).
Of course, the factory patches comes with encripted data, but you're free to resample & export those as unencrypted data (reading IP license is important here).

[baconpaul]

ones included in Studio One (Presence, Impact + Sampler) that can export samples in files that use ZIP compression and an XML descriptor

My understanding is that this zip + xml interchange format used by presonus and bitwig is the "multisample" format which is an open format documented here: https://github.com/bitwig/multisample

ShortCircuit can already read that format. In fact, I was able to play the bitwig stock samples in that format in SC just the other day! And some other tools I'm working on have been able to write it also so no reason SCXT won't be able to in the future. My comments above about "multisample" refer to that.

I don't have studio one but it would be interesting to see if SCXT (you need a very recent build - like last few days) can read any of the S1 sample packs which are zip files with th extension ".multisample"

[wikter]

ones included in Studio One (Presence, Impact + Sampler) that can export samples in files that use ZIP compression and an XML descriptor

My understanding is that this zip + xml interchange format used by presonus and bitwig is the "multisample" format which is an open format documented here: https://github.com/bitwig/multisample

ShortCircuit can already read that format. In fact, I was able to play the bitwig stock samples in that format in SC just the other day! And some other tools I'm working on have been able to write it also so no reason SCXT won't be able to in the future. My comments above about "multisample" refer to that.

I don't have studio one but it would be interesting to see if SCXT (you need a very recent build - like last few days) can read any of the S1 sample packs which are zip files with th extension ".multisample"

I own S1 V5, it can export those multisample files, i'll try to test it at home tonight.

[MorpherX]

1. The original SC2 has a sample replace feature (without deleting the other parameters)
Is this anyhow already implemented (have not found it) ?

2. How can I save a preset with the plugin version SC XT ?
I have not found found such a feature ?