Daw Project Export Tool for Renoise 3.5+ (early state)

ffx · July 26, 2025, 8:52am

A very early state, kind of a scaffolding of a daw project export tool (and later import maybe) for the Renoise DAW, starting from version 3.5 and upwards.

Sadly I had to halt the development of this tool, due to API limitations, which would be easy to add, because everything already is implemented under the hood (just an assumption, I am not a Renoise core dev).

Working so far

Auto converts Renoise sample instruments into Redux instances, to make it loadable in the target DAW
Note data and song structure
Track automation data
Section naming
Track coloring and naming
Loads fine into Bitwig 5.3+ and Studio One 7.2+
You can also convert any sample instrument to Redux VST3 via context menu

Partly working so far

Track automation mapping, this only works so far, if the VST3 uses index as parameterID, e.g. Redux VST3. But most plugins won’t work, because they use unique parameter ids instead. The tool currently exports the index value.
VST3 preset export, read below
VST2 preset export using the VST2 info tool included (a workaround)

What’s missing / not implemented yet

Master track automation conversion
Any kind of pattern hex automation conversion
Redux macro device to instrument device automation conversion
polyphonic aftertouch
No idea why VST3 preset loading fails in Cubase 14+. Might be the preset data itself. As a workaround, load the exported dawproject into S1 and then again export as dawproject. Bitwig exports also fail to load in Cubase. S1 uses an uncompressed zip type.

This can’t work due to the API limitations

VST2/AU preset generation/export. Renoise does not provide any way to get the .fxp / .aupreset data. The device.active_preset data only contains the individual inline song data of the VST2 or AU plugin, assumingly different to VST3. This is already implemented in Renoise via “import preset…” and “export preset…”, just not made available in the API for unknown reasons.
VST3 preset export might be wonky, because it grabs the preset data from device.active_preset_data’s <ParameterChunk> node, assuming that this is simply the complete .vstpreset. But it might not be the case for every plugin…
parameterID mapping, so most automation won’t work, except for some VST3 plugins still using the index as parameter id (e.g. Redux VST3)
The correct VST2 plugin identifier can’t be set (an integer, which you see as “Unique ID” in the plugin info tooltip), since it is neither available in the API nor in device.active_preset_data, but required for VST2 preset loading
You can’t determine the target device of the “Instr. Automation Device” via API currently. Has to be done through a complete track search instead (so the device has to sit on the track where the instrument plays). That <LinkedInstrument> node is missing in the active_preset_data for some reason, if you access it via API (not copy-paste).
An import can only work for the song structure, but not for preset transferring, due to the same API limitations.

Song requirements

A song has to fulfill the following requirements for a working export:

Only one instrument per track! Use Fladd’s track splitter tool!
The Instr. Automation Device has to be placed onto the track where the target instrument is playing

Automatic workarounds

The tool can use a vst2info tool to extract the missing plugin infos, which I coded in Rust. There are pre-built binaries included in the /bin sub directory, pre-built for macOS (arm/intel ub2), windows x86_64, linux x86_64.

Manual workarounds

You can enable VST2 export, and then manually export each preset, overwrite the generated file(s) in the /tmp directory. And then use the “Repack .dawproject” menu entry.
Same for AudioUnit, but here you would also have to figure out the parameter ids and fix it in the project.xml (Search for “AuPlugin” and then the “Parameters” node, in here the parameterID attributes)
For most VST3 automation, you will have to figure out the parameter ids and fix it in the project.xml (Search for “Vst3Plugin” and then the “Parameters” node, in here the parameterID attributes). You can use another daw which exports dawproject, adding those parameters as automation first, and then look into that project.xml… Yes, very cumbersome…

How to build from source

macOS and Linux users use the ./build_for_mac_linux.sh script. Might need a chmod +x first. Windows users can test the same script, which should work in Windows 11 at least.

You can also decide to build a bunch of binary vst-tools that I’ve lamely coded in Rust.

These tools try to circumvent the current limitations of the Renoise API. The VST2 tool will give detailed infos for a given plugin path. If you want to use those via the tool settings, you will have to build these as first step with ./build_vst_tools.sh.

The tools require Rust / cargo to be installed on the system.

Feel free to contribute

Feel free to improve, try yourself, get in touch, and discuss it. Contact me, if you have questions or ideas.

I have tested this tool so far for macOS. However, it should theoretically also work for Windows and maybe even Linux. Please report back.

I’ve also tried to make the source code nicely readable. You know, this is important for team work, like proper function-, variable- and parameter-naming. The goal should be that a new developer can understand what’s going on on-the-fly. What is the method or object actually doing?

