Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Q&A, Tips, Tricks and Howto

Reply
 
Thread Tools Display Modes
Old 08-16-2019, 03:33 AM   #1
LuCsa
Human being with feelings
 
Join Date: Aug 2016
Posts: 87
Default Scripting - language and paradigm confusion

Dear Reapers,

once again I'm happily thinking about tackling Reaper scripting, but there is a veeery basic question recurring to me around which I fail to wrap my mind.

Reaper offers me to write my scripts in either EEL, Lua or Python. The documentation also lists C/C++ as an available language.

As a C++ programmer I am very much thinking with the object oriented paradigm in the back of my head. What is ReaScript's "paradigm"?
Lua is per se not object oriented (but you can "fake" classes), Python is, I don't know about EEL... C/C++? What... is it now C or C++? Procedural or object oriented?

In what frame of mind should I conceptualize my scripts?

Secondly, the compiled C/C++ Reaper API dll that is mentioned in the API documentation... Is it for use in external programs?


I'd be glad if someone could shed some light on this and a short explanation of Reaper's/ReaScript's paradigms would be most helpful!

Thanks,
LuCsa
LuCsa is offline   Reply With Quote
Old 08-16-2019, 03:51 AM   #2
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

ReaScript is basically just the Reaper C API functions(*) wrapped to work in a scripting context, it doesn't take advantage of the object oriented possibilities of Lua or Python. Cockos's Eel language doesn't really have real objects. So, ReaScript could be described as "procedural". You can of course do object oriented wrappers in Lua or Python yourself.

ReaScript doesn't allow writing scripts in C or C++, the C API functions are listed in the same documentation for convenience of binary extension plugin developers. If you do an extension plugin with C++, you get access to some actual object oriented possibilities. There are some C++ base classes/interfaces you can inherit from and make Reaper create and use instances of those. A lot of the code needs to be written in C, though. (So the bulk of the code is going to be procedural with C++ extensions too.)

(*) Much of the Reaper API has always been the C API functions, even for C++ extension plugins.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 08-16-2019 at 09:15 AM.
Xenakios is offline   Reply With Quote
Old 08-16-2019, 04:39 AM   #3
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

To add to the confusion there also are "JSFX"es in Reaper.
These are plugins that can be scripted in EEL and can be used in the same ways as VST plugins (doing Audio and Midi stuff). EEL supposedly is the only script-type language that is fast enough for this, and moreover has the advantage to be usable for ReaScripts (supposedly the fastest variant here, as well), using a very similar IDE, built in in reaper for both issues.

And of course you can do VST plugins in C++ and use them in Reaper.

-Michael
mschnell is offline   Reply With Quote
Old 08-16-2019, 06:05 AM   #4
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Quote:
Originally Posted by LuCsa View Post
Secondly, the compiled C/C++ Reaper API dll that is mentioned in the API documentation... Is it for use in external programs?
There's no 'stock' Reaper API dll, if you menat that, you'd do it yourself in the form of a Reaper extension plugin, as Xenakios has mentioned.

e.g. SWS extension or js_ReaScriptAPI extension.
nofish is offline   Reply With Quote
Old 08-16-2019, 06:16 AM   #5
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by LuCsa View Post
Secondly, the compiled C/C++ Reaper API dll that is mentioned in the API documentation... Is it for use in external programs?
The wording is a bit unclear, it should IMHO be something like :

Quote:
API functions can be called from compiled C/C++ dynamic libraries (such as the SWS extension plugin) that are loaded by REAPER
Reaper or its API can not be used directly as a library from external programs. (Except by doing interprocess communication. You would write an extension plugin for Reaper that acts as a server for the external application or something like that.)
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 08-19-2019, 01:36 PM   #6
LuCsa
Human being with feelings
 
Join Date: Aug 2016
Posts: 87
Default

Thanks for your explanations! :-)

Quote:
Originally Posted by Xenakios View Post
ReaScript is basically just the Reaper C API functions(*) wrapped to work in a scripting context, it doesn't take advantage of the object oriented possibilities of Lua or Python. Cockos's Eel language doesn't really have real objects. So, ReaScript could be described as "procedural". You can of course do object oriented wrappers in Lua or Python yourself.

ReaScript doesn't allow writing scripts in C or C++, the C API functions are listed in the same documentation for convenience of binary extension plugin developers. If you do an extension plugin with C++, you get access to some actual object oriented possibilities. There are some C++ base classes/interfaces you can inherit from and make Reaper create and use instances of those. A lot of the code needs to be written in C, though. (So the bulk of the code is going to be procedural with C++ extensions too.)

(*) Much of the Reaper API has always been the C API functions, even for C++ extension plugins.
It strikes me that the API isn't inherently object oriented...it seems so
obvious to me, but maybe I'm taken in by some big misunderstanding...
So even when I call a "getTrack()" function which returns a "track" this is not an "object"?

How would I create a C++ extension?

Do you make use of the object oriented paradigm when, for instance, scripting with Python?


Kind regards,
Lukas
LuCsa is offline   Reply With Quote
Old 08-19-2019, 03:12 PM   #7
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by LuCsa View Post
It strikes me that the API isn't inherently object oriented...it seems so
obvious to me, but maybe I'm taken in by some big misunderstanding...
So even when I call a "getTrack()" function which returns a "track" this is not an "object"?

How would I create a C++ extension?

Do you make use of the object oriented paradigm when, for instance, scripting with Python?
Cockos hasn't wanted to lock themselves to use some particular C++ class declarations etc for much of the stuff, which they'd need to do if for example MediaTrack was a public class. You can get pointers to for example MediaTracks (such as with GetTrack) but they are "opaque", you don't get to know what's actually inside or change their behavior. Instead they provide C compatible functions like :

