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

[audiojunkie]

My concern with it all, was that "it seemed" that you guys were against the format being added to ConvertWithMoss. Now, after BaconPaul's comments, I think it is more clear. It's not that you are against the format being added to ConvertWithMoss, it's that you aren't interested in actually doing the conversion work. That is fine. I don't have a problem with that. I don't think anyone was expecting the Surge Synth Team to do any of it. I just felt that it was strange that you guys "seemed" to be against the idea, which seemed to be strange considering it was open source.

[baconpaul]

It's not that. It's just I don't think you can make it work. And odds are you will generate an invalid document.

It's a bad idea. You shouldn't do it. If we get bug reports for documents made with something other than short circuit we will close them. And there's no guarantee that we won't change things (but will retain streaming compatibility with valid past documents).

But we can't stop you.

[moss]

Thanks to the whole Surge Team for chiming in and explaining your thoughts! And yes, that is what I also understood so far.

As Paul explained, object streaming/serialization is nearly impossible to reengineer (even with the code available) since it depends on implementation details of the language itself. I only ran into such a choice once with the Maschine 1 format (they used Boost, and even as Boost clearly states not to use this for production code and it might not even be compatible across platforms). Therefore, even if this is easy to implement (while other formats like a plain XML are even simpler) it is very problematic for compatibility. If the software becomes unavailable in the future for whatever reason you are stuck with it (I had to deal with such things in my business life).

Another thing I forgot to mention are multis. None of the other exchange format (SFZ, multisample...) does support multi-setups only single sounds.

As I said, I highly respect all your decisions and the reasons behind them but maybe if more time is available in the future and the dust has setteled, it would be great if you could reconsider a more open format.

Cheers!

[baconpaul]

So I don't even know what 'a more open format' means. And thinking about this overnight I think there's another way to explain it

A short circuit session contains three things. it contains an engine, a sample manager, and a patch object model. A sample manager is a list of samples referenced by the patch object model. A patch object model is a collection of C++ objects which represent the full feature set. The role of the engine is to consume a patch and sample manager and run the appropriate DSP to make the outputs based on MIDI etc... inputs.

To author a short circuit configuration we have three tools

1. The C++ API. This is open source code, available under the MIT license, which you can fork, copy, use, etc...
2. A UI which uses that C++ API.
3. A set of other tools which use the C++ api to manipulate the objects. If you've read the source I'm sure you've seen them in clients/cli-tools. But they the API from 1 just like the UI does

Now since people want to save the session etc.... the sample manager and patch object model have the feature that they can serialize and de-serialize themselves. This resulting binary stream (which can be json or msg pack) is a *result* of the object model though not an *interface* to it. We then store that stream in the DAW state in plugin contexts or in a RIFF file for .scp/.scm. More over scp/scm can add samples to the RIFF file, or it can modify the sample manager to have relative paths and re-point and collect the samples.

So we *have* an open format. That C++ api. Go for it! But we don't have an open document format. The documents are a side effect of the primary api.

And I don't see why we would invest in one. There's already substantially lower resolution ones available which we can import from and export to. (I added a very rudimentary SFZ export last night for instance). But that's never going to be as expressive as the full runtime model.

So my question to you, @moss, is why do you even *want* a document intermediation to the content. What is it you would do with it? Like, what would you do with a group where one zone had the sine-plus oscillator pumped into a network of non-linear filters, and the other overlapping zone had 13 variants into a tetrad resonator. You can get a json representation of that now (menu/developer/dump JSON for part, then look in the log from menu/show log) but other than the geometry you cant do anything with that in any other sampler.

So think of short circuit session like an ardour session file, or falcon, alchemy, tal-sampler, halion, serum2, etc.... just with an open api to the entire object model available to you, for free, in the code base.

[Andreya_Autumn]

And thank you both for the respectful engagement!

So, here's what I gather:
- Your aim is convenience and future-proofing.
- The user journey is basically "transfer a Shortcircuit XT part/multi into another sampler".
- And the goal is to have that load preserve as much of the behavior of the part/multi as possible.

Feel free to fill me in if I've missed something, but that's basically it right?

And that all makes sense. I am also sensing under the surface that there is a history of painful experiences here with lovely creative tools rendered missing or broken by software updates, company closures etc. And I deeply empathize with that.

Here's an example of what I think you might be missing though: Get this one small file from our factory content (the ... top right has a download button): https://github.com/surge-synthesizer/sh ... 20Bass.scp

No obligation of course, so I'll put it in words:
That scp uses no samples at all (but it could, of course).
It makes a bass sound out of two full-range overlapping zones, one stereo one in mono. Each one has an oscillator in it, one has a bank of Allpass filters with feedback (with some stereo modulation), etc etc... some of these features are uncommon even in bigger synthesizer plugins.

