Old 10-07-2019, 02:46 PM   #41
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 2,816
Default

REAPER starts actions (via hookcommand) on the main thread. You can start a new thread to do some background processing if you wish, but many API functions cannot safely be called from it (which ones is not documented).

What do you want the loop to be doing exactly? Why must it run so fast?

Last edited by cfillion; 10-07-2019 at 03:01 PM.
cfillion is online now   Reply With Quote
Old 10-07-2019, 04:42 PM   #42
Alkamist
Human being with feelings
 
Join Date: Dec 2011
Posts: 500
Default

Quote:
Originally Posted by cfillion View Post
REAPER starts actions (via hookcommand) on the main thread. You can start a new thread to do some background processing if you wish, but many API functions cannot safely be called from it (which ones is not documented).

What do you want the loop to be doing exactly? Why must it run so fast?
I see. Thanks for the info.

Well what I was specifically asking you about was calling a function that loops and terminates when there is a key up: I was trying to figure out if I could rewrite my Zoom Tool script in C++ to get more fps out of it.

Basically I'm a nerd who plays video games with a 144 Hz monitor, so 30 fps to me looks super unresponsive. I know that it doesn't matter to most people but I'm really picky is all.

I was also thinking of porting this unpublished as of yet pitch correction GUI script that I did in Lua to C++ to try to get more fps on that as well.
Alkamist is offline   Reply With Quote
Old 10-07-2019, 04:52 PM   #43
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,957
Default

Quote:
Originally Posted by Alkamist View Post
if I could rewrite my Zoom Tool script in C++ to get more fps out of it.
Since it ultimately relies on Reaper's code for zooming and drawing, trying to call the Reaper functions more often isn't necessarily going to make it run any better. Reaper has well known issues with GUI responsiveness and extension plugins can't really do anything about that. Anyway, the code does look quite complicated and you might get some improvement by using C++, but it's not guaranteed.
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is offline   Reply With Quote
Old 10-07-2019, 05:10 PM   #44
Alkamist
Human being with feelings
 
Join Date: Dec 2011
Posts: 500
Default

Quote:
Originally Posted by Xenakios View Post
Since it ultimately relies on Reaper's code for zooming and drawing, trying to call the Reaper functions more often isn't necessarily going to make it run any better. Reaper has well known issues with GUI responsiveness and extension plugins can't really do anything about that. Anyway, the code does look quite complicated and you might get some improvement by using C++, but it's not guaranteed.
Yeah I'm starting to get the impression that switching my development to C++ isn't the right thing to do. At least with my motive.

I could also definitely improve the code on the Lua end as well. As I've started developing more and more I've gotten a lot better. I'll probably end up going back and refactoring everything I've done so far to improve performance and readability.
Alkamist is offline   Reply With Quote
Old 10-08-2019, 06:54 AM   #45
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 9,112
Default

@Alkamist

An alternative to doing your own extension would be integrating/submitting your zoom tool to SWS, as the basic facilities (registering actions, doing continous actions I linked to previously) are already there.

Tbh I'm a bit hesitant to suggest this though, because of the rather slow release cycles SWS currently has (hoping this will change at some point, but not sure about it.)

Last edited by nofish; 10-08-2019 at 07:19 AM.
nofish is offline   Reply With Quote
Old 10-08-2019, 08:26 AM   #46
moss
Human being with feelings
 
moss's Avatar
 
Join Date: Mar 2007
Location: Germany
Posts: 408
Default

Quote:
Originally Posted by cfillion View Post
This is how dialogs are constructed at runtime by SWELL:
[code]#include <swell/swell.h>
#include <swell/swell-dlggen.h>
...
Many thanks for the example code!

I tried to compile this on Windows:

1) So far I understood that SWELL emulates Windows functions, therefore swell.h is only included on Macos and Linux. How do I now include "swell-dlggen.h" on Windows? I get a lot of wrong type errors when I try to compile.

2) In your example you create a static variable. Is that somehow necessary or can it be put in a class or even created on the fly?

