Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
ASPiK Latest Release: v1.6.0
Avatar
W Pirkle
Admin
June 9, 2019 - 3:12 pm
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline

v1.6.0 was released on June 9, 2019 and is the first SDK version that is hosted on GitHub. 

The MacOS ASPiKreator software was recompiled to stop a corrupt-executable issue, and documentation was added involving some VSTGUI4 items as well as the FX Objects from the 2nd Edition FX Plugin book. 

- Will

Avatar
Jan
Member
Members
June 10, 2019 - 5:49 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

Hello,

I just got your book and took some time this weekend to work with the aspik framework.

I found a few problems and some were solved by switching to the github version:

aspikreator now works on mac

------------------------------------------------------------------------------------------------------------------

building a VST3 project on mac always gives this error: 

-------------------------------------------------------------
Result: 40 tests passed, 0 tests failed
-------------------------------------------------------------
mkdir -p /Debug/test_VST.vst3/
mkdir: /Debug/test_VST.vst3/: Permission denied
make: *** [test_VST_buildpart_1] Error 1

Clearly some cmake macros were not filled in correctly

creating an AU plugin was fine on my macbook

creating a VST3 plugin on windows works fine (it builds and I tested it in Traktion). I run windows 10 in a parallells session on my mac

----------------------------------------------------------------------------------------------------------------------

Avatar
Jan
Member
Members
June 10, 2019 - 5:52 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

The AU plugin works well in Garageband, however it does not render correctly in Presonus Studio One.

It looks like the plugins canvas (ie the actual part that we design or program with vstgui4) is not placed correctly. It renders from the top of the plugin window, thus overpainting the controls that Studio One itself gives to every plugin. 

I have two screenshots where you see it happening, but I cannot attach them here. I can send them to you if you want.

 

Jan

Avatar
shane
Member
Members
June 11, 2019 - 7:56 am
Member Since: June 7, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

The Kreator now works for me on Mac as well. The AU and the AAX projects both compile successfully. Cool

However, I am also getting that "mkdir: /Debug/test_VST.vst3/: Permission denied" error. 

Cheers!

Avatar
W Pirkle
Admin
June 11, 2019 - 10:21 am
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline

Hi Shane

Yeah, the ASPiKreator fix was just a re-compile with the target set to 10.10 which allows anyone from 10.10 and up to use it, as originally released.

AFAIK, the VST error you are getting is not coming from ASPiK. It is coming from a CMake module that Steinberg provides. Since VST3 is already packaged with CMake, I just use their modules, the same as with their SDK, so most of the ASPiK CMake stuff for VST3 is really Steinberg's stuff. This is why AAX and AU are a bit different as they were never packaged with CMake to begin with. For VST3 Mac, there are two possibilities, and one acid-test. 

See the Forum post here and scroll down to the middle where I talk about the various directories that the SDK tries to create, or worse, *assumes exists*

https://www.willpirkle.com/forum/installing-and-using-rackafx7/cmake-error/page-2/#p2337

I think one of those will answer your question.

- Will 

Avatar
Jan
Member
Members
June 11, 2019 - 4:31 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

Hi Will, I checked the link you posted here But it didn't helped me much. 

 

I agree with you this is a VST3 cmake issue. What is happening is that the mkdir command tries to create a directory in root filesystem (which is never allowed with regular user permissions). /Debug/test_VST.vst3/.  See the first slash

However, I found that the plugin is created correctly and can be found in the mac_build/VST3/Debug directory, from where you can copy it to the VST3 folder in your Library subfolder. I suspect the script that is failing is meant to perform the linking of the plugin in that VST3 folder. At my work I am using a slightly older VST3 SDK (but no framework as aspik) and there it works.

It loads and I noticed I didn't had the UI misplacement on the VST3 plugin as I see it in the AU plugin. I wil investigate further the coming days

 

Jan

Avatar
W Pirkle
Admin
June 11, 2019 - 5:39 pm
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline

Hi Jan

You are correct about this - and I just found my Macintosh_HD/Debug folder full of VST3 folders, and each has a SymLink to the VST3 plugin, as if it were in the MacOS location. The issue is coming from CMake/Steinberg, but I may have to add a string to my CMake files to fix this.

I did verify that this is happening and the target path is not getting set to the MacOS location. 

I will check and get back to the Forum; if it requires a new ASPiK update, then I will do that as well.

I will also give you a simple fix to regenerate your Xcode project by re-running CMake if possible.

- Will

Avatar
W Pirkle
Admin
June 11, 2019 - 7:13 pm
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline

OK latest news - I need to update ASPiK - thank you Jan for figuring this out. I never noticed the root/Debug directory, and everything worked properly - plugin got written etc... because for whatever reason, I had opened my root folder for writing. And you are correct, everything is compiled and working and the Plugin is being written. 

This was due to a change in the VST3 SDK 3.6.13 (the current release) where they moved some path stuff around and I had to change the CMake files accordingly. However, the string they used "TARGET_PATH" had changed names from a previous version of the SDK and was supposed to point to the project's ../Debug/ folder, not the root folder.

