Framework is now updated to support latest VST 3.6.7+ SDK. Plugins builds nicely but there are some warnings on mac, though plugins works nicely... I will check this in the future.
Hi there, I can’t find the post any more, but did I see you say that you have basic .ini/preference file saving implemented into WDL-Youlean? It’s just coming to the point where I need to look into putting that into my plug.
Hi there, I can’t find the post any more, but did I see you say that you have basic .ini/preference file saving implemented into WDL-Youlean? It’s just coming to the point where I need to look into putting that into my plug.
Yes, look at IPlugConfigFile. It is tested just briefly but it should work...
Ok, so no luck so far. I have the following code in my .h file and in OnParamChange:
Code:
IPlugConfigFile myPlugPrefs;
case kPrefsSaveButton:
myPlugPrefs.SetFilePath("C:\\test.ini");
myPlugPrefs.WriteValue("defaultgroup", "test variable", 12.0, "test comment");
myPlugPrefs.WriteFile();
// Hide the Preferences window
preferencesGroup->HideControls(true);
break;
I've tried forward and backward slashes on the file path, first singly, then after some Googling found I should be doubling them up. But no test.ini file appears at C:\
I'm also not sure how I should approach saving prefs on OSX, I think a lot of software uses the com.<companyname>.<productname>.plist files in <username>-Library-Preferences-Preferences format, but those appear to be saved as XML files.
Ok, so no luck so far. I have the following code in my .h file and in OnParamChange:
Code:
IPlugConfigFile myPlugPrefs;
case kPrefsSaveButton:
myPlugPrefs.SetFilePath("C:\\test.ini");
myPlugPrefs.WriteValue("defaultgroup", "test variable", 12.0, "test comment");
myPlugPrefs.WriteFile();
// Hide the Preferences window
preferencesGroup->HideControls(true);
break;
I've tried forward and backward slashes on the file path, first singly, then after some Googling found I should be doubling them up. But no test.ini file appears at C:\
I'm also not sure how I should approach saving prefs on OSX, I think a lot of software uses the com.<companyname>.<productname>.plist files in <username>-Library-Preferences-Preferences format, but those appear to be saved as XML files.
Sorry for late reply. Are you using mac or windows?
New update is available. This time I have added true retina support on mac and DPI awareness on windows. If you use GUIResize you can activate true retina mode by adding one line of code to the constructor: pGraphics->UseSystemGUIScaling();
BTW, on windows it took me one half an hour to implement but on mac close to 4 days. I really hate mac...
Please test this as I am not yet sure if it works perfectly in every DAW, though I have tested it in several DAWs...
Sorry for late reply. Are you using mac or windows?
No probs! I'm mainly developing on Mac but am testing things on Windows as well to keep things in check. In this case I was testing with Windows, I figured as it was .ini file based it'd better to get things working in Windows and then get expand it to work on Mac as well. But yeah, this was with Windows 10.
Also regarding your second comment, unfortunately I don't have access to a Retina Mac so can't test the new features (spot the Hackintosh guy...). Would it still be useful for you for me to test the feature anyway?
can we get a loudness meter beta that does retina? :-) you need a good demo project
Good demo project to showcase retina support?
Well I am in middle of updating Loudness Meter to V2, the problem is that there is a lot of changes under the hood so it will take a while until I finish it. One of the main problems is that I will introduce "Pro" version that will have couple of more features like dynamic hisogram so it will be a challenge to set everything up for sure... Hopefully if everything goes well I will be able to support development of new plugins and updates to the framework... We will see.
Youlean, your VST3 SDK 3.6.7 implementation is great. However I found a bug: at this line you are erasing the second output bus instead of the second input bus. :-)
Youlean, your VST3 SDK 3.6.7 implementation is great. However I found a bug: at this line you are erasing the second output bus instead of the second input bus. :-)
I also updated kNumPrograms in Resource.h. The preset names appear in both Logic and Ableton but selecting them in the host doesn't update the kGain parameter with the specified value, it just stays at the last user-selected value.
I also updated kNumPrograms in Resource.h. The preset names appear in both Logic and Ableton but selecting them in the host doesn't update the kGain parameter with the specified value, it just stays at the last user-selected value.
I have not yet updated the preset system. I still have couple of bugs to solve. Sorry for delay.
That's ok, I understand! I have a feeling that the parameters may be causing some extra weirdness in Logic when changing window size and view mode, but I need to examine this further before properly reporting it.
Could anybody please test the demo version of Bitwig Studio with a VST3.6.7 built on Windows ? For me VST3s (32+64 bit) are no more working after I have updated today. I get in Plug-Ins->Settings->Show errors found with plugins the following error:
Code:
com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: Could not read VST plug-in metadata
64 bit plugin host reported errors: Pluginhost returned non zero exit code -2
32 bit plugin host reported errors: Pluginhost returned non zero exit code -1
VST2 and all my other DAWs seem to run fine with VST2/3.6.7.
That's ok, I understand! I have a feeling that the parameters may be causing some extra weirdness in Logic when changing window size and view mode, but I need to examine this further before properly reporting it.
Could anybody please test the demo version of Bitwig Studio with a VST3.6.7 built on Windows ? For me VST3s (32+64 bit) are no more working after I have updated today. I get in Plug-Ins->Settings->Show errors found with plugins the following error:
Code:
com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: Could not read VST plug-in metadata
64 bit plugin host reported errors: Pluginhost returned non zero exit code -2
32 bit plugin host reported errors: Pluginhost returned non zero exit code -1
VST2 and all my other DAWs seem to run fine with VST2/3.6.7.
I figured the Bitwig VST3 crash out and corrected it on myself: I checked my VST3s with the validator of the SDK and everthing is fine.
It's a crash in Bitwig (and maybe other DAWs) while scanning a 3.6.7 SDK side chain plug-in and only when using a VST3 SingleComponentEffect (like we do in IPlug): Bitwig queries a second output bus with index = 1 in getBusArrangement (without getting the number of output buses before), when two input buses are present (main + aux = side chain). This is really a bad behaviour of this DAW.
The second bad behaviour is by Cubase not to implement an index check before casting an element of the bus list in getBusArrangement. They implemented a boundary check in this method of the multi component vstaudioeffect.cpp (that other unknown frameworks :-) and the side chain example in the SDK use ) and forgot it in vstsinglecomponenteffect.cpp. By inserting the two lines of the screenshot into the second cpp, the SDK 3.6.7 is returning a reasonable error instead of crashing (and Bitwig seems to await this error or at least has no problems with it).
That was very, very hard to figure out: bitwig has some kind of debug protection, doesn't respond to my (recently sent) e-mails and it's not possible to debug the scanning of plug-ins (because of sub-processes and time limited scanning, later in processing it's possible to debug the seperate processes). I just ended up with adding dozens of TRACEs in VST3 SDK/IPlugVST3 and that helped a lot.
Sorry, Youlean, wrong thread here, but I answer here my own question anyway. :-) the only relevant point here for IPlugVST3 is, if we want to migrate to VST3 multi component usage (one day).
Yep, presets seem to be working well over here! One thing I've noticed is that you can get strange results if you try to populate a parameter with the wrong type. It ends up being assigned to another parameter, which left me confused for a while.
Sorry for the noob question, I havent'been following the developments. I'm thinking about changing to WDL-Y for a number of reasons. Is there a list of all the critical differences that I should check against to make moving easier and preventing new bugs in my code?
Sorry for the noob question, I havent'been following the developments. I'm thinking about changing to WDL-Y for a number of reasons. Is there a list of all the critical differences that I should check against to make moving easier and preventing new bugs in my code?
I could make guide how to switch. I will write that tomorrow. As far as changes goes, there shouldn't be much work to switch, maybe hour or two... The biggest problem I would say is that preset management is changed internally so plugins build with my framework won't be compatible with WDL-OL save states in daw, though there is a workaround for that... This was mainly changed so we can have system that will make possible dynamic adding or removal of controls in minor updates. Everything that works in WDL-OL should be working in my framework too.
Actually, now that I think more the best way to switch is to rename old project folder and clone my IPlugEffect with same name as your old project, then you can copy resource.h + source and header files from old project to new one. Now if you added some libs you will need to add them again in the projects.
in resource.h you will need to add #define AU_MIDI_FX 0
also there are some API changes:
mRECT to mDrawRECT
GetRECT to GetDrawRECT
LoadBitmap to LoadPointerToBitmap
I think that this would be it. If you have any problems, let me know.
Quote:
Originally Posted by 1eqinfinity
Hm, interesting. I'm using states chunks and save a lot of additional data. Must I rewrite the SerializeState()?
No, from your side everything will be same, only internal stuff is changed because of private/public parameters (private are still shown in AU and VST3, I will fix that ASAP)...
Ok, I'll try, thanks!
Embedding fonts for one is a very nice feature, and live GUI editing is too.
Oh, one more thing, what's the result of #define AU_MIDI_FX 0?
Ok, I'll try, thanks!
Embedding fonts for one is a very nice feature, and live GUI editing is too.
Indeed, this saves a lot of time and frustrations..
Also, live edit will be expanded in the future with live control layer adjustments, undo redo etc. This was also available in old version, but I needed to make it from scratch in order to eventually support total GUI edit with live editor like adding controls etc...
Hi there, got another question regarding configs/preferences - what’s the best approach to storing strings in a config file? I'm trying to store the user's first and last name in there for copy protection reasons. Saving and recalling it to and from the file is going as expected, but the plugin crashes with a Bad Access error if the .ini file doesn’t exist. It doesn’t do this with floats and ints, so I feel like there’s a conceptual issue I need to understand first.
I’m currently trying things along these lines. Should I be using a string instead and converting it to a char array afterwards?