3) I guess I use CreateDialog to create the dialog?! How do I clean that up? Can this be called multiple times?

Thanks!
moss is offline   Reply With Quote
Old 10-08-2019, 08:29 AM   #47
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 2,816
Default

SWELL is for macOS and Linux only. On Windows you would use the Windows API as usual.

Quote:
Originally Posted by moss View Post
2) In your example you create a static variable. Is that somehow necessary or can it be put in a class or even created on the fly?
SWELL_DialogRegHelper objects must live forever once constructed unless SWELL_curmodule_dialogresource_head is reverted when destructing them. (It would be best to make a replacement helper class that takes care of that.)

Last edited by cfillion; 10-08-2019 at 08:44 AM.
cfillion is online now   Reply With Quote
Old 10-08-2019, 09:39 AM   #48
Alkamist
Human being with feelings
 
Join Date: Dec 2011
Posts: 500
Default

Quote:
Originally Posted by nofish View Post
@Alkamist

An alternative to doing your own extension would be integrating/submitting your zoom tool to SWS, as the basic facilities (registering actions, doing continous actions I linked to previously) are already there.

Tbh I'm a bit hesitant to suggest this though, because of the rather slow release cycles SWS currently has (hoping this will change at some point, but not sure about it.)
I might do that at some point after I refactor the code. I'm going to try to clean it up because the code currently is pretty gross.
Alkamist is offline   Reply With Quote
Old 10-08-2019, 01:24 PM   #49
moss
Human being with feelings
 
moss's Avatar
 
Join Date: Mar 2007
Location: Germany
Posts: 408
Default

Quote:
Originally Posted by cfillion View Post
SWELL is for macOS and Linux only. On Windows you would use the Windows API as usual.
Thanks for the explanation. I dived a bit into the code and it seems my understanding of SWELL was correct but those SWELL_Make functions are basically internal functions for the implementation of a static windows dialog based on a resource description. Therefore, one would need to implement those functions for Windows as well to be able to write cross-platform code.
moss is offline   Reply With Quote
Old 10-08-2019, 01:38 PM   #50
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 7,957
Default

Quote:
Originally Posted by moss View Post
Therefore, one would need to implement those functions for Windows as well to be able to write cross-platform code.
Or just #ifdef the code sections that create the controls for the different platforms to call CreateWindow on Windows and the Swell make functions for the other platforms. (On Windows, every win32 GUI control like a text field or a button is a "window".)
__________________
For info on SWS Reaper extension plugin (including Xenakios' previous extension/actions) :
http://www.sws-extension.org/
https://github.com/Jeff0S/sws
--
Xenakios blog (about HourGlass, Paul(X)Stretch and λ) :
http://xenakios.wordpress.com/
Xenakios is offline   Reply With Quote
Old 10-08-2019, 01:46 PM   #51
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 2,816
Default

The SWELL_Make* functions can also be used without registering a resource ID. This is how SWELL internally builds the color/file/font picker dialogs on Linux: by opening a blank dialog (resource ID = nullptr) and filling its content when handling the WM_CREATE window message (see swell-miscdlg-generic.cpp).
cfillion is online now   Reply With Quote
Old 10-10-2019, 11:53 PM   #52
moss
Human being with feelings
 
moss's Avatar
 
Join Date: Mar 2007
Location: Germany
Posts: 408
Default

Thanks for the hints!
Will look into it when I find some time.
I guess there is no cross-platform (simple) example for that?
moss is offline   Reply With Quote
Old 10-11-2019, 07:32 AM   #53
cfillion
Human being with feelings
 
cfillion's Avatar
 
Join Date: May 2015
Location: Québec, Canada
Posts: 2,816
Default

The easiest way to have cross-platform Windows/SWELL code (that is without implementing window creation twice) is to use the resource files to describe the dialogs. You can move and hide controls dynamically later as needed.

Last edited by cfillion; 10-11-2019 at 08:51 AM.
cfillion is online now   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:53 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.