You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Its impossible and not the scope of this library to be able to parse all plugin data, these are a few which should be easier to implement.
Generators
3xOSC
BooBass
Plucked
Effects
Fruity Balance
Fruity Blood Overdrive
Fruity Center (lol whatever it does)
Fruity Fast Dist
Fruity Free Filter
Fruity Mute 2
Fruity Notebook 2
Fruity Send
Fruity Soft Clipper
Fruity Stereo Enhancer
Soundgoodizer
Notes for implementers
Technically, all plugins with just knobs and sliders should be easy to implement, Most data is stored in 4 byte unsigned integers but 0-100% or whatever the extremes of the knobs/sliders are, they are pretty small values in terms of the available range.
Once you have implemented a parser for a plugin, please make sure that you add the relevant docstrings and docs. You can choose to add an image of the plugin in docs/img folder of the repo, but don't add your own bit.ly links to docstrings, that will be done by me.
If you have any suggestions, please let me know or if you have PRs mention this issue.
@demberto
I tried looking into Fruity Blood Overdrive, but I am confused about how to interpret the plugin parameters.
Based on this and looking at FruityFastDist as an example I planned to create the parameters "pre_band", "color", "pre_amp", "x100", "post_filter", "post_gain" with all of them StructProp[int], except of x100 which probably will be an enum.IntEnum (0,1).
However, when looking at the parameter values with FLPEdit this does not look at all like what I expected.
First of all, I have no idea what the 3 represents, as I expected this to be the value for pre_band which should have been 0 or some similar minimum value.
I also expected the other values to be 0, 128, 512 or anything similar representing minimum or maximum values as per the current plugin settings.
I also tried to set all knobs to 100% to get a feeling for the range, but these values also do not make immediate sense to me.
In comparison to this Fruity Fast Distortion's parameters fit very neatly with their values interpreted as int.
I have the feeling I am missing something fundamental about event values here. 🤔
Any pointers for how to interpret this would be a great help.
Ahh I remember Fruity Blood Overdrive, I had tried implementing it once earlier. IL probably made the representations closer to the one used by VST plugins.
VST plugins store an 8 or 10 (to indicate they are a VST) in the first 4 bytes. I think redesigned native plugins store a 3.
That's the reason it never changes. Why they did it, IDK. The internal name "Fruity Wrapper" is enough to indicate a VST plugin is loaded, same goes for native plugins.
I also tried to set all knobs to 100% to get a feeling for the range, but these values also do not make immediate sense to me.
Yes the values will be like that. If you check the docstrings on the minimum, maximum and default values of plugin parameters, you will find out that ranges like 128, 256 and 1024 are used a lot. Its indeed a space waste to use a 4 byte integer for such small values.
Match the list of parameters to the values you got starting from the first [16, 39, 0, ... and you will immediately notice that you have cracked it 😉. All knobs have the same range and x100 being a button is stored as a 0 or 1 but in a space of 4 bytes. Hence remaining bytes will be empty.
To get a 4 byte integer, you do:
So, finally 36 bytes are divided into:
4 bytes "native plugin marker", always 3 (the next time you see a 3 at top, just ignore it)
6 params - 4 bytes each = 24 bytes
Remaining 4 bytes will always be zero ig, maybe they are used when used in Patcher, but that's another topic.
I hope I helped. This is a time consuming job.
I misjudged the proportions this issue might reach, I am converting it to a discussion.
Repository owner locked and limited conversation to collaborators on Sep 17, 2022
Activity
ttaschke commentedon Sep 17, 2022
@demberto
I tried looking into
Fruity Blood Overdrive, but I am confused about how to interpret the plugin parameters.Based on this and looking at
FruityFastDistas an example I planned to create the parameters"pre_band", "color", "pre_amp", "x100", "post_filter", "post_gain"with all of themStructProp[int], except ofx100which probably will be anenum.IntEnum(0,1).However, when looking at the parameter values with FLPEdit this does not look at all like what I expected.
First of all, I have no idea what the
3represents, as I expected this to be the value forpre_bandwhich should have been0or some similar minimum value.I also expected the other values to be
0,128,512or anything similar representing minimum or maximum values as per the current plugin settings.I also tried to set all knobs to 100% to get a feeling for the range, but these values also do not make immediate sense to me.
In comparison to this

Fruity Fast Distortion's parameters fit very neatly with their values interpreted asint.I have the feeling I am missing something fundamental about event values here. 🤔
Any pointers for how to interpret this would be a great help.
demberto commentedon Sep 17, 2022
Ahh I remember Fruity Blood Overdrive, I had tried implementing it once earlier. IL probably made the representations closer to the one used by VST plugins.
VST plugins store an
8or10(to indicate they are a VST) in the first 4 bytes. I think redesigned native plugins store a3.That's the reason it never changes. Why they did it, IDK. The internal name "Fruity Wrapper" is enough to indicate a VST plugin is loaded, same goes for native plugins.
Yes the values will be like that. If you check the docstrings on the minimum, maximum and default values of plugin parameters, you will find out that ranges like
128,256and1024are used a lot. Its indeed a space waste to use a 4 byte integer for such small values.Match the list of parameters to the values you got starting from the first
[16, 39, 0, ...and you will immediately notice that you have cracked it 😉. All knobs have the same range andx100being a button is stored as a0or1but in a space of 4 bytes. Hence remaining bytes will be empty.To get a 4 byte integer, you do:
So, finally 36 bytes are divided into:
I hope I helped. This is a time consuming job.
I misjudged the proportions this issue might reach, I am converting it to a discussion.