Well this is a kick in the nuts: VST2 plug-ins

[mystran]

There's a lot of value in that. So unless there is another file standard that is also human readable and editable in a basic text editor, I vote for all my files to be in xml format!

Most of the popular alternatives like JSON are also human-readable plain-text and arguably even easier to edit as you don't need to worry about things like nesting tags correctly.

edit: For all intents and purposes among all the human-readable plain-text markup languages XML is the 2nd worst for both humans and computers alike. The only thing I can think of that's actually worse is SGML and guess what.. XML is a subset of SGML.

[Obsolete187521]

[DELETED]

[Music Engineer]

XML is the 2nd worst

and what would you recommend to use instead, i.e. what is the best? json?

[frizzbee]

yeah because JSON has no nesting...

[mystran]

XML is the 2nd worst

and what would you recommend to use instead, i.e. what is the best? json?

I don't think there's necessarily a "best" format, but JSON at least is very widely used, well documented and easy to implement. Basically the front page of json.org gives you the complete statemachines (well, very close at least) for parsing it as well as links to readily available implementations in just about every language you can imagine.

Also I hope I didn't give the impression that I think XML is somehow unworkable, rather I just tried to answer the question that was asked: why do people hate XML. Simple XML formats aren't that bad really, it's just that after you get exposed to things like XPath/XSLT (yes, people use these in the real world) you'll start wondering if it's really the best way to do things.

[Hanz Meyzer]

JSON is quite ok, extremely simple, too, a three year old kid could fill in the values here.

[mystran]

yeah because JSON has no nesting...

Ofcourse it does, but you only have to worry about choosing between '}' and ']' when closing a matching paren, instead of having to write </xsl:processing-instruction> where the probability of spelling errors is a whole lot higher.

[Urs]

I did do measurements across DAWs. None except Cubase separates GUI and Audio for VST3 at all.

Sure .. ever heard of AAX DSP, UAD plug-ins or Waves Soundgrid for example ?

