search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.04k stars 1k forks source link

Scripting System #2221

Open mamins1376 opened 9 years ago

mamins1376 commented 9 years ago

i have an idea: create a "platform" like VBA in Office apps, a script system to automate some processes, e.g. a special configuration for triple osc, or making some standard tricks like sidechaining or developing a 'Riff machine' using a small script by user. I know that wants lots of time and programming but can be a nice feature to create a special ability to making musics.

tresf commented 9 years ago

Reminds me of a "record" feature. It could use the undo events as a way to repeat tasks over and over. The tricky part I feel would be knowing how to target the actions.

Wallacoloo commented 9 years ago

This could be doable once we restructure all the controls to use Open Sound Control messaging. Then the macro can just record all the commands that are sent and resend them when you trigger the script.

The difficult part is knowing which "scope" in which to run the command. For example, if you select fx channel 6 in the mixer, then start recording the macro, configure fx channel 6 to route to #7, and then stop recording, what does the macro mean? If I select fx 9 and run the macro, should that just configure channel 6 to send to ch 7 again? Or does it configure the active channel, #9 to send to fx 7? Or does it configure #9 to send to the channel to its right, #10?

Any of those are valid interpretations of the intended action. There's far too much ambiguity for such a macro recording feature to be useful.

Another point to be made is that if there's a series of actions you find yourself always repeating, that sounds like a usability issue, and the best way to fix that would almost always be through some ui refinement rather than macros.

musikBear commented 9 years ago

that sounds like a usability issue

@Wallacoloo -you almost get me going when you talk like that :p MMMMmmmmmmmm donu.. i mean usecases The (perhaps) most important part of software development .. Has lmms ever been through one.. ?

tresf commented 9 years ago

The (perhaps) most important part of software development ..

The most important part of software development is writing good code, which we're always in need of help on. C++ is a lot of work. Please don't make an SDLC term sound like it is more important than the late hours and hard work of the devs. Actions speak louder than words. :+1:

WilliamAHuston commented 8 years ago

@Wallacoloo What is the status of adding OSC control to LMMS? This would be very nice to have. I understand it is a big job, but just basic controls -- like being about to start, stop, detect beat (both within a measure and also the measure within the song) -- would be helpful. Thanks.

Wallacoloo commented 8 years ago

@WilliamAHuston OSC is on hiatus until/unless somebody else picks it up. Some explanation can be found here.

follower commented 6 years ago

With regard to a general scripting system for LMMS, I've spent some time researching potential approaches--primarily from the perspective of integrating Qt-specific solutions into LMMS.

Qt's in-built scripting system(s) are based on JavaScript/ECMAScript and are currently in a state of transition from a deprecated system to a "new hotness".

Python seems to be the most commonly used language outside the officially supported JavaScript implementations (e.g. it's used by FreeCAD).

For my future reference and anyone else who might be interested here's an outline of options and associated issues/documentation (via):

While I have a preference for Python as a language, due to the Qt "native" support of JS, I'd like to try a proof-of-concept using QJSEngine to get an idea of its complexity/functionality but who knows how long it'll take me to get to it. :D And, if I never do, well, hopefully someone else will find these notes helpful to get started. :)

(Somewhat) related LMMS issues: #551, #19, https://github.com/LMMS/lmms/issues/1911#issuecomment-121810037

follower commented 6 years ago

Here's a proof-of-concept of a (simple) Javascript-able application (using the newer but less capable QJSEngine): https://github.com/follower/qtjs-test

The application has a "dial" in its GUI and you can write a Javascript script to set the position of the dial:

qtjs-test-screenshot

If you're interested in seeing how it's implemented the best place to start looking is probably here: https://github.com/follower/qtjs-test/blob/master/qtjs-test/appapi.h

Potential LMMS hooks for scripting

I've been looking at places in LMMS where it might make sense to provide scripting functionality.

There's some broad categories:

1) Scripting of LMMS (i.e. scripting existing functionality). 2) Implementing new LMMS functionality in a script. 3) Existing plugin types (e.g. instruments, effects) implemented in a script. 4) Scripting functionality shipped as part of a song.

There's some blurring between categories.

While (4) has been talked about previously it seems to be the most potentially problematic (a la Word documents with embedded VBA scripts).

What seems to be a better approach would be to require explicit installation of a plugin (for example) rather than shipping the source with the song--even if that's possible.

It seems like (3) would be most limited by performance constraints--and I don't know what they are currently.

