Old 10-29-2009, 01:57 AM   #1
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,417
Default Definition of RPP format?

Is the RPP format defined somewhere?

I am writing a small app to parse RPP-files, and I could reverse engineer the format, but if a definition is already available I'd rather use that.

So, is there...?
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 10-29-2009, 02:34 AM   #2
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Fabian View Post
Is the RPP format defined somewhere?

I am writing a small app to parse RPP-files, and I could reverse engineer the format, but if a definition is already available I'd rather use that.

So, is there...?
No, there isn't, as far as I know. The format is quite straightforward to parse structurally however. If you have some particular issue with some aspect of the format, just ask, someone will probably know.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 10-29-2009, 03:26 AM   #3
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by Fabian View Post
Is the RPP format defined somewhere?

I am writing a small app to parse RPP-files, and I could reverse engineer the format, but if a definition is already available I'd rather use that.

So, is there...?
No, there isn't, as far as I know. The format is quite straightforward to parse structurally however. If you have some particular issue with some aspect of the format, just ask, someone will probably know.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 10-29-2009, 04:58 AM   #4
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,417
Default

Quote:
Originally Posted by Xenakios View Post
No, there isn't, as far as I know. The format is quite straightforward to parse structurally however. If you have some particular issue with some aspect of the format, just ask, someone will probably know.
OK, thanks, Xen.

Yes, the format is quite straightforward, I just thought that there would/could/should be a formal definition somewhere. I have no specific issues, as yet, and I'll sure call for help if I stumble on something.

Thanks again.

And again (for your double reply)
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 10-29-2009, 05:06 AM   #5
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,417
Default OK, first issue...

The .RPP file begins

Code:
<REAPER_PROJECT 0.1
  <NOTES 0
    |Just a simple test project with project notes.
    |How are newlines encoded?
  >
What does the zero after "NOTES" mean?
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 10-29-2009, 11:45 AM   #6
sws
Code Monkey
 
sws's Avatar
 
Join Date: Sep 2007
Location: Madison, WI
Posts: 857
Default

Quote:
Originally Posted by Fabian View Post
The .RPP file begins

Code:
<REAPER_PROJECT 0.1
  <NOTES 0
    |Just a simple test project with project notes.
    |How are newlines encoded?
  >
What does the zero after "NOTES" mean?
The zero is the state of the check box "Show project notes on load." 1 means yes, 0 means no.
sws is offline   Reply With Quote
Old 10-29-2009, 01:39 PM   #7
Fabian
Human being with feelings
 
Fabian's Avatar
 
Join Date: Sep 2008
Location: Sweden
Posts: 7,417
Default

Quote:
Originally Posted by sws View Post
The zero is the state of the check box "Show project notes on load." 1 means yes, 0 means no.
Thanks.
Great, we're already on our way to write a definition of the RPP format
__________________
// MVHMF
I never always did the right thing, but all I did wasn't wrong...
Fabian is offline   Reply With Quote
Old 10-29-2009, 01:44 PM   #8
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

yeah, subscribed!
I think that Runaway (AATranslator) could say many things about that...
Jeffos is offline   Reply With Quote
Old 10-29-2009, 10:23 PM   #9
Runaway
Human being with feelings
 
Runaway's Avatar
 
Join Date: Jun 2009
Location: Sydney, Australia
Posts: 2,510
Default

Quote:
Originally Posted by Jeffos View Post
yeah, subscribed!
I think that Runaway (AATranslator) could say many things about that...
Damn dobbed in again! :-)

I'm probably the worst person in the world when it comes to documentation (actually writing specs etc and following them) but in the absence of an expert I'm happy to help (anything to distract me from this OMF2 conversion).

Mind you I didn't know about the 'notes' thing but that was outside the scope of what I needed to look at.
__________________
AATranslator
Runaway is offline   Reply With Quote
Old 10-01-2010, 01:59 AM   #10
fredv
Human being with feelings
 
Join Date: Dec 2008
Posts: 78
Default

Hi,

maybe i haven't found the right place, but is there any document written since 2009 about RPP format ?

I have especially questions about the VST big blocks of codes, what is it exactly ? binary data serialized ? does it show status of VST plugins ?

Thanks
fredv is offline   Reply With Quote
Old 10-01-2010, 04:06 AM   #11
Runaway
Human being with feelings
 
Runaway's Avatar
 