I am not blaming Steinberg - I should have been more careful with the string variable names (my fault) and part of that is me trying to reuse the same variable names across the CMake files for the other APIs too to try to keep some consistency there. But the Steinberg CMake modules change with every single SDK release so it is always a chore when they change the names of stuff. 

I am going to run some more tests tomorrow morning (mainly on Windows to make sure that TARGET_PATH didn't change meanings again there too), then do a GitHub push of the latest changes (nothing but CMake files for VST3 only) for v1.6.1 -- if you are using GitHub, you can then synchronize your forked version with a pull. Also I'll make the standard zip folder for those who don't want to use Git. 

Thanks again Jan!!!!!

Will

Avatar
W Pirkle
Admin
June 12, 2019 - 11:43 am
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline
Avatar
Jan
Member
Members
June 12, 2019 - 5:37 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

hey Will, 

Happy to help. 

Have to check your fix tomorrow.

 

With regards,

 

Jan

Avatar
Jan
Member
Members
June 13, 2019 - 5:29 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

update the ASPIK project from Git. Creating a new project. VST3 builds now works well. The plugin is softlinked to the library directory where the daw's will find them.

Avatar
W Pirkle
Admin
June 14, 2019 - 9:11 am
Member Since: January 28, 2017
Forum Posts: 362
sp_UserOfflineSmall Offline

Great - glad that this issue has been resolved! And, glad that you are using GitHub - I wish I could get more ppl to use it instead; in addition I would love it if we could get some collaborators to work on some new features: AUv3 (with bridge?), Rack Extensions, etc...

Thanks Jan;

Will 

Avatar
Jan
Member
Members
June 17, 2019 - 3:28 pm
Member Since: June 10, 2019
Forum Posts: 6
sp_UserOfflineSmall Offline

I am software engineer by day so Git is something I use on a daily base.

I advise you to use a standardised naming and method of creating branches and releases. One tool I use on a daily base is git flow. A simple extension on top of git (it exists for the windows installs of git too).

I am interested in bringing more gpu computing in the audio rendering loop. I still don't see it happening a lot and I don't understand it, it is a good computing resource that is left aside.

 

Jan

Avatar
Tom
Admin
June 17, 2019 - 4:35 pm
Member Since: April 3, 2014
Forum Posts: 73
sp_UserOfflineSmall Offline

Jan said

I am interested in bringing more gpu computing in the audio rendering loop. I still don't see it happening a lot and I don't understand it, it is a good computing resource that is left aside.

Hi Jan,

in a plugin you must never do "non-deterministic" things in your process call. This rules out any involvement of the GPU as you have  basically no guaranteed turnaround time / latency. It can/does even vary a lot over time depending on the "mood" of the graphics driver.

What I already did is using the GPU in the view to directly transform a FFT complex spectrum into log-scaled magnitude/phase plots, I think in these areas it can also shine and take a lot off the CPU.

I think Acustica Audio does or at least tried to use CUDA in their Nebula engine, but I never got it to work on my machine - and now I am on AMD GFX board again which leads me to another point: When you do commercial audio software you would need to support a lot of different platforms and this is already a pain without having to care about GPU computing. E.g. all the back-and-forth of Apple regarding nVidia, AMD, Intel graphics in the last years means a high risk for you as you still today have no good cross-platform, cross-GPU-Brand solution for GPU programming: nVidia sticks to CUDA and only has poor OpenCL support, AMD has better OpenCL but does not provide a CUDA compiler, Intel has good OpenCL support but is slow and your CPU will suffer when the integrated GPU gets busy....If you want to tackle this all, this is a real nightmare.

Next point is, that it does not scale well - if you have multiple instances of your GPU-Computing PlugIn, it will quickly saturate the GPU and give even more unpredictable results in terms of turnaround time.   

Then, if someone has a "big" GPUs, it is usually because it is needed, e.g. in Post, to drive the video streams, so they are already busy.

Also, there are DSP cards which are used in audio - and as they are dedicated for the job, there is no interference with all the other tasks a GPU has to handle... 

But I agree, that from an engineering/scientific perspective, "GPU Audio Computing" could be very interesting - I just think it is not very well suited for "real world" VST plugins. 

Best Regards

Tom 🙂

Forum Timezone: America/New_York

Most Users Ever Online: 85

Currently Online:
7 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Skyler: 48

Derek: 46

Frodson: 45

TheSmile: 43

Peter: 41

clau_ste: 39

JimmyM: 33

Gwen: 32

EZB: 24

lppier: 23

Member Stats:

Guest Posters: 1

Members: 579

Moderators: 1

Admins: 4

Forum Stats:

Groups: 12

Forums: 36

Topics: 595

Posts: 2377

Newest Members:

haslo, tomr, Noah, Dave, acv, Vasil992, Vasil92, dowsed, Simple, Chris_1

Moderators: W Pirkle: 362

Administrators: Tom: 73, JD Young: 80, Will Pirkle: 0, W Pirkle: 362