The ability to have (2) would potentially enable additional contributors without C++ skills to help enhance LMMS which seems potentially valuable but may require additional work to design/expose a lower level API that enables implementation of new functionality.

Functionality implemented via (2) could potentially be shipped as part of LMMS or as a new style of e.g. "application extension" plugin.

Category (1) lends itself most easily to "personal" scripting/automation tasks (e.g. macros--like "Oh, on the 2nd of every month I shift every 3rd note up an octave") which might in some cases be generally useful. I could see something like a "scripts" menu here. It would most likely require creation of an API implemented/exposed via "Proxy" objects of existing LMMS objects--or potentially with Qt's MetaObject system some of this could be implemented dynamically or through annotations on existing objects.

Hey, it's free to dream, right? :)

Anyway, this has been an interesting exercise so far, if for no other reason than highlighting some of the design decisions to be made--and having an automatable dial in a GUI test app! :)

lcoenen commented 6 years ago

That would be great! One could almost use lmms for live producing instead of relying on time-expensive mouse mouvement.

vlad0337187 commented 6 years ago

Most of applications use Python for scripting, including Blender, Sublime Text, Gedit.

If there would be Python API, it could make easier developing prototypes of some functions.

If to compare Python and Javascript themselves, last would lose by all parameters.

AndiEcker commented 6 years ago

+1 for using Python

2018-04-18 20:07 GMT+01:00 Vladislav notifications@github.com:

Most of applications use Python for scripting, including Blender, Sublime Text, Gedit.

If there would be Python API, it could make easier developing prototypes of some functions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/2221#issuecomment-382496144, or mute the thread https://github.com/notifications/unsubscribe-auth/ADlPbiKYxmhWFQaVGjugN0uUW1BtMwu7ks5tp47qgaJpZM4FiQcl .

follower commented 5 years ago

Hi @hartsantler, thanks for your sharing your Qt Script integration commits.

While Qt Script scores high on the ease of integration/functionality front, I'd have concerns about how wise it is to add a new feature like this using a technology that's already been deprecated for ~3.5 years. From what I've read, the support its unlikely to be removed before Qt 6 but it still seems to me to potentially be creating extra work for ourselves.

Apparently JS standard support has improved in later versions of QJSEngine but I'm not sure how much the integration side of things has improved.

While I was researching the current state I discovered Mixxx uses Qt Script and have a tracking issue for potential replacement: "qt5: Replace deprecated QtScript with QJSEngine" (There's a bunch of informative links in the comments.)

It seems like there's some fundamental issues with the implementation of Qt Script which could also make transitioning an interim API more difficult. (But maybe there's a way we can define a LMMS "Scriptable API" that would support a transition--and maybe Python too. cough :D )

Would you have any interest in comparing how possible it looks to get your Qt Script-based functionality working with QJSEngine?

There's probably some trade-offs between backward-compatibility of Qt releases (i.e. minimum Qt version required to support useful QJSEngine functionality) but FWIW Qt 5.12 (which supports but deprecates Qt Script) has support until early 2020s.

If code that works gets the functionality going then that's cool but I think it's wise to know the trade-offs we might be making.

Thanks for reading. :)

vlad0337187 commented 5 years ago

QScript is the natural choice, and easy to get working in LMMS with the Qt5 API. hartsantler@8b468e5

@hartsantler , sorry, I think, that Python will be better solution, than any Javascript-based language.

It has dozens of available libraries, is enough fast, used in many different programs as scripting language, including with QT5 framework (for example, CryEngine Sandbox). JS, in other side, has too outdated and too non-logical syntax, has too many logical problems.

Generally, thought, that most of UI could be controlled by Python, also, saving files, processing files and many-many non-realtime work could be implemented in Python to save developer's time.

Offtop: Also I think, that C++ is awful language (not bad, but awful). At first - syntax. As I understood, for accessing different types of properties (types, methods, etc), there are needed different tokens (why ?), Second - need for .h to define properties, .cpp to write them Third - no normal package manager, dependencies installed system-wide, applied to project with command-line arguments, and etc., etc. Fourth - crashes. Every the most little mistake can crash all the program. I'd contribute to any project in any language (C#, Java, Vala, ...), but I just can't use C++ (my brain dislikes it, tried to start using it many times).

Think, there will be much more contributors to Python part of LMMS (if it'll be added), rather than to Javascript's (for example) (because JS has not so powerful library support, implementing some features without cpp would be hard), or Lua (not so flexible, no good libraries at all), and rather to C++ (because entry threshold is too high).