Join Date: Jun 2009
Location: Sydney, Australia
Posts: 2,510
Default

Not that I'm aware of but ask if you need something explained and someone here will surely reply
__________________
AATranslator
Runaway is offline   Reply With Quote
Old 10-01-2010, 07:36 AM   #12
fredv
Human being with feelings
 
Join Date: Dec 2008
Posts: 78
Default

I would have loved to know what those meant :

<VST "VST: ReaEQ (Cockos)" "reaeq.dll" 0 ""
cWVlcu5e7f4CAAAAAQAAAAAAAAACAAAAAAAAAAIAAAABAAAAAA AAAA==
AgAAAAAAAACYAAAAAQAAAAAAAAAgAAAABAAAAAAAAAABAAAAn/glkw==
mItYQMwrbSvCtdQ/AAAAAAAAAEACAAAAAQAAAGHEdkEHxXRAIzgcPA==
s/7hPwAAAAAAAABAAgAAAAEAAACrC7qaaYrDQF5rzePgtgBAAAAA AA==
AAAAQAEAAAABAAAAcsVVZLwOlUAFR1Qc1XP8PwAAAAAAAABAAQ AAAA==
AQAAAAAAAAAAAPA/
>

How is it made ? i suppose these are binary configuration of VST plugins but how you convert that to these fields ?

Thanks
fredv is offline   Reply With Quote
Old 10-01-2010, 08:10 AM   #13
sws
Code Monkey
 
sws's Avatar
 
Join Date: Sep 2007
Location: Madison, WI
Posts: 857
Default

They're Base64 encodings of the VST plugin's save state. (So yes, serialized binary data.) The content of the save state is plugin-specific. You could probably decode some simple plugin's state by making a change and seeing what happens. See projectcontext.cpp in WDL for example Base64 encode/decode functions.

<edit> I should be a little more specific for your example:
The first line, <VST "VST: ReaEQ (Cockos)" "reaeq.dll" 0 "", should be self explanatory.
The next 6 lines are the Base64 data. Decode for raw binary.
> closes the <VST block.
sws is offline   Reply With Quote
Old 11-14-2014, 01:26 AM   #14
AllWeasel
Human being with feelings
 
Join Date: Nov 2014
Posts: 3
Default

First, let me apologize for waking an old thread. I did try to google and search the forums, but had no luck elsewhere.

I'm coding a 3rd party app that helps automagically re-organize the way Reaper stores things (willy-nilly) by default. A small part of that is being able to make changes to the rpp files now and then. I ran across this line in a Reaper project:

RECORD_PATH "Media-Files" ""

Now, the "Media-Files" part is just the default record path that I've set, but I'm a bit puzzled by the second (empty) quoted string. Can someone tell me what might be saved in that second string so I don't overwrite something important?

Thanks in advance.
AllWeasel is offline   Reply With Quote
Old 11-14-2014, 02:07 AM   #15
DarkStar
Human being with feelings
 
DarkStar's Avatar
 
Join Date: May 2006
Location: Surrey, UK
Posts: 19,677
Default

Most of mine are similar.

A few say .. RECORD_PATH "media"
or even ..... RECORD_PATH ""
__________________
DarkStar ... interesting, if true. . . . Inspired by ...
DarkStar is offline   Reply With Quote
Old 11-14-2014, 04:05 PM   #16
IXix
Human being with feelings
 
Join Date: Jan 2007
Location: mcr:uk
Posts: 3,889
Default

I suspect the empty string is probably the "secondary record path".
IXix is offline   Reply With Quote
Old 11-16-2014, 02:46 AM   #17
AllWeasel
Human being with feelings
 
Join Date: Nov 2014
Posts: 3
Default

Ok, I'll bite. Where in the option menu can I find that one? I tried searching for it, but had no luck. I suspect it's called something else, but I can't find it. Any help is appreciated.
AllWeasel is offline   Reply With Quote
Old 11-16-2014, 02:57 AM   #18
DarkStar
Human being with feelings
 
DarkStar's Avatar
 
Join Date: May 2006
Location: Surrey, UK
Posts: 19,677
Default

@ IXix - good point (never used it here )

@ AllWeasel - in Project Settings
__________________
DarkStar ... interesting, if true. . . . Inspired by ...
DarkStar is offline   Reply With Quote
Old 11-16-2014, 03:00 AM   #19
Dannii
Human being with feelings
 
