[FREE] ConvertWithMoss - convert from/to WAV,Bitwig,SFZ,SF2,DecentSampler,MPC/Force,Wave-/Modwave/KMP,NKI,EXS) v17.1

[audiojunkie]

Hey Jürgen, there is a new essential format that Convert With Moss needs—it will be an essential one: The Shortcircuit-XT read/write format. I think it’s going to end up being as popular as SFZ and SF2. You should be able to get the specs on the format from @Baconpaul of the Surge Synth Team (SST).

Hey, a question about this. Do Everyone, everyone on this thread/reading this, think that a binary format for ShortcircuitXT is enough or would it be great to have an xml/text format to make library build easier?
(Shortcircuit already supports two "xml" formats: SFZ & Multisample).
We at SST decided that a binary one is faster for load & write operation & as SC-XT is more than a sampler and contains a lot of synthesis, effects & mix parameters.
Maybe, instead of supporting the format, it could be a good idea to create a renderer to bounce to audio per keys/velocity.

The most important asset a sampler user has is the audio samples. Samplers come and go (and always will). But if you have access to the actual audio samples, you can load and use them in any future sampler that comes along. We want access to the samples. Having a monolithic format or having a xml format with a folder of samples is less important, as long as we can access the samples. If the monolithic format is just a zip file, that can be opened by anyone, then monolithic is fine. Otherwise, an xml file and a folder of samples is better. Access to the samples by anyone is the key here.

So, whether that is with a renderer or by some other means, if we have access to the samples (preferably including any synthesized parts and effects), and can convert to other formats, we (or at least “I”) will likely happy with whatever is chosen.

[Uncle E]

Hi Moss, I have an SF2 that keeps outputting noise when I try to convert to Kontakt using either 15 or 16.1.1. Would you be interested in checking it out? It's the only one having issues, I converted 59 other SF2's fine.

Yes, please. PM me the download link.

Thanks. Sent.

[moss]

Hi Moss, I have an SF2 that keeps outputting noise when I try to convert to Kontakt using either 15 or 16.1.1. Would you be interested in checking it out? It's the only one having issues, I converted 59 other SF2's fine.

Yes, please. PM me the download link.

Thanks. Sent.

Seems extracting 24-bit samples was broken. Will be fixed in the next update.

[Andreya_Autumn]

So about Shortcircuit XT. We have said before, and I will re-iterate here, that the format Shortcircuit saves in is not an open sample format like .sfz, .SF2, .multisample, decent etc. .scp and .scm are patch files for Shortcircuit XT itself, and are not intended to serve that purpose. This will not change.