Suggestions for the API

renoise.DeviceParameter.plugin_parameter_id - int, unique VST3 parameter id provided by the plugin, is a simple index for VST2 (bei AudioUnit müsste es etwas ähnliches geben)

renoise.AudioDevice:export_active_preset(file_path) - saves the currently selected preset in plugin specific format, that is .vstpreset for VST3, .fxp for VST2, .aupreset for AudioUnit. Just as “export preset…”

renoise.InstrumentPluginDevice:export_active_preset(file_path) - saves the currently selected preset in plugin specific format, that is .vstpreset for VST3, .fxp for VST2, .aupreset for AudioUnit. Just as “export preset…”

renoise.AudioDevice:import_active_preset(file_path) - imports a plugin type format specific preset into the active preset. Just as “import preset…”

renoise.InstrumentPluginDevice:import_active_preset(file_path) - imports a plugin type format specific preset into the active preset. Just as “import preset…”

renoise.AudioDevice.unique_id - Just as “Unique ID” in the info tooltip. Renoise does not use it for VST2, instead it uses the plugin filename. But the actual ID is needed for the export.

renoise.InstrumentPluginDevice.unique_id - Just as “Unique ID” in the info tooltip. Renoise does not use it for VST2, instead it uses the plugin filename. But the actual ID is needed for the export.

renoise.AudioDevice.active_preset_data["LinkedInstrument"] - Also contains LinkedInstrument node for Instr. Automation Device

Uses the following libraries

JSON lua by RXI

xml2lua by Manoel Campos da Silva Filho, Paul Chakravarti

Also FancyStatus and ProcessSlicer.

License

Licensed under CC Attribution-NonCommercial-ShareAlike 4.0 International - Deed - Attribution-NonCommercial-ShareAlike 4.0 International - Creative Commons

Can be changed.

Download - Releases · Jurek-Raben/DawProject-Tool · GitHub

Source code - GitHub - Jurek-Raben/DawProject-Tool

Beatslaughter · July 26, 2025, 11:23am

For pattern commands you may be able to rip out some things from my following tool here, which can convert some pattern commands to envelopes, at least for those supporting it. Been 14 years though, so don’t ask me into too much detail what’s going on.

https://www.renoise.com/tools/copy-automation

If i’m not mistaken VST2 presets may be embedded in the song.xml as base64 encode.

ffx · July 26, 2025, 12:12pm

Hi, thanks for your suggestions! However, the Song.xml contains the exact same data as the data the tool is already grabbing from the device.active_preset_data. And this is a different data than actually required and provided via “export preset”. I have no idea if you also could make a valid .fxp preset file from that inline chunkdata, but it looks different content wise.

TB_Spectogram_V1 VST2 - preset data via “export preset” context menu (required for dawproject):

TB_Spectogram_V1 VST2 - inline song data via device.active_preset_data[Chunkdata] and via Song.xml (it’s the same):

I think there is no way to create a proper VST2 preset via the lua API currently. I assume the VST2, VST3 and AU plugin APIs provide functionality like “give inline data” and “give preset data”… Very unclear for me here. The solution is what I mentioned as suggestions for the API above. Plus no plugin identifier for VST2, and no magic string (“T1SG”) for the fxp either available.

spinesois · July 26, 2025, 3:12pm

Have you researched the fxp format? It seems fairly straightforward to chuck a binary header onto the Base64 data and get a valid fxp file. One possible reference: GitHub - CharlesHolbrow/vst2-preset-parser: vst2 .fxp and .fxb binary file parser for node.js

ffx · July 26, 2025, 3:16pm

Sure, I already thought about that, but Renoise API lacks of required info to create that header properly. Can’t create these guys:

Also there seems to be a difference in content for the actual content, see above. However, thanks for the feedback and link!

ffx · July 29, 2025, 5:40am