Dannii's Avatar
 
Join Date: Mar 2010
Location: Adelaide, South Australia (originally from Geelong)
Posts: 5,598
Default

Quote:
Originally Posted by AllWeasel View Post
Ok, I'll bite. Where in the option menu can I find that one? I tried searching for it, but had no luck. I suspect it's called something else, but I can't find it. Any help is appreciated.
Open project - press Alt+Enter (project settings) - media tab.
__________________
Dannii is offline   Reply With Quote
Old 11-16-2014, 03:01 AM   #20
Dannii
Human being with feelings
 
Dannii's Avatar
 
Join Date: Mar 2010
Location: Adelaide, South Australia (originally from Geelong)
Posts: 5,598
Default

Quote:
Originally Posted by DarkStar View Post
@ IXix - good point (never used it here )

@ AllWeasel - in Project Settings
Looks like we were posting at the same time. You beat me to it.
__________________
Dannii is offline   Reply With Quote
Old 11-16-2014, 03:07 AM   #21
AllWeasel
Human being with feelings
 
Join Date: Nov 2014
Posts: 3
Default

Hah! Not the preferences-->project settings, but the "Project settings"-->Media tab!

And you kind folks are absolutely correct. I confirmed that is the second string on that line.

Thanks for the info. Happy mixing!
AllWeasel is offline   Reply With Quote
Old 12-26-2015, 06:13 AM   #22
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by sws View Post
They're Base64 encodings of the VST plugin's save state. (So yes, serialized binary data.)
I just checked that the preset name for a plugin's parameter set definition also is stored here.

I would love to be able to see the complete parameter information saved in theses sections.

Did anybody find out more than already stated in this thread ?

If the file format is not easily decodable, maybe a script could be done to print out the plugin parameter names and their setting that are stored in a "preset" ?

Obviously SWS "Live config" is able to push such presets onto a plugin living in a track's effect chain.

-Michael
mschnell is online now   Reply With Quote
Old 12-26-2015, 12:25 PM   #23
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

The preset name is part of the plugin's data itself, not Reaper's. That depends on the plugin in question (it can store it opaque)...

I guess if you want to read from "standard" fxp files you need the fxp spec (i.e plugins that store only parameters, not custom opaque data), which tbh I wasn't able to find so you may have to look at the VST SDK...

(and I have zero clue about VST3)


EDIT: Just to be clear. When you save the project, Reaper asks the VST plugin for its data chunk, and the VST plugin sends the data to Reaper, then reaper just encodes it to base64. That's what I mean that it's not "part of Reaper" and reaper can't decide.
kenz is offline   Reply With Quote
Old 12-26-2015, 01:30 PM   #24
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by kenz View Post
The preset name is part of the plugin's data itself, not Reaper's. That depends on the plugin in question (it can store it opaque)...
Really ?

If you click the little "+" on the Boarder that Reaper builds around the plugin's GUI, you can e.g. "save preset" and then set a name for the preset you save. (You can recall it at any time via that name and e.g. SWS Live Configs can use this preset later to "recall" it.

And this is the same for all plugins, Cockos and non-Cockos, JSFX, VST2, VST3.

To me that looks like a Reaper-created functionality.

Quote:
Originally Posted by kenz View Post
Just to be clear. When you save the project, Reaper asks the VST plugin for its data chunk, and the VST plugin sends the data to Reaper, then reaper just encodes it to base64. That's what I mean that it's not "part of Reaper" and reaper can't decide.
I do know that. It's obvious when playing around with JSFX (Sliders = parameters). With VSTs this seems to be just the same.

If the "preset name" in fact is a port of the plugin's data chunk that would mean that any plugin format necessarily defines this (text-)"parameter".

-Michael

Last edited by mschnell; 12-26-2015 at 11:49 PM.
mschnell is online now   Reply With Quote
Old 12-26-2015, 02:46 PM   #25
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by mschnell View Post
If the "preset name" in fact is a port of the plugin's data chunk that would mean that any plugin format necessarily defines this (text-)"parameter".
Any preset name stored in the data chunk in a predictable location is likely to be the name of the Reaper format plugin preset name/file. Additionally plugins may have their own presets handling stuff. In other words, the data chunk stored in the .rpp file may contain additional Reaper specific data (probably in the beginning), it might not be just the raw data chunk the plugins can produce.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 12-26-2015, 11:52 PM   #26
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Thanks for enlightenment ! (As always )
-Michael
mschnell is online now   Reply With Quote
Old 12-27-2015, 02:56 AM   #27
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