If you are looking for something to serve that purpose, look amongst the aforementioned ones. Jürgen already knows that this is our position (from discussion with Paul, I'm told). But I thought I'd make it clear to other readers.

Now, which of the various formats is best suited to the task of "future-proofing" sample sets, trying to ensure you can load those in some other sampler 10 years from now, etc... That's a very important question and one we are sympathetic to! It just is not (and will not be) the question for which .scp and .scm files is the answer.

We do have an open issue to export as SFZ or other such formats though. So that's something we will probably do eventually. And we offer three save options for our own formats, with filesystem references to the samples, with samples collected in a new folder, or as a monolith. If your priority is accessing the samples you'd use one of the first two.

And if you want some hypothetical future sampler to be able to load not just the samples, but all the modulations and effects as well... Well either it would fail to do that accurately, or it would have to be Shortcircuit XT.
In the former case you're not getting the whole patch anyway, in which case may as well have used .multisample or something.
And in the latter case, well, you have Shortcircuit XT.

[moss]

So about Shortcircuit XT. We have said before, and I will re-iterate here, that the format Shortcircuit saves in is not an open sample format like .sfz, .SF2, .multisample, decent etc. .scp and .scm are patch files for Shortcircuit XT itself, and are not intended to serve that purpose. This will not change.

...

Hi Andreya,

first let me thank you for all the work you put into all the Surge plugins, very impressive!
Also thanks for chiming in and clarifying the position of the Surge Team.

While I highly respect that position, I still do not understand it. It feels quite strange that an open source project wants to keep their format closed, especially with bringing up the same argument of other sampler plugin manufacturers. And I have to admit that this dampened my enthusiasm for Shortcircuit somewhat (and I sadly heard the same from several other people).

Think about e.g. these things:
- If you need to go via another format (source->SFZ->Shortcircuit) you have a double conversion and likely will loose or screw up more parameters.
- If you convert one or more libraries you need to resave each and every preset individually in the native format (and also true for the other direction).

Would be great if the team would reconsider that position.

Cheers!

[audiojunkie]

So about Shortcircuit XT. We have said before, and I will re-iterate here, that the format Shortcircuit saves in is not an open sample format like .sfz, .SF2, .multisample, decent etc. .scp and .scm are patch files for Shortcircuit XT itself, and are not intended to serve that purpose. This will not change.

...

Hi Andreya,

first let me thank you for all the work you put into all the Surge plugins, very impressive!
Also thanks for chiming in and clarifying the position of the Surge Team.

While I highly respect that position, I still do not understand it. It feels quite strange that an open source project wants to keep their format closed, especially with bringing up the same argument of other sampler plugin manufacturers. And I have to admit that this dampened my enthusiasm for Shortcircuit somewhat (and I sadly heard the same from several other people).

Think about e.g. these things:
- If you need to go via another format (source->SFZ->Shortcircuit) you have a double conversion and likely will loose or screw up more parameters.
- If you convert one or more libraries you need to resave each and every preset individually in the native format (and also true for the other direction).

Would be great if the team would reconsider that position.

Cheers!

I agree 100%. It's almost in the anti-spirit of open source to try to dissuade the use of the format for sample conversion. I've found that strange from the beginning--it's been talked about openly for months by you guys. A closed format on an open sampler--it just doesn't make any sense.

I understand that you are saying this largely because of all of the synthesis stuff you've added. But the samples themselves should always remain accessible--even in monolithic patches. Also, as you've previously mentioned, the samples could be autosampled to get the full patch if needed. I don't understand the dissuasion.

[Andreya_Autumn]

Thanks both for the replies. And lemme be clear that I (and we) also really respect your work (both of you in your respective ways), and I understand how our stance may seem strange from your perspective.

Now, I guess I should not say "never" because it is not only up to me. Surge Synth Team is an open contribution project, anyone who is able to contribute and who is open to collaborative discussion can potentially have a say in what happens. In a hypothetical future where the current members have stepped back a bit and others stepped in... well who knows. But lemme try to shortly explain why this choice makes sense to us today.

Long story short: The project we set out to do is "building a creative sampler". Which (obviously) is different from the "develop and maintain a stable and future-proof sampler file format".

The former project has two important properties.
A: It feels fun and exciting to those of us who have been working on it. Might sound a bit elementary, but that's critically important to a volunteer project like this one. If it weren't fun we would've never gotten it to where it is now.

B: Seems like there is space for us to fill. There are other free and open source samplers of course, but not with this kind of feature set (extensive modulation/processing options, MPE and microtuning, eventually accessibility support, etc etc). This ties into A. When I see a message like "I'm glad this exists, thanks for making it" I feel happy to have helped someone else be happy! That's fun.


Those of us currently working on this project don't feel the same excitement about developing a stable sample format. Already as it stands now, one of the biggest threats to the project has been overambition. There are three of us doing most of the work (with a larger group of others contributing also) And we are, to put it lightly spread very very thin. At one point last year some of us almost gave up because the scope of it all was making it feel less fun. Thankfully we managed to pull back together (in some part because we did scale down on our ambition somewhat). But I think you understand why we are reluctant to take on the added complexity that designing and maintaining an open standard would entail.


And besides that danger, we also don't feel we can do the job of the open format better than Bitwig/Presonus have done with multisample. It looks to us like the problem is, if not solved, then at least in the process of being solved, and by people more invested in that question than we are. So we are happy to follow their lead and import (and eventually export) those other formats.

But you both know that already of course, and are not happy with that solution. This is where I in turn have to as you to help me understand something that I don't get: Why is that not good enough?

More specifically, I have heard two concerns: loss of the patch data besides the sample mapping itself, and the additional setup needed when transferring a sample patch from/to Shortcircuit.

The first one concerns things like modulations, effects, potentially special trig conditions, etc etc etc... But when would you need *all* of that information, except when loading your patch into Shortcircuit itself? Do you actually expect that some other sampler will exist which can match all of its features to the point where this data will actually be useful to transfer over?

As an example, one of the processors I've recently added (and which needs some tweaking still) is a kind of quad comb filter/resonator, with the combs tuned to one of a short list of 4-note chords (in any of 4 inversions, either in Just Intonation or standard equal temperament). Another one is a kind of flanger which uses the same base class but places the 4 combs on the unit circle of a cartesian plane where x=pitch y=pan. And then rotates them around that circle.

The individual building blocks of those procs are not new at all. But the way they're combined I have not seen anywhere else. What would some other sampler do with that information? Should other devs be expected to implement such effects in the future, so that this hypothetical open format can be opened with fidelity by their sampler also?

And similarly, about transferring between samplers, as you mentioned earlier. Is that not a reasonable expectation? Are earlier samplers actually similar enough that this "just works" beyond the mapping/sample playback features themselves (which are covered by sfz etc already)?

These questions might sound rhetorical which is not my intention at all. I just actually don't get it. Happy to try to understand though.

[Andreya_Autumn]

Geeze, that got long... Here's another perspective that might actually serve as a TL;DR:

Probably the most important "user journey" for us in developing SCXT goes something like this:
- Load a sample, or an sfz, sf2 etc
- Then expand on it with the creative tools inside processors, modulation, effects.
- Have fun while doing that

That's really the main thing that SCXT is designed for. Loading a pre-existing library, having it play correctly, and then not doing anything further with it, simply isn't the main goal. Doesn't mean we don't want to do it! We (or let's be real, mostly Paul) have spent considerable effort getting SFZ etc to import correctly. But it's not the primary purpose. Perhaps that also helps clarify the position.

[wikter]

Geeze, that got long... Here's another perspective that might actually serve as a TL;DR:

Probably the most important "user journey" for us in developing SCXT goes something like this:
- Load a sample, or an sfz, sf2 etc
- Then expand on it with the creative tools inside processors, modulation, effects.
- Have fun while doing that

That's really the main thing that SCXT is designed for. Loading a pre-existing library, having it play correctly, and then not doing anything further with it, simply isn't the main goal. Doesn't mean we don't want to do it! We (or let's be real, mostly Paul) have spent considerable effort getting SFZ etc to import correctly. But it's not the primary purpose. Perhaps that also helps clarify the position.

I think that the "export" to multisample/SFZ option should be considered although it would leave apart a lot of information on processing... But it's something to discuss on Discord.
My question here was about exporting an xml file, I already suggested that in the early alpha stage, but ED & Paul decided to put stakes on binary format. I'm not a huge fan of binary files, I prefer an XML to use any spreadsheet app to generate layers, settings that otherwise must be done slowly per layer on a keyb/mouse repeating job. That's how i view this, so i asked the question. Maybe... we should propose this to V1.1...

[Andreya_Autumn]

Yeah indeed, as noted above, export to a multisample format is a very reasonable thing that I bet we'll do.

As for the "generating layers without using keyboard and mouse" question. Xenakios had a similar question a while back, he wanted to do it programmatically whereas you wanted to use a spreadsheet.

Unless I've understood it wrong though, the information that you wish to generate is the sample mapping data, right? In which case it should work perfectly fine to generate any of the existing open formats. Which we already do a (no pun intended) decent job importing today (though there are surely edge bugs to squash still).

And if the data you want to generate is more than just mapping stuff. Well, a lot of effort went into making the UI easy and fun to use. We are still missing some multi-edit features (as you know Wikter) but will keep polishing it. I would certainly hope that when we are done, none of the features that are specific to Shortcircuit should be so tedious to set up that anyone would rather use a spreadsheet than the UI.

And again, if want to export extended info from SC for use elsewhere, then please help me understand what other sampler you expect to actually be able to use that info.

[baconpaul]

OK so quite a bit of confusion here, although Andreya's answer is correct. Let me try and add a few thoughs

1. Nothing about short circuit is closed. It's all open. Do whatever you want!
2. The format with which we save information is a transformation of our internal object model with versioned streaming changes. It's a document as a side effect of the object to stream mapping, not as a primary. There is no code which is 'write to json'(*).
3. For storage in the daw and in scp/scm we stream it as mgpack; but for interoperation between the ui and the back end we stream it as json.
4. The codes all there. Go for it. But if you are looking for a 'to-json' method you wont find it. Instead you will find c++ templates bound to objects which create something
5. You can see what it does. The developer menu will dump the engine state to json. You can read it. I use this to debug all the time.
6. That is tightly coupled with our version strategy
7. And the SCP/SCM includes this and a few other sections in a RIFF file

But here's the thing

1. Our version strategy is the C++ code. And it works great. But you would need to track that.
2. Since we serialize and unserialize objects we can make assumptions about out stream which are more robust and can simply hard fail if they aren't met.
3. If you ask me 'what's the json format for a zone', I honestly dont know. What happens when you run the code.

So thats a *bad* format. A format is documented with labels and syntax. Like SFZ, Decent, Multisample, etc....

I am certainly not going to sit here and say thats shortcircuit is that, and subsequently that it its appropriate for a sample format. Again, especially when SFZ, Decent, Multisample etc... already exist.

And if you come and ask me the question 'whats a json format for the zone' I reserve the right to laugh at you and point you to this message.

So is that a closed format? No. don't be silly. the code is all there. There's even a menu to show you the json in the tool.

But an open format isn't just 'you can read the code'. An open format is documented, with syntax, with support, and with the expectation that lots of tools will read and write it.

We have no intention of ever doing that with the short circuit object model.

Hope that clears things up.

(*) well actually there is code which is 'to_json' in patch_io.cpp but you know that already if you have read this far. The thing is it doesn't do what you expect. It passes a const & to the engine to a pile of template code.

[baconpaul]

I prefer an XML to use any spreadsheet app to generate layers, settings that otherwise must be done slowly per layer on a keyb/mouse repeating job.

Great!

Luckily

1. Multisample is XML
2. We read multisample

So you can do this today!

[Andreya_Autumn]

Ah, thanks Paul. That information is important also. I glossed over this, assuming at least you Jürgen already knows most of that (or are able to glean it from reading), since I know you know what you're doing. Better than me, certainly. So Paul's answer is clear about what the format is and is not. Mine is about why we would choose to design it that way.

Anyway, I'm serious when I say I want to understand the concern better. And genuinely hope my questions about it don't seem facetious. If there are concerns which align with the project goals and are not adequately addressed by what we're doing, we'd love to know.

[wikter]

I prefer an XML to use any spreadsheet app to generate layers, settings that otherwise must be done slowly per layer on a keyb/mouse repeating job.

Great!

Luckily

1. Multisample is XML
2. We read multisample

So you can do this today!

I just wanted to know what people thinks about the idea. I think it's be easy to create a bidirectional "translator", but i'm just curious about how people use & do.
For multisample mapping, Studio One has a great tool for mapping, and of course, i have some Calc sheets I did in 2001 when I multidampled every piece of hardware I got in the studio.

[baconpaul]

Writing imported from mapping formats to Shortcircuit *in the short circuit codebase* is actually pretty easy now. Claude would bang it out while I took a shower or made dinner honestly. But that’s a direct manipulation of the object model not a document to document translator

If there’s a format we don’t read we’re happy to consider it! We have an open issue for decent and support basics on others

But if you have a spreadsheet or xml you what not making it into sfz or multi sample is super easy with modern dev tools too. Happy to chat about other format imports