Add the framework : CoreFoundation.framework by clicking on the +
By default the bundle is created in this folder /Users/xxxx/Library/Developer/XCode/DerivedData/xxxxxxx
(see in red below)
Personnaly I prefer a relative path. Click on "File" then "Project settings..."
You can also define this relative path approach to be activated by default for each new project by clicking on "XCode" then "Preferences".
Please also not the "Archives" path that you can also customize.
The idea behind the type of build (debug or release) is available by clicking on "Product" then "Scheme" then "Edit Scheme"
"Archives" is when you want to deploy your build on AppStore
For release build, you can change the "Run" to select "Release" instead of "Debug" in this window
Then click on "Product" then "Destination" then "Choose Destination", select "Any Mac (Intel)" instead of "My Mac"
After that, you can start to add your files (.h and .cpp) in the "MyPlugin" yellow folder.
Add your resources if you have some (in order to be included in the bundle) in "Copy Bundle Resources" section.
Add your .cpp files (no need to add .h files) in "Compile Sources" section
Finally you click on "Product" then "Build"
Posté Mon 02 Nov 20 @ 10:51 pm
Thank you DJCEL.
I will try the week-end ;-)
I will try the week-end ;-)
Posté Sat 07 Nov 20 @ 10:24 am
I have just successfully compiled in .bundle on mac :-)
Is there also a release mode on xcode?
Because apparently the compilation is in debug mode.
Is there also a release mode on xcode?
Because apparently the compilation is in debug mode.
Posté Sat 07 Nov 20 @ 3:12 pm
I answered with additional screenshots above.
"Archives" is when you want to deploy your build on AppStore
"Archives" is when you want to deploy your build on AppStore
Posté Sat 07 Nov 20 @ 10:50 pm
Perfect DJCEL !
Thank you
Thank you
Posté Sun 15 Nov 20 @ 12:53 pm
You are welcome. You can share with me one test of bundle file (release build) (zip it before sending it) and i check on my system that everything works ok.
Then you can upload everything on the website ;-)
Use the variable VDJ_MAC in your code (with #if defined(VDJ_MAC) on the parts of your code that are differents between both version) to keep one source file. Easier for updates
Then you can upload everything on the website ;-)
Use the variable VDJ_MAC in your code (with #if defined(VDJ_MAC) on the parts of your code that are differents between both version) to keep one source file. Easier for updates
one_example wrote :
#if (defined(VDJ_WIN))
rcXML.id = IDR_SKINXML; // as defined in resource.h
rcPNG.id = IDR_SKINPNG; // as defined in resource.h
rcXML.type = "XML";
rcPNG.type = "PNG";
#elif (defined(VDJ_MAC))
rcXML.name = "FX_GUI.xml";
rcPNG.name = "FX_GUI.png";
#endif
rcXML.id = IDR_SKINXML; // as defined in resource.h
rcPNG.id = IDR_SKINPNG; // as defined in resource.h
rcXML.type = "XML";
rcPNG.type = "PNG";
#elif (defined(VDJ_MAC))
rcXML.name = "FX_GUI.xml";
rcPNG.name = "FX_GUI.png";
#endif
Posté Sun 15 Nov 20 @ 1:11 pm
Please use "arm64" for M1 chip or "x86_64" for intel chip
But you can compile with both to get an universal binary (ie compatibility of the program with both chips)
https://developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon
But you can compile with both to get an universal binary (ie compatibility of the program with both chips)
https://developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon
Quote :
i386 : 32-bit intel
x86_64 : 64-bit intel
x86_64h : 64-bit intel (haswell)
arm64 : 64-bit arm
arm64e : 64-bit arm (Apple Silicon)
arm64_32 : 32-bit code on 64-bit arm
armv6 : 32-bit arm
armv7 : 32-bit arm
armv7s : 32-bit arm
armv7k : 32-bit arm
x86_64 : 64-bit intel
x86_64h : 64-bit intel (haswell)
arm64 : 64-bit arm
arm64e : 64-bit arm (Apple Silicon)
arm64_32 : 32-bit code on 64-bit arm
armv6 : 32-bit arm
armv7 : 32-bit arm
armv7s : 32-bit arm
armv7k : 32-bit arm
Posté Sat 29 Jan 22 @ 1:47 pm
I followed this process to create a Max OS (M1) bundle for the OnlineSource example Plugins_SDKv8_Example7.html and copied it to Documents/VirtualDJ/PluginsMacArm/OnlineSources/
The files compile, and the bundle looks good, but the Online Source never shows up when VirtualDJ is opened. Also, my included logging indicates that the DllGetClassObject() function in the bundle is never called. How do I debug this?
The files compile, and the bundle looks good, but the Online Source never shows up when VirtualDJ is opened. Also, my included logging indicates that the DllGetClassObject() function in the bundle is never called. How do I debug this?
Posté Thu 27 Oct 22 @ 10:18 pm
Online Source plugins are currently only available for Pro users
Posté Fri 28 Oct 22 @ 6:33 am
Thank you. I just upgraded to VirtualDJ PRO Infinity. After logout/login, VDJ setup shows the license, but the plugin still isn't loading.
~/Documents/VirtualDJ/PluginsMacArm/OnlineSources/VdjConnect.bundle
#include "TestProvider.hpp"
HRESULT VDJ_API DllGetClassObject(const GUID &rclsid,const GUID &riid,void** ppObject)
{
Log log;
log.info("DllGetClassObject called..."); // This logs to /tmp/vdj.log
...
*ppObject=new TestProvider();
return NO_ERROR;
}
~/Documents/VirtualDJ/PluginsMacArm/OnlineSources/VdjConnect.bundle
#include "TestProvider.hpp"
HRESULT VDJ_API DllGetClassObject(const GUID &rclsid,const GUID &riid,void** ppObject)
{
Log log;
log.info("DllGetClassObject called..."); // This logs to /tmp/vdj.log
...
*ppObject=new TestProvider();
return NO_ERROR;
}
Posté Fri 28 Oct 22 @ 3:47 pm
Could you send it to me? I'll have a look, but it should be loaded on startup
Posté Fri 28 Oct 22 @ 4:01 pm
Sure. Do I post the bundle file here or email it?
Posté Fri 28 Oct 22 @ 4:07 pm
Sent you a PM with my email address
Posté Fri 28 Oct 22 @ 4:11 pm
Got it, looks like it was a bug in VirtualDJ not loading OnlineSources plugins correctly.
Will be fixed in next update.
Will be fixed in next update.
Posté Sun 30 Oct 22 @ 9:36 am
I compiled the example at https://www.virtualdj.com/wiki/Plugins_SDKv8_Example.html into MyPlugin8.bundle but can't seem to get VirtualDJ to find it once moved into the following location:
"/Users/USERNAME/Documents/VirtualDJ/Plugin64/MyPlugin8/MyPlugin8.bundle"
What can I be missing? I'm on Big Sur, fresh install of Virtual DJ.
"/Users/USERNAME/Documents/VirtualDJ/Plugin64/MyPlugin8/MyPlugin8.bundle"
What can I be missing? I'm on Big Sur, fresh install of Virtual DJ.
Posté Tue 29 Aug 23 @ 4:56 am
It's Plugins64, not Plugin64 (if you are on Intel mac), the sub folder should be the type of the plugin, not MyPlugin8. So OnlineSources, Other, SoundEffect, VideoEffect etc...
Posté Tue 29 Aug 23 @ 5:13 am
Arm or intel mac?
Posté Sat 02 Sep 23 @ 3:09 am
It's intel. Still have been having the same issue, fixed the path but it doesn't find the plugin. Upgraded to pro to see if it makes a difference but haven't logged on via my mac yet. Works on Windows although I'm using 'C:\Users\USER\AppData\Local\VirtualDJ\Plugins64'
Posté Mon 04 Sep 23 @ 12:57 am
One or two questions.
1 does "FXName.bundle" folder live on a mac as .zip or are they just as a folder?
or is it different to either case I guessed?
2 copying & renaming, with windows you just copy the .dll and rename, then you have a new copy, is it the same case with mac?
1 does "FXName.bundle" folder live on a mac as .zip or are they just as a folder?
or is it different to either case I guessed?
2 copying & renaming, with windows you just copy the .dll and rename, then you have a new copy, is it the same case with mac?
Posté Wed 13 Dec 23 @ 6:16 pm
Yes, .bundle and .app are really just folders, although Finder hides this fact by default. (You can still right-click and select 'show contents' to 'open' the folder and look inside)
Copying and renaming should indeed work in the same way.
Regarding code style, one thing I'd personally do different is to declare the parameters with a fixed size directly, rather than manually allocating/deallocating memory for each.
So char parStatus[2048]; instead of char *parStatus = new char[2048];
And to make it even more tiday (and safe from mistakes) you could then also use std::array instead:
std::array<char, 2048> parStatus
Then you can use parStatus.data() where you need a pointer to the data, and parStatus.size() when you need the size.
And since the data is now part of the CMyPlugin8 object, you don't need to deallocate it anymore either.
Another small thing is that you might want to look at std::format for creating strings. Probably doesn't matter too much in this case, but it should be quite a bit more performant than stringstream.
Copying and renaming should indeed work in the same way.
Regarding code style, one thing I'd personally do different is to declare the parameters with a fixed size directly, rather than manually allocating/deallocating memory for each.
So char parStatus[2048]; instead of char *parStatus = new char[2048];
And to make it even more tiday (and safe from mistakes) you could then also use std::array instead:
std::array<char, 2048> parStatus
Then you can use parStatus.data() where you need a pointer to the data, and parStatus.size() when you need the size.
And since the data is now part of the CMyPlugin8 object, you don't need to deallocate it anymore either.
Another small thing is that you might want to look at std::format for creating strings. Probably doesn't matter too much in this case, but it should be quite a bit more performant than stringstream.
Posté Wed 13 Dec 23 @ 6:43 pm