Quote:
Originally Posted by mschnell View Post
Really ?

If you click the little "+" on the Boarder that Reaper builds around the plugin's GUI, you can e.g. "save preset" and then set a name for the preset you save. (You can recall it at any time via that name and e.g. SWS Live Configs can use this preset later to "recall" it.

And this is the same for all plugins, Cockos and non-Cockos, JSFX, VST2, VST3.

To me that looks like a Reaper-created functionality.
You're misunderstanding some things here.

The loading/unloading of plugins is indeed Reaper functionality with the '+' you mentioned -- but it does so through the VST spec (or internally for JSFX). For example, when it saves a preset via the +, Reaper uses a function and asks the VST plugin in question "Send me preset number X", the VST plugin sends its data back, and Reaper saves it.

Same thing when loading a preset, it tells the plugin "Load this preset with this data into slot X", but the data itself is defined by the plugin (and the FXP container, but for most plugins it is opaque other than the header...).

That said, the FXP format DOES store preset names in a known location, however, the plugin is not obliged to use or follow it at all. Some plugins with internal preset management set this name to NULL or nothing and don't even use it.

Also, the FXP format does allow for simple plugins to use a simple 'parameter list' format instead of opaque data. In those plugins, it simply stores their parameters. The FXP format has 4 'types': opaque preset, opaque bank, normal preset and normal bank. The normal categories are the ones with simple parameters but most plugins I know use opaque data. You'll have to look at the VST SDK for exact details of the FXP format, I haven't been able to find its specs anywhere. (it's basically just dumping of C structs... but it is in big endian unfortunately)

Note that some plugins do not even use VST's preset functionality, but an internal preset management. In those plugins, you cannot even use Reaper's + function to save individual presets! Most of said plugins will send opaque data as if they are being saved in the project instead. Some plugins don't even have banks! Those plugins save the same opaque data for banks as for presets!

Ultimately it's up to the plugin what it wants, and how, to send to Reaper so it can store it.

In conclusion: when Reaper gets a plugin parameter, a plugin's preset name, or other things like that, it uses functions defined by the plugin to get them (function pointers in the plugin's struct), not from the chunk directly!

In fact, this has implications even for ReaScript: calling functions that get information about the plugin fails when the plugin is OFFLINE. The chunk exists, but the plugin does not, and Reaper does not know how to get it without calling the plugin itself. (which is proper)

The only downside is that Reaper can't get parameters etc even for offline JSFX, when it should be able to, because those are internal to Reaper and it knows them already. Not sure why it cannot.



Here's what I gathered from the FXP/FXB formats:

Code:
// Remember that ALL THE data is in Big Endian in these structs, swap them for Little Endian (I blame Steinberg's Mac roots :()
// Also, just to be safe, use packing in the structs if you're going to implement them as-is in code, to avoid padding breaking it completely (technically it should be safe, but you never know!)

#pragma pack(push,1)
struct FXB_Header {
  uint32_t Magic;    // 'CcnK' in ASCII
  uint32_t Size;     // this is the entire size of what follows (not including Size and Magic)
  uint32_t Type;     // ASCII 4-byte ID, one of: 'FPch' (Opaque Preset), 'FBCh' (Opaque Bank), 'FxCk' (Preset with Params), 'FxBk' (Regular Bank with Params)
  uint32_t Version;  // seems always 1 for presets (at least for VST 2), for banks it's 1 or 2
  uint32_t FXID;     // the ID of the VST
  uint32_t FXVer;    // version of the VST
};

// now depending on the Type, there are different kind of structs following the prior data, as defined below

// for Presets with Params (what you're probably after)
struct FXB_PresetParams {
  uint32_t NumParams;     // number of parameters
  uint8_t PresetName[28]; // the Preset's name in the FXB
  float Param[];          // variable length list of Parameters, the exact number is defined by NumParams
};

// Opaque Presets
struct FXB_PresetOpaque {
  uint32_t NumParams;     // ignored, useless
  uint8_t PresetName[28]; // the Preset's name in the FXB; NOTE: in this case the plugin MAY IGNORE it
  uint32_t ChunkSize;     // size of opaque chunk following
  uint8_t Chunk[];        // the chunk itself, completely opaque
};

