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 sp_TopicIcon
64 bit build issue
No permission to create posts
November 22, 2017
7:49 pm
Avatar
Eddie
Member
Members
Forum Posts: 12
Member Since:
July 11, 2017
sp_UserOfflineSmall Offline

Hi 

I've noticed a issue with 64 bit builds, I think someone posted something similar a while back. I had assumed issue was fixed. This is just using the Rackafx dll as a 64 bit dll. Not tried VST3. Assume the port to VST is the same(rackafx latest version updated theader files)

Basically if you add over say 70+ controls then depending on the size of the rest of the project you will get a stack overflow error. I have tried increasing the size of the stack reserve size to 2000000-90000000 (project properties/ linker/ system ) still no difference in visual studio 2015 & 2017. My code in question is not too complicated all variables and methods defined in the public section of the main header file. No graphics apart from a few standard knobs. Even if you blank out the gui it still happens.  This mostly happens on debug builds as they use more memory, from debugging I can see that it will get in to the constructor but no further than initUI() .

To test i used a build that worked ok in debug build, then added another 20 test controls bringing control count to 80 or so. Stack overflow!

Debugged in a couple of Daws Ableton 9 64 & Orion 64. Same on both. X86 builds seem fine as they use much less stack memory.

Any ideas on how to fix? Or a work around as I have a project that I want to finish and I need over 80 controls.

 

Regards

 

Mark

November 25, 2017
7:48 am
Avatar
Tom
Admin
Forum Posts: 67
Member Since:
April 3, 2014
sp_UserOfflineSmall Offline

Hi Eddie,

I was able to reproduce the issue - the problem is the size of the generated initUI method I think...

Regarding the stack reserve size, I guess it has no effect in this case: The DLL is loaded by another process (your DAW in this case) which already has allocated the stack for the calling thread.

Best Regards

Tom

November 27, 2017
2:16 pm
Avatar
W Pirkle
Admin
Forum Posts: 206
Member Since:
January 29, 2017
sp_UserOfflineSmall Offline

I also found this (VS2017 64-bit compile) on a huge project, and I have fixed it.

It is a __chkstck() problem with the initUI( ) function eating the stack due to the static object construction in the linked-list's append( ) method. And, yes Tom is correct about the host allocating the stack - it does not happen for some clients.

If you want the fix now, I can show you the code - unfortunately, the initUI () funciton is re-written each time you update a control in RackAFX so you'd need to play a few tricks to get around it, namely calling a sub-function from the top of the initUI( ) method. The fix is relatively simple - instead of appending the controls statically, you load them into a std::vector, then after all the CUICtrl declarations, you for-loop over the vector and append them directly. This removes the static declarations. 

I do not plan on releasing an update until after Jan 1, 2018 as I am also adding some new stuff that is going to help with the Make XXX functions. 

I am tied up at the moment but will post a temporary fix later today/tomorrow.

- Will

November 28, 2017
7:47 am
Avatar
W Pirkle
Admin
Forum Posts: 206
Member Since:
January 29, 2017
sp_UserOfflineSmall Offline

OK here is my temporary fix for __chkstck(). I may refactor this before the next release in 2018, but this should get you running to complete your current project. The PDF below shows what to replace (the append() functions) and what to comment out. You will likely want to use a text editor to do mass string replacements.

After all uiX inits, you loop over the vector and do the append()s within the loop, deleting each control pointer afterwards. Then, you clear the vector. You can also rewrite this to use pop_back() in the loop, but I'll let you decide.

Note that RackAFX uses special hex characters to replace/update code (yeah, this goes back to 2004 in the first generation product). This means that you can circumvent the update process by placing your altered code above the first hex code, then returning from the function. You'll need to cut and paste all the extra stuff after the loop-over-vector as well since it is required. I've tested this with a 64-bit plugin with 75 controls in Reaper, no problem. Also, if you use VS2017, you can catch any future chkstck() errors. The debugger will halt on the first { of any function whose stack usage is greater than the page size. 

One other note: the RAFX2 API has been in development for more than a year now. It cleans up all these static declaration issues (and many, many other things), adds super tight integration with AAX, AU and VST, and is C++11 compliant. Stay tuned, but don't fret - it won't be released until Fall 2018 at the earliest.

- WP

http://willpirkle.com/special/.....hk_fix.pdf

November 29, 2017
8:49 am
Avatar
Eddie
Member
Members
Forum Posts: 12
Member Since:
July 11, 2017
sp_UserOfflineSmall Offline

Ok cheers Will.

 

I'll give it a go.

 

Regards

January 13, 2018
10:24 am
Avatar
Eddie
Member
Members
Forum Posts: 12
Member Since:
July 11, 2017
sp_UserOfflineSmall Offline

Hi

Regarding this 64 bit issue with the size of the initui function overflowing the stack. The fix you gave works fine been using it for a while now. Was wondering if this had been fixed for Rackafx 6.9? Or will I still need to do if I open project in 6.9?

Also have another quick question about rackafxs built in presets. When ever I implement these in a plug in, I find that when you close & save your project in a DAW rather than loading up the plug in state as it was, it loads up whatever preset patch was open?  Should it not load the state as it was when you saved your DAW project?

 

Regards

January 16, 2018
12:12 pm
Avatar
W Pirkle
Admin
Forum Posts: 206
Member Since:
January 29, 2017
sp_UserOfflineSmall Offline

Hi Eddie

1) yes this is now implemented in v6.9

2) this issue with saving VST plugin states was a known bug in the VST SDK 3.6.6 - it only affects VST2 plugins, though. The VST3 versions preserve the correct saved states. 

Steinberg fixed this in the next version of the SDK. I need to update the VST3 libraries with the newer version but this will take some time for testing due to changes made to the VSTGUI4 portion. 

Standby for that update. 

In the meantime, if you do a "proper" export of your project with Make VST (v6.8.x) or Export Project (v6.9+) then you can compile with a newer SDK (3.6.7 for RAFX v6.8 and 3.6.8 for RAFX v6.9) and remove this issue. 

Each time there is a VST3 SDK update, I usually have to go through some hoops to get things adjusted to stuff they changed. The move to CMake with v6.9 should address most of this - but not this particular case with the RAFX-DLL-as-VST-DLL paradigm...

- Will

Forum Timezone: America/New_York

Most Users Ever Online: 36

Currently Online:
5 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Skyler: 48

Derek: 44

Peter: 41

Frodson: 40

clau_ste: 39

Gwen: 32

JimmyM: 29

EZB: 24

lppier: 23

Msaldaña: 18

Member Stats:

Guest Posters: 1

Members: 506

Moderators: 1

Admins: 4

Forum Stats:

Groups: 11

Forums: 31

Topics: 524

Posts: 2022

Newest Members:

semihyavuzz, alfredLue, danioc, midnightskate3, Alia5, Shamal Sundar, Walker, Brad, soli, Malcolm rest

Moderators: W Pirkle: 206

Administrators: Tom: 67, JD Young: 80, Will Pirkle: 0, W Pirkle: 206