Code:
SetMediaTrackInfo_Value(MediaTrack* tr, const char* parmname, double newvalue)
Incidentally, these translate pretty well into scripting languages too, since most will support pointers in some manner, strings and floating point values. Using Reaper's objects in this manner does get sometimes a bit awkward with the scripting languages, though. You are basically writing C even with the scripting languages. (IIRC, you may even need to do manual memory management in some cases.)

Cockos could of course add nice object oriented wrappers for the scripting languages, but they have decided not to do that. It would also be pretty limited at the moment, as the Reaper API doesn't have much support for callbacks. Whatever object like style they would be able to add, would mostly be syntactic sugar for reading and changing object properties.

C++ extensions are quite painful, you don't want to be doing them unless there's no choice or if you find that sort of thing entertaining. They are dlls/dylibs that export a single C function that will need to set up whatever the extension is going to be doing. There is lots manual work involved just to add for example a new action. There are some code examples around, but no comprehensive tutorials, as far as I know.

Here's a fairly minimal C++ extension example code I've done :

https://github.com/Xenakios/reaper_very_minimal

The actual extension code is in main.cpp, the other files are support stuff for building the plugin.

ReaScript should cover most basic needs for creating custom actions for Reaper.

I don't do ReaScripts with Python anymore, but if I recall right, I didn't use Python's object oriented features much. With Lua, it seems to be mostly a waste of time trying to make the Reaper API functions usable via an object style interface. Of course any custom logic, data handling or GUI needed can benefit from an object style approach.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.

Last edited by Xenakios; 08-19-2019 at 04:18 PM.
Xenakios is offline   Reply With Quote
Old 08-19-2019, 09:47 PM   #8
mschnell
Human being with feelings
 
mschnell's Avatar
 
Join Date: Jun 2013
Location: Krefeld, Germany
Posts: 14,686
Default

Quote:
Originally Posted by LuCsa View Post
Do you make use of the object oriented paradigm when, for instance, scripting with Python?
Besides using Python "inside" of Reaper as one of it's scripting languages - whith the appropriate pros and cons - , there also is "Beyond Reaper / Python".

This exports the Reaer API via a Python-Object Remote interface (via OSC hence in the end via an IP network interface) to be accessed by a stand alone Python program. This can be useful to do programs with their own GUI (and optionally running on a different Computer box) that are only loosely coupled with a free running Reaper instance.

A friend of mine very happily uses this paradigm.

-Michael
mschnell is offline   Reply With Quote
Old 08-22-2019, 01:01 PM   #9
LuCsa
Human being with feelings
 
Join Date: Aug 2016
Posts: 87
Default

Quote:
Originally Posted by Xenakios View Post
Cockos hasn't wanted to lock themselves to use some particular C++ class declarations etc for much of the stuff, which they'd need to do if for example MediaTrack was a public class. You can get pointers to for example MediaTracks (such as with GetTrack) but they are "opaque", you don't get to know what's actually inside or change their behavior. Instead they provide C compatible functions like :

Code:
SetMediaTrackInfo_Value(MediaTrack* tr, const char* parmname, double newvalue)
Incidentally, these translate pretty well into scripting languages too, since most will support pointers in some manner, strings and floating point values. Using Reaper's objects in this manner does get sometimes a bit awkward with the scripting languages, though. You are basically writing C even with the scripting languages. (IIRC, you may even need to do manual memory management in some cases.)
Ah, so things like "MediaTrack*" etc are just typedef pointers to some underlying data structure the functions know how to "read"?

Quote:
Originally Posted by Xenakios View Post
Here's a fairly minimal C++ extension example code I've done :

https://github.com/Xenakios/reaper_very_minimal

The actual extension code is in main.cpp, the other files are support stuff for building the plugin.

ReaScript should cover most basic needs for creating custom actions for Reaper.
Thanks, I'll look into it. Thanks for clearing things up!


Quote:
Originally Posted by mschnell View Post
Besides using Python "inside" of Reaper as one of it's scripting languages - whith the appropriate pros and cons - , there also is "Beyond Reaper / Python".

This exports the Reaer API via a Python-Object Remote interface (via OSC hence in the end via an IP network interface) to be accessed by a stand alone Python program. This can be useful to do programs with their own GUI (and optionally running on a different Computer box) that are only loosely coupled with a free running Reaper instance.

A friend of mine very happily uses this paradigm.

-Michael
Ohh, cool, that sounds awesome... I'll start with ReaScripts, but since I'm working pretty much with Python at work right now I might look into that as well later.

Cheers!
LuCsa is offline   Reply With Quote
Old 08-22-2019, 02:34 PM   #10
Xenakios
Human being with feelings
 
Xenakios's Avatar
 
Join Date: Feb 2007
Location: Oulu, Finland
Posts: 8,062
Default

Quote:
Originally Posted by LuCsa View Post
Ah, so things like "MediaTrack*" etc are just typedef pointers to some underlying data structure the functions know how to "read"?
For C++ code, not even typedefs, just forward declared classes so the Cockos header files can be used for compilation.

ReaScript code handles them essentially as void*'s but I think there's some type validation going on internally, so that you can't crash Reaper too easily with the script code.
__________________
I am no longer part of the REAPER community. Please don't contact me with any REAPER-related issues.
Xenakios is offline   Reply With Quote
Old 08-23-2019, 12:15 PM   #11
LuCsa
Human being with feelings
 
Join Date: Aug 2016
Posts: 87
Default

Quote:
Originally Posted by Xenakios View Post
For C++ code, not even typedefs, just forward declared classes so the Cockos header files can be used for compilation.

ReaScript code handles them essentially as void*'s but I think there's some type validation going on internally, so that you can't crash Reaper too easily with the script code.
Cool, thanks for clarifying...
LuCsa is offline   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 07:59 AM.


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