FYI: I’ve added now a github workflow, so with each merge into main, it should auto-build a release. Hopefully, you can now download the recent build directly from github (link in post #1).

I hope it will always add the last commit message of the merged branch to the release info text… But unsure here. Might be something like “merged Vx.y into main” instead

ffx · August 1, 2025, 12:42am

Criminal info

//-------------------------------------------------------------------------------------------------------
// VST Plug-Ins SDK
// Version 2.4		$Date: 2006/02/09 11:05:51 $
//
// Category     : VST 2.x Interfaces
// Filename     : vstfxstore.h
// Created by   : Steinberg Media Technologies
// Description  : Definition of Program (fxp) and Bank (fxb) structures
//
// � 2006, Steinberg Media Technologies, All Rights Reserved
//-------------------------------------------------------------------------------------------------------

#ifndef __vstfxstore__
#define __vstfxstore__

#ifndef __aeffect__
#include "aeffect.h"
#endif

//-------------------------------------------------------------------------------------------------------
/** Root chunk identifier for Programs (fxp) and Banks (fxb). */
#define cMagic				'CcnK'

/** Regular Program (fxp) identifier. */
#define fMagic				'FxCk'

/** Regular Bank (fxb) identifier. */
#define bankMagic			'FxBk'

/** Program (fxp) identifier for opaque chunk data. */
#define chunkPresetMagic	'FPCh'

/** Bank (fxb) identifier for opaque chunk data. */
#define chunkBankMagic		'FBCh'

/* 
	Note: The C data structures below are for illustration only. You can not read/write them directly.
	The byte order on disk of fxp and fxb files is Big Endian. You have to swap integer
	and floating-point values on Little Endian platforms (Windows, MacIntel)!
*/

//-------------------------------------------------------------------------------------------------------
/** Program (fxp) structure. */
//-------------------------------------------------------------------------------------------------------
struct fxProgram
{
//-------------------------------------------------------------------------------------------------------
	VstInt32 chunkMagic;		///< 'CcnK'
	VstInt32 byteSize;			///< size of this chunk, excl. magic + byteSize

	VstInt32 fxMagic;			///< 'FxCk' (regular) or 'FPCh' (opaque chunk)
	VstInt32 version;			///< format version (currently 1)
	VstInt32 fxID;				///< fx unique ID
	VstInt32 fxVersion;			///< fx version

	VstInt32 numParams;			///< number of parameters
	char prgName[28];			///< program name (null-terminated ASCII string)

	union
	{
		float params[1];		///< variable sized array with parameter values
		struct 
		{
			VstInt32 size;		///< size of program data
			char chunk[1];		///< variable sized array with opaque program data
		} data;					///< program chunk data
	} content;					///< program content depending on fxMagic
//-------------------------------------------------------------------------------------------------------
};

//-------------------------------------------------------------------------------------------------------
/** Bank (fxb) structure. */
//-------------------------------------------------------------------------------------------------------
struct fxBank
{
//-------------------------------------------------------------------------------------------------------
	VstInt32 chunkMagic;		///< 'CcnK'
	VstInt32 byteSize;			///< size of this chunk, excl. magic + byteSize

	VstInt32 fxMagic;			///< 'FxBk' (regular) or 'FBCh' (opaque chunk)
	VstInt32 version;			///< format version (1 or 2)
	VstInt32 fxID;				///< fx unique ID
	VstInt32 fxVersion;			///< fx version

	VstInt32 numPrograms;		///< number of programs

#if VST_2_4_EXTENSIONS
	VstInt32 currentProgram;	///< version 2: current program number
	char future[124];			///< reserved, should be zero
#else
	char future[128];			///< reserved, should be zero
#endif

	union
	{
		fxProgram programs[1];	///< variable number of programs
		struct
		{
			VstInt32 size;		///< size of bank data
			char chunk[1];		///< variable sized array with opaque bank data
		} data;					///< bank chunk data
	} content;					///< bank content depending on fxMagic
//-------------------------------------------------------------------------------------------------------
};

#endif // __vstfxstore__

Additional info

/**
 * A Vst2 Patch or Bank.
 * `.fxp` files will have a `.state64` string
 * `.fxp` files will have one of: `.patchParams` or `.patchChunk`
 * `.fxb` files will have one of: `.bankPatches` or `.bankChunk`
 * @typedef {Object} Vst2Preset
 * @property {string} fxMagic - one of: 'FxCk', 'FPCh', 'FxBk', 'FBCh'
 * @property {number} version - format version (typically 1)
 * @property {number} idUint - unique plugin id Number
 * @property {number} idString - unique plugin id as a string
 * @property {number} fxVersion -
 * @property {number} count - number of parameters (for FxCk patches). Number of programs (for FxBk banks)
 * @property {number[]} [patchParams] - all parameter values (for FxCk .fxp files)
 * @property {Buffer} [patchChunk] - binary state (for FPCh .fxp files)
 * @property {Vst2Preset[]} [bankPatches] - all patches in the bank (for FxBk .fxb files)
 * @property {Buffer} [bankChunk] - binary state (for FBCh .fxb files)
 * @property {string} [state64] - base64 encoded state (for all .fxp files)
 */

ffx · August 1, 2025, 7:51pm

Published v0.1.2 now, containing the following additions:

vst2 preset generation (.fxp) - read below
Added a vst2 info tool, which I coded in Rust, to extract the missing data from a plugin, e.g. unique identifier. Binaries for macOS, Windows and also Linux are included in the /bin dir inside the tool
Pitchbend, midi cc automation. Also fixed the plugin<->automation mapping

There still is something wrong with the vst2 preset generation. Even though you can manually load the generated .fxp files successfully into the fitting vst2 in a lot of cases (e.g. A1StereoControl), it does not seem to load automatically in S1 and Bitwig. The plugins are correctly loaded though.

Some vst2 fxp preset generation does not seem to work, this might be caused be the provided chunkdata in active_preset_data. For example fxps of tone boosters plugins look valid in the hex editor but simply load as init into the plugins. The chunkdata also is way bigger than the data which Renoise generates while an fxp export.

Maybe @taktik could give me a hint here what’s going on, why the chunkdata is so much bigger than exported data, after his break of course.

Next up I am trying to build a VST3 info tool Or taktik will be faster… Well, Rust actually is quite impressive. I can really easily build cross platform, it’s so modern, omg. The only not modern: For some reason it’s using snake case So I am learning Rust while building this tool.

Songs seem to load fine into Bitwig and S1, mostly with automation. Sometimes Bitwig shows an “unknown” automation lane. This is due to a VST3 plugin using parameter IDs instead the index, all the TB plugins for example. At least you can copy then the automation.

Generated fxp on the left, exported fxp on the right. Can’t find a difference (except 0x10 bytes longer). Must be another reason then. Maybe filenaming? Ah maybe the preset name! EDIT: fxp loading in Bitwig seems to be fixed for A1StereoTool, but not in S1…

spinesois · August 1, 2025, 11:34pm

I was bored so I tried to spot the difference: programName and OutputGain have different values.

ffx · August 1, 2025, 11:52pm

Thanks But that’s inside the chunk data, so it’s ok.

I’ve uploaded a new fix, so for now, bridged vst2 plugins won’t be exported, since my vst2info tool can’t check a vst cross-cpu-archtecture. I guess I will have to split the mac tool into x64 and arm, and then load each plugin as its architecture.

ffx · August 2, 2025, 8:19am

I`ve fixed it, so it now can use the info tool for bridged plugins (two separate builds). And added more coroutine.yield calls. It still can cause a warning modal due to long execution time, e.g. reading and converting huge parameter chunks of slow, bridged plugins seems to be a bottle neck. Just keep clicking on continue execution

I can export now quite complex songs and all tracks play in bitwig., including all vstpresets and most fxps. For some still unknown reason, the fxps do not load in studio one. It loads it’s own exported ones correctly. Can’t spot a difference… It’s all spec conform now as I can tell. Bitwig has a bug, if you directly export an imported dawproject, it will mess up the instruments. So this can’t be used as a workaround… I reported this bug months ago… Maybe it can be fixed if you move the instruments around, no idea.

ffx · August 4, 2025, 9:13pm

v0.1.5 - Added now a VST3 info tool. So far it only can readout VST3 fx, but not most VST3 instruments… But parameter id mapping for fx now works via the tool.

Can compile the tool for macos only… First check the tool setting, you might have to disable the vst3 info tool usage first. Should work on macos… Annoying, these workarounds…

This is the rust vst3 info tool: DawProject-Tool/vst3info-tool/src/main.rs at main · Jurek-Raben/DawProject-Tool · GitHub

It can load some instruments only, often gives a “seg fault”… I’ve ripped the code mostly from here: GitHub - HelgeSverre/rust-vst3-host

This tool has the same loading problems sadly…

ffx · August 5, 2025, 9:18am

Ok, I’ve found out that Studio One currently has multiple bugs when it comes to dawproject import/export and VST2:

While an import, preset is not loaded, even if it is a valid fxp format (even loads it correctly if done manually)
While an export, parameterIDs are incorrectly mapped for VST2s. Some “magic” id is used instead of the index (VST2 spec has no way to set a ID for a parameter)

I’ve tried to report these issues, but the support is quite annoying/not helpful and does not seem to understand normal words, or something. Let’s see…

ffx · August 7, 2025, 5:59pm

I’ve added AU preset and automation export. S1 currently seems to be buggy regarding AUs in dawproject files though. Hope they will come up with a fix. It was quite easy this time, since I simply could use the preinstalled command line tools auval and plutil.