Yet, AAX plug-ins are guaranteed to keep processing part and UI in the same process, even if part of the processing is distributed to an external platform (I guess they originally designed it for separation, but then haven't followed through). UAD plug-ins exist in VST2, which also guarantees that. Hence, I don't think separation between UI and processing part of the plug-in is necessary even if some/all of the workload is forked out onto a separate system.

Also be prepared for a few surprises with an x86 build of a plug-in running inside Logic on Apple Silicon .

I haven't noticed anything out of the ordinary. But then, in AU we do have a clean separation (not possible in VST3 for due to the design choices made on either side).

Audio/UI separation allows for other niceties such as exporting your plugin's UI on a touchscreen of some hardware control surface, or the other way round, a PC editor for some hardware like this.

If a host were to enable this, they'd probably be better off streaming the picture with a HW codec than dealing with the data transport from A to B and back that some modern plug-ins might require.

[syntonica]

I vote for all my files to be in xml format!

Or, you can just use a flat text file.

XML is a pain to parse, mostly because the vast majority of programmers don't use it correctly. It makes data files magnitudes larger than they need to be and its a pain to actually sit down and read. JSON is okay, but I never need my data nested. Both require you to either write your own parser, or pull in someone else's code which is usually over done, Linux-style.

My flat file parser loads and saves in under ~100 LOC, is quick and I can update it in minutes if required.

[lorcan]

I did do measurements across DAWs. None except Cubase separates GUI and Audio for VST3 at all.

Sure .. ever heard of AAX DSP, UAD plug-ins or Waves Soundgrid for example ?

Yet, AAX plug-ins are guaranteed to keep processing part and UI in the same process, even if part of the processing is distributed to an external platform (I guess they originally designed it for separation, but then haven't followed through). UAD plug-ins exist in VST2, which also guarantees that. Hence, I don't think separation between UI and processing part of the plug-in is necessary even if some/all of the workload is forked out onto a separate system.

Think about it, how would processing running on a Sharc DSP and a UI running on a Intel CPU would be 'guaranteed to run in the same process' ? They don't even share the same instruction set, memory space, etc.

Also be prepared for a few surprises with an x86 build of a plug-in running inside Logic on Apple Silicon .

I haven't noticed anything out of the ordinary. But then, in AU we do have a clean separation (not possible in VST3 for due to the design choices made on either side).

It's explicitly mentioned in the Apple porting guidelines not to share pointers between ARM/Intel parts, had you not done a clean separation, you would have witnessed quite a few things breaking.

Audio/UI separation allows for other niceties such as exporting your plugin's UI on a touchscreen of some hardware control surface, or the other way round, a PC editor for some hardware like this.

If a host were to enable this, they'd probably be better off streaming the picture with a HW codec than dealing with the data transport from A to B and back that some modern plug-ins might require.

I don't think you understood the idea. For example, imagine a bunch of low-cost efficient DSP boards running low-level code (maybe e.g. live FX) controlled by a 'dummy' plug-in inside a DAW whose only role is to send parameter changes / automation. Makes no sense to compute a UI in the DSP and stream it to the master DAW here.
The other way round, perhaps some sort of tablet on stage for remote hands-on operation of a PC or hardware rack. Something like the Avid S1 or NI Kontrol but with a 'real' animated plug-in UI.
Not to mention the write once, deploy to many platforms aspect.
And let's not forget UI/DSP synchronization issues which many happily ignore when direct communication is possible.

[Music Engineer]

I don't think there's necessarily a "best" format, but JSON at least is very widely used, well documented and easy to implement. [...] Simple XML formats aren't that bad really

ok, good to know. maybe i'll consider to transition to json someday. no top priority at the moment, though.

[Lind0n]

I don't think you understood the idea. For example, imagine a bunch of low-cost efficient DSP boards running low-level code (maybe e.g. live FX) controlled by a 'dummy' plug-in inside a DAW whose only role is to send parameter changes / automation. Makes no sense to compute a UI in the DSP and stream it to the master DAW here.
The other way round, perhaps some sort of tablet on stage for remote hands-on operation of a PC or hardware rack. Something like the Avid S1 or NI Kontrol but with a 'real' animated plug-in UI.
Not to mention the write once, deploy to many platforms aspect.
And let's not forget UI/DSP synchronization issues which many happily ignore when direct communication is possible.

Isn't this essentially what SOUL is trying to do?

[Markus Krause]

you could just use the Windows 10 remote desktop or similar networking tools for this purpose. It is free, works with any existing plugin on nearly any device.
but we're getting off-topic here

[Urs]

...

I don't know the guts and gizzards of TDM plug-ins, but native AAX plug-ins are still guaranteed to run UI in the same process as their (native) DSP part. UAD plug-ins still have a native DSP part which passes audio and data back and forth to their external DSP. They manage just fine without the separation of UI and (native) DSP part of a plug-in spec.

I even think that there's a reason that the vast majority of plug-ins shares data between UI and (native) DSP part. It is the complexity of the separation that developers would rather avoid. If you wanted to keep the number of plug-ins very low for a given format, you just need to enforce the strict separation of UI and (native) DSP part. I believe it's the single most effective way to make a plug-in format unsuccessful.

As for Rosetta, I think it would be awesome luck to find a plug-in that has its UI ported to Apple Silicon while the DSP part is left behind on Intel, or vice versa.

As for dummy plug-ins, I might not quite understand what you mean.

[rafa1981]

To add to the XML bikeshedding, yes, I hate it too for configuration files. Storing program configuration in a Markup Language for me is a smell of enterprisey software and I have to work against my own biases to judge such program fairly instead of being thrown-off with that small detail.

IMO XML's main purpose is to mark unstructured text/documents, not configuration files or data exchange. 99% of the time you are covered with just flat key-values, an "ini" file or JSON.