Lua and automation envelopes generation

[X-Raym]

@Xenakios
This s so impressive. Probably the most powerful envelope generator I ever saw !

[Xenakios]

Development will probably be on hold until next week. (Gig on Sunday, need to prepare for that. But well, if I am insane enough, I might incorporate the envelope generator in the live performance too...)

[musicbynumbers]

Originally Posted by Xenakios

But well, if I am insane enough, I might incorporate the envelope generator in the live performance too...)

That's the "spirit (of adventure)" there!

[heda]

Originally Posted by Xenakios

Development will probably be on hold until next week. (Gig on Sunday, need to prepare for that. But well, if I am insane enough, I might incorporate the envelope generator in the live performance too...)

using it live... could generata some cool stuff... like this (youtube video) :P

Take a week break. But only a week eh?

[FnA]

It has already begun.

http://fox6now.com/2014/08/03/it-was...ore-than-2000/

[todd_r]

Originally Posted by Xenakios

...I will try to make this as awesome as possible, so that maybe Cockos can include this with the Reaper 5 installer at some point...

Any word that it would? I really think it should as it look amazing!

[Xenakios]

Tried continuing work on the script but looks like Lua is starting to beat me... There certainly are some very odd and annoying things in the language. I just spent like 2 hours debugging (without success) a problem that shouldn't even be a problem in a properly designed and implemented programming language...

I am starting to seriously consider if I should just do this envelope generator thing as an extension plugin in C++ with Juce...(That would of course mean no way it would be included in the Reaper installer.)

[Argitoth]

Hey Xenakios, do it. Choose a language that does what you need.

[heda]

sad...
and curious about the annoyances in the language...
I don't know what more advanced features were you trying to do, but it is working great in Lua as it is already.

[Xenakios]

Originally Posted by heda

sad...
and curious about the annoyances in the language...
I don't know what more advanced features were you trying to do, but it is working great in Lua as it is already.

The stuff I tried coding wasn't advanced by any means. But looks like I don't completely understand Lua's tables and how one is supposed to deal with variables/tables that refer to each other. It seems to be surprisingly easy to cause completely incomprehensible data corruptions in Lua. And people say that kind of badness is supposed to be C++'s domain! (At least C++ code usually crashes when this kind of stuff happens. But Lua just keeps on going, without any way to really understand what went wrong and when.)

[heda]

I started learning python, but then EEL came out and I thought ok let's learn EEL, but then Lua came out and I am still learning Lua. Don't tell me I need to learn C++. that's too much for me now hahaha. ok. I hope tomorrow will be a better day
I've found Lua is more exigent with the variables than EEL. For example not liking passing nil when expecting a value. EEL wouldn't complain, but Lua gives an error. I guess C++ is still much more difficult. But then you really know what is doing. Whatever language you choose but please don't leave it unfinished. For me it was already pretty.

[Xenakios]

Originally Posted by heda

then Lua came out and I am still learning Lua. Don't tell me I need to learn C++

Lua is probably just fine if you don't make things too complicated...It could be that despite my own estimation, I may have been doing things a bit too much on the "edge"...It's also within the realm of possibilities Reaper's Lua implementation isn't completely correct. That would be very complicated to debug, though. These weird problems I've had with Lua are so random, it's not trivial to produce a simple test case for Cockos to investigate. I also wouldn't want to waste their time in case I've made some elementary mistakes with my Lua code.

C++ as a language is pretty easy in the end... What is difficult and what I myself hate is the complexity of just getting things to build as desired. Visual Studio and XCode are complete bitches to work with in that department. Also more advanced libraries like Juce or Qt complicate build set ups a lot. So C++ isn't my favourite language to do relatively simple casual things. There certainly has to be a bigger project to work on to make it worth it. I didn't initially think this envelope generator would be such a project and I thought it'd be nice to learn Lua while doing it.

[babag]

been a month since the last post on this. what's the status? any changes, updates in the works? abandoned? re-evaluating?