struct FXB_BankParams {
  uint32_t NumPrograms;   // number of Presets in bank
  uint32_t CurProgram;    // current Program selected in the bank
  uint8_t Reserved[124];  // 124 useless bytes

  // List of Presets with all their data, including the headers for each! its exact size is determined by NumPrograms
  struct { struct FXB_Header Header; struct FXB_PresetParams Data; } Preset[];
};

struct FXB_BankOpaque {
  uint32_t NumPrograms;   // same as before, but this can be ignored because it's opaque this time
  uint32_t CurProgram;    // same as above, some plugins don't even have banks...
  uint8_t Reserved[124];

  uint32_t ChunkSize;     // size of opaque chunk following
  uint8_t Chunk[];        // the chunk itself, completely opaque
};
#pragma pack(pop)
Note that it's only the FXB/FXP stuff above that is in Big Endian, 99% sure that the plugin's data will be in Little Endian (I don't mind it since I find LE superior in most usage)

By the way Xen is right that Reaper stores more information before the actual FXB inside the FX chunk: it stores the routings there and other information. I've reverse engineered it awhile ago to some extent as I needed it when parsing. (so you should be able to skip it and get the plugin data with it easily)

After decoding the base64 chunk, this is what is in there more or less:

Code:
// NOTE: all stuff is back to Little Endian, also, these structs are one after another but separated because some have variable length
#pragma pack(push,1)
struct VSTChunkHeader {
  uint32_t FXID;       // the VST ID
  uint32_t Magic;      // 0xFEED5EED or something like that (not important)
};

struct VSTChunkInputs {
  uint32_t NumInputs;     // number of input channels for routing
  uint64_t RoutingMask[]; // a mask for routing the channels in the matrix; each bit defines a column, each element is a different row; its exact size is NumInputs
};

struct VSTChunkOutputs {
  uint32_t NumOutputs;
  uint64_t RoutingMask[]; // same as above but for output routings
};

struct VSTChunk {
  uint32_t Size;       // size of the VST Data
  uint8_t NoIdea[8];   // no idea what these are :)
  uint8_t VSTData[];   // the VST Data itself
};

struct VSTChunkFooter {
  uint8_t NoIdea[6];   // this seems related to the previous NoIdea element but I'm not sure what it is; it's 6 bytes at the end of the VST data.
};
#pragma pack(pop)
Well, reverse engineering complex data formats was one of my hobbies back in the day, I mostly do simple stuff now.

EDIT: fixed typos/errors and replaced char with uint8_t for consistency...

Last edited by kenz; 12-27-2015 at 03:56 AM.
kenz is offline   Reply With Quote
Old 12-27-2015, 03:39 AM   #28
mpl
Human being with feelings
 
mpl's Avatar
 
Join Date: Oct 2013
Location: Moscow, Russia
Posts: 3,960
Default

I see it is 6 years old thread, but just saying: there is some outdated chunk definitions in Cockos Wiki.
mpl is offline   Reply With Quote
Old 12-27-2015, 03:54 AM   #29
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Hmm. Without doing more detailed analyzing, I will not be able to decide, but from my first findings, to me the opinion of Xenakios seems more likely:

Raeper fetches the complete parameter settings (including an "internal" preset list if available) from the plugin via the plugin (e.g. VST) API

The "internal" preset list is part of the VST parameters if the VST provides it there. It might do so or not do so.

Reaper saves this information in Base64 format in the project file

With that information Reaper saves a Reaper propriety "Preset" name for this (complete) parameter setting. This name is managed by the [+] button and rather obviously independent of the VSTs "internal" preset list.

Reaper seems to save the parameter information only in the project file and not in separate ".fxp" files (as e.g. vmachine does).

By means of the Reaper propriety "Preset" name, Reaper can manage multiple sets of parameters for each plugin. Same can e.g. be "called up" by SWS Live Config. (Maybe there is ReaScript function and/or an Action for this as well.)


If you look at the user interface of SWS Live Config you might see what I mean.

-Michael

Last edited by mschnell; 12-27-2015 at 04:02 AM.
mschnell is online now   Reply With Quote
Old 12-27-2015, 04:03 AM   #30
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

Quote:
Originally Posted by mschnell View Post
Hmm. Without doing more detailed analyzing, I will not be able to decide, but from my first findings, to me the opinion of Xenakios seems more likely:
I detailed exactly how a plugin can store its information. This isn't a matter of opinion. It depends on the plugin in question. There are 2 main ways a plugin stores its data. Your parameter list is just one of them, but most plugins I have do NOT store it like that. Rather they store it in completely opaque data.

Furthermore using a VST API to retrieve the parameter info is exactly the definition of opaque data. This means the plugin has to be online for Reaper to get any data out of it.

The chunk is always available because the plugin can be restored even if it's offline, but it is proof that Reaper does not parse the chunk itself because the APIs fail when the plugin is offline.

Quote:
Originally Posted by mschnell View Post
With that information Reaper saves a Reaper propriety "Preset" name for this (complete) parameter setting. This name is managed by the [+} button and rather obviously independent of the VSTs "internal" preset list.
I believe Reaper simply uses the PresetName in the FXP structure I mentioned... but I'm not sure how that is stored in the base64 chunk exactly, though...

Quote:
Originally Posted by mschnell View Post
Reaper seems to save the parameter information only in the project file and not in separate ".fxp" files (as e.g. vmachine does).
Yes it encodes the serializes the structs above into the base64 chunk. I split them up for clarity so you know which one is the "VST chunk" part and which one is Reaper's extra stuff at the beginning (i.e routings)...


Just for the sake of an example, Bidule as VST stores its data entirely opaque (it compresses the xml layout with zlib, and then stores the compressed form in the 'fxb' and reaper serializes it into the base64 etc...).

Because of this, Bidule does not have any presets, not even internally, as it is simply not made for that.

If I click on '+' in Reaper and type a name, nothing happens. And no preset gets added, I can't even rename the preset it says 'No preset' and 'Reset to factory default' (which is just calling an API to Bidule which resets it to default).

If that doesn't convince you well I give up as to me this is not a matter of opinion but simply how things work.

I'm not familiar with SWS Live Config but I don't think it stores the entire Reaper chunk (if it did, it would work around lack of presets though!).

The point is: it's up to the plugin, and not to Reaper, to store/rename/whatever the presets. Reaper just calls APIs for it and cannot retrieve them when it is offline either.

NOTE: I think Reaper omits the FXB Header itself in the chunk, though. I believe it simply stores the plugin's opaque data as-is, but I didn't verify that, sorry.

Last edited by kenz; 12-27-2015 at 04:11 AM.
kenz is offline   Reply With Quote
Old 12-27-2015, 05:05 AM   #31
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by kenz View Post
If I click on '+' in Reaper and type a name, nothing happens. And no preset gets added, I can't even rename the preset it says 'No preset' and 'Reset to factory default' (which is just calling an API to Bidule which resets it to default).
Yep that supports that the "[+]" preset is completely different from the preset list managed by the VST itself. I.e. it is just a Reaper propriety thingy (unfortunately called by the same name).

I did check that changing the [+] - preset name imposes a change in the Base64 information. I did not yet decode the Base64 string to see if the [+] - preset name can be seen there and at what position it is located.

Quote:
Originally Posted by kenz View Post
I'm not familiar with SWS Live Config but I don't think it stores the entire Reaper chunk
It supposedly just stores the [+]-"Preset" name or an ID of the parameter set denoted by same.

-Michael

Last edited by mschnell; 12-27-2015 at 05:29 AM.
mschnell is online now   Reply With Quote
Old 12-27-2015, 07:39 AM   #32
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

EDIT: On further investigation it appears you're somewhat right with this, but it is not stored in the project though.

Reaper's are stored in the 'presets' directory as .ini, which are probably base64 base16 encoded (i.e they store full chunk). Since I had the whole thing read-only, it probably is why it didn't work.

Anyway, that probably just stores a 'snapshot' of the VST chunk in the .ini file, not in the project. So you technically can't save it with the project...

For example an entry in the .ini file is like:
Code:
[Preset0]
Name=Preset's Name
Data=hex chunk
Len=X
But as you can see, that thing does not get stored in the RPP file, which I was talking about (since this topic is about it). It's a way to store global presets for a plugin I guess

Last edited by kenz; 12-27-2015 at 07:45 AM.
kenz is offline   Reply With Quote
Old 12-27-2015, 02:55 PM   #33
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by kenz View Post
Reaper's are stored in the 'presets' directory as .ini,
That in fact is an excellent hint !!!!

It means that to make a decent backup of a project, the presets directory needs to be saved.

Thanks a lot !
-Michael
mschnell is online now   Reply With Quote
Old 12-28-2015, 02:53 AM   #34
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

By the way how much did the base64 thing changed when you changed the preset's name/ID?

I can't see where it could be stored other than the "NoIdea" 8-byte thing in the last struct... it probably is for that purpose but for sure can't store a name though. Maybe it stores just the ID of the preset? (but then what happens if you change the IDs around, or is that not even possible?)
kenz is offline   Reply With Quote
Old 12-28-2015, 02:57 PM   #35
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by kenz View Post
By the way how much did the base64 thing changed when you changed the preset's name/ID?
Changing the [+] - Preset name by a single character changed a single character close to the end of the second line associated to that plugin:

<! AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MwAAAAAA
!> AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MgAAAAAA


-Michael

Last edited by mschnell; 12-29-2015 at 12:53 AM.
mschnell is online now   Reply With Quote
Old 12-28-2015, 03:55 PM   #36
spk77
Human being with feelings
 
Join Date: Aug 2012
Location: Finland
Posts: 2,668
Default

Quote:
Originally Posted by mschnell View Post
Changing the [+] - Preset nane by a single character changed a single character close to the end of the second line associated to that plugin:

<! AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MwAAAAAA
!> AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MgAAAAAA


-Michael
A test with online base64 decoder/encoder:
http://www.motobit.com/util/base64-decoder-encoder.asp



<! AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MwAAAAAA
!> AADwPzTkusM08sA/NWQ8SiX89z8X2c73U+P1PwwAAAAzAAAAUAAAAAYAAAABAAAAAQ AAAJYr82YFtfM/AAAAAAB0ZXN0cHJlc2V0MgAAAAAA

AAAAAAB0ZXN0cHJlc2V0MwAAAAAA = testpreset3
AAAAAAB0ZXN0cHJlc2V0MgAAAAAA = testpreset2
spk77 is offline   Reply With Quote
Old 12-28-2015, 04:37 PM   #37
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,619
Default

Kind of off-topic, but does anyone know why RPP files aren't compressed? My bare orchestral template (before any media items) is over 100MB. It actually is quite painful over my NAS (yay Windows CIFS!) With something like LZ4 this could be compressed in parallel over my 8 cores in about 30ms and trivially halve the size.
tack is offline   Reply With Quote
Old 12-29-2015, 12:54 AM   #38
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by spk77 View Post

AAAAAAB0ZXN0cHJlc2V0MwAAAAAA = testpreset3
AAAAAAB0ZXN0cHJlc2V0MgAAAAAA = testpreset2
You found my secret [+] preset names

Ah, obviously the slash separates the parameters. So it might be "base64url" or similar.

Hence, seemingly the [+]preset name is the last of eleven parameters (after the tenth slash) in the information stored for the plugin instance.



-Michael

Last edited by mschnell; 12-29-2015 at 01:10 AM.
mschnell is online now   Reply With Quote
Old 12-29-2015, 02:08 AM   #39
kenz
Human being with feelings
 
Join Date: Aug 2013
Posts: 339
Default

The slash is part of the base64 characters (the only symbols are + and / in fact, all A-Z and a-z and 0-9). To actually 'delimit' the parameters or data you need to decode it to binary, for sure.

Also about that "second line", you mean in the VST chunk right? Looks like it is actually stored at the end somehow (i.e the VSTChunkFooter I mentioned) after the VST's data...

So the footer actually looks like this:

Code:
* 1 unknown byte, seems always null?
* null terminated preset name
* 4 unknown bytes

Last edited by kenz; 12-29-2015 at 02:31 AM.
kenz is offline   Reply With Quote
Old 12-29-2015, 03:14 AM   #40
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,688
Default

Quote:
Originally Posted by kenz View Post
The slash is part of the base64 characters (the only symbols are + and / in fact, all A-Z and a-z and 0-9).
That is why there is bas64url and several other bas64 variants, that replace these two characters

-> https://en.wikipedia.org/wiki/Base64

So it might be that the slash is a section delimiter.

Quote:
Originally Posted by kenz View Post
Looks like it is actually stored at the end somehow
Yep.

-Michael

Last edited by mschnell; 12-29-2015 at 03:27 AM.
mschnell is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 12:58 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.