So. In the scenario of your concern - someone wants to convert Shortcircuit patches into something else - what should happen to that beta bass patch?
When they load that patch into some other hypothetical sampler, what sound can they reasonably expect to hear?

Again, we're empathetic to the goals above, and if we believed that they were attainable with the strategy you favor (or any) I think we would consider it. It's just that:
- A: Lossless patch transfer from SCXT to some other sampler seems very very very far-fetched.
- B: Non-far-fetched (near-fetched? ) patch transfer would reasonably omit all those hyper-specific features, and focus on the sample mapping, amp envelopes, velocity sens, keyswitches etc etc... The standard sampler features.

A doesn't seem tenable, and B is already served really well by the existing formats (which again, we're happy to export to).

Hope that helps.

[baconpaul]

100%. Only thing I will add is: if your goal is future proofing there are few better strategies than having the entire source tree

Even if we did make an open format it could be abandoned. Having an html document about a tag is less useful than a runtime in that case.

[audiojunkie]

You mention that you’ll add SFZ export. How would you go about exporting the complete sound? Resample the output?

[Sascha Franck]

I've got a question regarding ConvertWithMoss: Is there any option I'm overlooking that would allow me to only save a patch file but not the samples? I mean, what I see myself using it for so far is to convert some EXS patches to other formats - and the required samples already exist as plain files, so I see no need for them to be doubled, the target sampler would only have to relocate them.

[baconpaul]

You mention that you’ll add SFZ export. How would you go about exporting the complete sound? Resample the output?

you wont get the complete sound. sfz doesn't have the complete sound. the way to get the complete sound is to run the engine.

if you want to resample the output, like with a samplebot pro or something, that's a different thing, but also freezes modulators, randoms etc...

how would you go about exporting the complete sound from surge?

[audiojunkie]

You mention that you’ll add SFZ export. How would you go about exporting the complete sound? Resample the output?

you wont get the complete sound. sfz doesn't have the complete sound. the way to get the complete sound is to run the engine.

if you want to resample the output, like with a samplebot pro or something, that's a different thing, but also freezes modulators, randoms etc...

how would you go about exporting the complete sound from surge?

That was what I was asking you. As far as modulators go, one would need to have the sample long enough to capture a sufficient cycle of the modulation. It could be a large file. Gigasampler introduced us all to the world of multi-gigabyte-sized libraries and direct-from-disk streaming. It seems clear that an Autosampler-type solution is what will be needed—not that you guys will be expected to develop it or anything.

Edit: And loop points wouldn’t be as needed in a case like that either. Most songs average 3.5 minutes. It is not often that a single sound will play one note throughout the whole song—verse, chorus, and bridge. Likely, you could sufficiently sample 30 seconds per every third, and get a sufficient recreation of the patch. I know a guy that does every note for one minute each, but I think that’s overkill. It does seem, unfortunately that all of this does indeed dampen my enthusiasm about the potential of Shortcircuit. It was designed as a hybrid—a synth with sampling capabilities. I would have rather it had been ONLY a sampler. I think adding the synth capability somewhat ruined the potential of the app as the open sampler of the future. Because of the synth add on stuff, it has become a closed format like Halion or Falcon. Also, this still leaves the world without an open sampler format that can create instruments with a GUI. TX16Wx is the closest we’ve got, and its format is open and good, but the tool itself requires challenge response copy protection, and it’s developed by a single person that at some point will end his business. It’s a short term solution at best.

I appreciate the hard work the Surge Synth team has done with Shortcircuit. You guys have nearly killed yourselves off with building it. I’m absolutely certain people will use and enjoy it! Unfortunately, though, for me, it won’t be serving the purpose in my toolbox that I really need and want.

[moss]

I am afraid I cannot add anything meaningful to the Shortcircuit format discussion. Therefore, I suggest to move it to the Shortcircuit Discord if necessary.

[moss]

I've got a question regarding ConvertWithMoss: Is there any option I'm overlooking that would allow me to only save a patch file but not the samples? I mean, what I see myself using it for so far is to convert some EXS patches to other formats - and the required samples already exist as plain files, so I see no need for them to be doubled, the target sampler would only have to relocate them.

Sorry, no.

[audiojunkie]

I am afraid I cannot add anything meaningful to the Shortcircuit format discussion. Therefore, I suggest to move it to the Shortcircuit Discord if necessary.

Agreed.

[baconpaul]

Yeah especially now it is clear Audiojunkie basically wants “sfizz or sforzando with a gui editor” which isn’t at all what Shortcircuit ever was or was ever intended to be, I see why the confusion arises. Thanks for letting us accidentally hijack your thread for a while!

[moss]

Yeah especially now it is clear Audiojunkie basically wants “sfizz or sforzando with a gui editor” which isn’t at all what Shortcircuit ever was or was ever intended to be, I see why the confusion arises. Thanks for letting us accidentally hijack your thread for a while!

Which would actually be a nice thing to have No worries and keep up the good work!