just curious as this is something i could really use.

thanks,
BabaG

[musicbynumbers]

Originally Posted by babag

been a month since the last post on this. what's the status? any changes, updates in the works? abandoned? re-evaluating?

just curious as this is something i could really use.

thanks,
BabaG

there is a version right now it does a lot of it. (first post)

I'm sure Xenakios will get around to it soon, I think it will be worth the wait!

[babag]

yeah. was just curious as it seemed at a crossroads.

[Xenakios]

Been busy doing other stuff...(Updating my HourGlass software.)

I'll take a last look at the Lua version of the envelope generator at some point and if it doesn't start working correctly, I'll think about something else for it.

[babag]

thanks, xenakios.

[Xenakios]

Started working on the C++/Juce based version of this today since I didn't feel like starting to debug whatever obscure problems there were in the Lua based version.

[IXix]

Originally Posted by Xenakios

Started working on the C++/Juce based version of this today since I didn't feel like starting to debug whatever obscure problems there were in the Lua based version.

CPP FTW!

[jrp]

Lua is probably just fine if you don't make things too complicated...It could be that despite my own estimation, I may have been doing things a bit too much on the "edge"...It's also within the realm of possibilities Reaper's Lua implementation isn't completely correct. That would be very complicated to debug, though. These weird problems I've had with Lua are so random, it's not trivial to produce a simple test case for Cockos to investigate. I also wouldn't want to waste their time in case I've made some elementary mistakes with my Lua code.

C++ as a language is pretty easy in the end... What is difficult and what I myself hate is the complexity of just getting things to build as desired. Visual Studio and XCode are complete bitches to work with in that department. Also more advanced libraries like Juce or Qt complicate build set ups a lot. So C++ isn't my favourite language to do relatively simple casual things. There certainly has to be a bigger project to work on to make it worth it. I didn't initially think this envelope generator would be such a project and I thought it'd be nice to learn Lua while doing it.

nicely put! What do you mean by "on the edge"?
btw, i can totally understand maybe shortly taking a final look, and not going back to an older somhow malfunctioning project.

[Xenakios]

Originally Posted by jrp

What do you mean by "on the edge"?

Too many "object" instances, too much passing around of functions as variables...I would expect all that to work, but it looks like something went wrong somewhere and I am not really willing to look into that anymore.

I would currently not recommend Lua for anything large and/or complicated. Anything more than 50 lines of code and I am sure unexpected problems will start appearing. It's fine for short simple things though, which is the intended use of scripting languages anyway. Obviously keeping the code short and uncomplicated basically means almost any stuff involving GUI is out. At least I wouldn't start trying to do any involved GUI work in Lua/ReaScript anymore.

[ovnis]

Any news ?

[Xenakios]

Sorry, no news yet. Been busy with other stuff and will probably be until the end of September...But I might need this envelope generator thing in the mean while, so I might work on the C++ version at some point...The Lua version is definitely abandoned now, I don't want to start fighting with the Lua GUI code anymore.

[Lostz]

Originally Posted by Xenakios

Originally Posted by Xenakios

Please, can you share these latest versions? For study purpose only.

Thanks, and congratulations for the script.

[Xenakios]

Originally Posted by Lostz

Please, can you share these latest versions? For study purpose only.

Thanks, and congratulations for the script.

The version shown in the gif animations should be available in the Bitbucket git repo, not in the latest commit though, the latest commit is where things started breaking down miserably when I tried to add buttons to enable/disable the envelopes etc...

So maybe this one :

https://bitbucket.org/xenakios/reape...envelope01.lua

If that one is too broken, try looking for a still older version from the repo (the env generator script uses only the generate_envelope01.lua file) :

https://bitbucket.org/xenakios/reaper-lua-stuff/src

[Lostz]

Thanks!

[todd_r]

Any news on the new version?

[Lawrence]

C++ as a language is pretty easy in the end...

I'm not too bright then because I find it pretty difficult.

The above is not me being facetious, but sincere, I really struggle with the basics. I often wonder if I'd dived in earlier when I was younger and more patient would I feel differently about that.

I haven't looked again recently and the last one didn't help me very much (and again, that's on me, not any fault of the person providing the examples) but are there any newer skeletal / basic working extension examples out there that might be easier to grasp?

One of you guys should teach a mini class on that, and assume that those learning know nothing.

[Xenakios]

Originally Posted by Lawrence

are there any newer skeletal / basic working extension examples out there that might be easier to grasp?

The C++ Reaper extension plugin example I've done is pretty close to the most basic example possible. If I recall right, it isn't even really C++, but just C stuff. Which actually might make it a bit harder to understand. However, the guts of the Reaper extension system are C so it's slightly difficult to avoid exposing all the C ugliness involved. I have however been thinking of some solutions for that...

I stand by what I wrote earlier : C++ as a language isn't very difficult. APIs and libraries one may have to use to do anything interesting might be, for example because they expect one to write C and not C++. Or they might be using a C++ style that makes things difficult and error prone to do. (Unfortunately for example the Reaper API things that actually are C++ tend to be in that category.)

Another example of a difficult C++ API/library is the Boost Graph library. While it in theory uses the best C++ principles, it is in practice very difficult and frustrating to use. It looks like it is easier to just write one's own library for graph data structures instead of using the Boost one.

Another thing that you might confuse with C++ being "difficult" is that build systems (how the code is compiled into a working binary from multiple code files, header files, library files) are generally a complete bitch to deal with. That however isn't entirely the language's fault but rather the fault of the manufacturers (like Microsoft and Apple) who do the so called "Integrated Development Environments" that have hardly anything "integrated" in them for C++. If the language ever gets "modules", some of those issues may go away but that isn't going to officially happen until 2017 earliest. I would say that dealing with the build systems is a different skill set from writing the C++ code. A well thought out example project for Visual Studio or XCode may alleviate some of the issues involved, but it's hard to not make things eventually escalate...

Build system issues aside, I honestly do enjoy writing certain kinds of C++ code!

[Xenakios]

Originally Posted by todd_r

Any news on the new version?

Sorry, no. Too many other things on my mind lately.

[Lawrence]

Originally Posted by Xenakios

I stand by what I wrote earlier : C++ as a language isn't very difficult.

I wouldn't dare attempt to dispute that by any means, especially not from someone as skilled as yourself. Like many technical things it appears to be at least partly relative to how you learn and/or maybe how you think and unfortunately for me, I seem to be on the bad end of that scale.

Otoh, I've never had a really structured course in it either so that might also play into it. I've found some languages reltatively easy to grasp, and some others, like C++, a real struggle. I might just be giving up to soon, letting my frustrations get the best of me. Everything semi-complex requires a certain bit of motivation I guess. I don't know how many of the scripting gurus (James and SPK and those great guys) are also doing extensions.

I installed VS Community 2015 yesterday, haven't even launched it yet to look over what's new, but I might give it another go when the weather turns really cold here.

[Xenakios]

Originally Posted by Lawrence

I wouldn't dare attempt to dispute that by any means,

The problem is that for example in Reaper context there simply are no simple examples to give. The underlying C API is just too low level(*). A C++ abstraction layer would first need to be written on top of those things before I could demonstrate how simple things can be. (I haven't so far done such a thing because of course I can myself manage even with the raw C calls, most of the time.) Also the C++ base classes/interfaces in Reaper are so complicated to implement that an intermediary class would almost always be needed for newbies to have any chance of doing anything useful with them. Things are further complicated by the Reaper API not being complete which leads to use of various hacks that again make things unnecessarily complicated.

edit : And when GUIs are involved, it all becomes muddled up by the complexities of how different C or C++ libraries implement GUIs. The language and its common techniques to implement GUIs may seem like the same thing to you, but I've long ago learned to separate those issues in my mind. The unfortunate fact is : there is NO way to make a GUI simply with C++(**), especially if you need to also take into account the GUI has to run inside a plugin. The language was never designed in tandem with a GUI framework in mind, like Visual Basic or C#/.NET or Delphi clearly have been
designed.

edit2 : I also noticed in the Juce forum you had some problems understanding how the Presonus VST3 plugin extensions should be used in a Juce plugin. That kind of stuff is so complicated I have problems understanding it. However, it again has nothing to do with the C++ language itself. It's a complexity in the API you would like to use. VST3 is a horribly complicated framework and then there's Juce to deal with too...(Sorry for digging that up in the Juce forum, but I kind of wanted to understand what kinds of things you have been struggling against...) This is stuff you will never learn taking a basic C++ course. And probably not in an advanced course either.

(*) Cockos has managed to expose those APIs to the scripting languages relatively cleanly, though. Basically, if the C functions are all one needs, there probably isn't a reason to even touch the topic of developing a C or C++ extension plugin anymore instead of writing in one of the ReaScript languages.

(**) I have wondered if a really simple C++ library could be designed to do GUIs but I am probably not going to be the hero who actually ends up doing it. GUI libraries are horribly boring and involved work. I rather live with the slight complexities that for example something existing like Juce has.

[kenz]

For what it's worth, I only know some C and I find it *much* easier than C++. I tried to learn C++ but gave up when it became with too many rules/abstractions and things to learn. C is just easy to learn because it is a simple language without a lot of things to worry about and learn. However, the syntax for function pointers is an absolute nightmare, but I keep a note nearby handy for 90% of its uses whenever I need them. I'm talking about the language itself here, not importing whatever libraries (including the standard libraries).

GUI is always a pain and it does not apply to C(++) only, even in JSFX I find it a burden when I need it for some FX.

Anyway, I know EEL is terrible at dynamic memory/arrays in general but I didn't think Lua also has nitpicks with tables and the like (I don't know lua at all), hope to see more of this script whether it's extension or not.

[Xenakios]

Originally Posted by kenz

C is just easy to learn because it is a simple language without a lot of things to worry about and learn.

I think C has a LOT more things to worry about than real C++. I could give some embarrassing examples about what C is compared to C++, but I'll let it be. We can agree to disagree.

I agree about function pointers though. Before C++11 the same awful syntax had to be used for them in C++ too.

[Lawrence]

Good explanations X. Thanks,

That must be part of the reason why C# is so popular, GUI. I see it being used now in all kinds of cross platform use cases. I found it very interesting to find that VB 2015 was actually written in VB and the devlopers talked about some of the misconceptions of spped and all that being more in the underlyijg coding approach, no so much in the higher level managaing of some of the parts.

[Lawrence]

Originally Posted by Xenakios

edit : And when GUIs are involved, it all becomes muddled up by the complexities of how different C or C++ libraries implement GUIs. The language and its common techniques to implement GUIs may seem like the same thing to you, but I've long ago learned to separate those issues in my mind.

That's (partly) what gives me fits, especially in Windows. The Windows GUI frameworks are just (always) sitting there and my assumption was they should be easy to reach. Is there really no simple way to instance a form or other controls in C++ like you can in those other languages?

If not, I suppose that means all of those other methods are managed in some way, hiding the complexity. Can you code with the standard Windiws class libraries in C++?

I think I should probably stay at the kiddies table.

[Xenakios]

Originally Posted by Lawrence

That's (partly) what gives me fits, especially in Windows. The Windows GUI frameworks are just (always) sitting there and my assumption was they should be easy to reach. Is there really no simple way to instance a form or other controls in C++ like you can in those other languages?

If not, I suppose that means all of those other methods are managed in some way, hiding the complexity. Can you code with the standard Windiws class libraries in C++?

I think I should probably stay at the kiddies table.

C++ is very unideal for using the modern Windows GUI facilities. There is nominal support but I wouldn't touch that stuff anymore even with a long pole. Interestingly enough, the very first prototype of HourGlass was done with C++ that used the Windows Forms stuff. I soon however realized that approach just won't work in the long run. (The C++ that has to be used for that stuff isn't standard C++, so I eventually went with the Qt framework instead. Later I realized Qt absolutely sucks for use with plugin code...So now I've been migrating towards Juce, which has certain guarantees it will work for plugin programming.)

From C++ the ancient awful C-based win32 GUI programming style can of course be used. But that's just plain shitty to develop with.

[Lawrence]

Crazy. Good to read though, that it's not (all anyway) me.

I guess I've been living in a bubble where creating a new windiws form by .... ermn... simply writing ."X as New Windows Form" (so to speak) just doesn't translate directly to those lower level languages, i assumed I could include those classes and instance those things directly from those libraries in a few short lines of code. Silly me.

I mean if you look at the "visual" languages (C#, whatever), the "designer" code that gets auto created when you drag in GUI parts, it's not really anything you couldn't type out manually in a Windows script and get to the same place. I also dabbled in F# for a minute and it too is not really built for that so much.

[Xenakios]

Originally Posted by Lawrence

Crazy. Good to read though, that it's not (all anyway) me.

I guess I've been living in a bubble where creating a new windiws form by .... ermn... simply writing ."X as New Windows Form" (so to speak) just doesn't translate directly to those lower level languages, i assumed I could include those classes and instance those things directly from those libraries in a few short lines of code. Silly me.

The Windows Forms stuff for C++ works pretty much the same as for the other languages. Drag and drop design of the forms, it will generate code for the control event handlers etc. However I personally have very good reasons to never use that system again. The long term price of using the special C++ flavour needed for that is just too high. (As a more technical detail, the C++ dialect has garbage collection facilities which standard C++ of course doesn't have. In that Microsoft "managed" C++ you can create new objects on the heap and won't need to delete them manually later. This can faairly effectively be done with standard C++ too, but Microsoft of course didn't want to go that way back then.)

I want my code to use standard C++ that compiles on multiple platforms, even if I would not actively use those other platforms. It is a safe guard for the future so that I don't have to be stuck with a platform because of something I've myself developed. (My current computer usage is pretty evenly distributed between Windows and OS-X though...) Software users also appreciate if one's software is available for something else than Windows too.

It's also worth noting that things like VST plugins and Reaper extension plugins will need to have parts written with lower level APIs anyway, because they themselves use the win32 API for the GUI. It may be quite tricky to get Windows Forms GUIs to interoperate correctly enough inside something like Reaper.

The C++ and Windows Forms combination is also clearly a second class citizen in the Microsoft ecosystem, so I would also expect all sorts of problems because of that too.

[Lawrence]

After going through "C++ 101" yesterday your previous comment makes much more sense to me. Indeed, the basics of the language itself (syntax, approaches, etc) are indeed not that hard. It gets more (comparably) difficult when you start to do some other stuff.

As to MS, yeah, it's interesting to watch how people react to their languages. I did a lot of Enterprise development with VB because (obviously) it's fast to get results with and when I first moved to .NET I hated it, compared to VB6. A lot of things that were drag and drop in VB6 became more manual in .NET, like graphics and printing (something that is a big priority in Enterprise development) got a bit harder. It's funny to see how many enterprise developers still love and use VB6... and are still shouting at MS to bring it back or extend it's development. They had actually left VB out of some parts of the forward progress of C# and so many people complained they actually changed their minds.

As much as the C# fans will try to dispute it, it's a clear truth that those languages compile the same, no real pressing functional difference.

I want my code to use standard C++ that compiles on multiple platforms

Yes, that seems to be the best reason to use C++ (other than necessity in some cases like VST). I see now that C# is doing much the same via vendor products, compiling cross platform (desktop and mobile) apps from C# code.