Tutorial: Triggers (Part 3)

[attic]

Like the link - never found that one before

That link is the beginning to your book.

[stw]

So welcome to the 40s club mates
I first saw a Z80 in a school project when some nerds did some wicked things beyond my understanding with it
Not much later i had a C20! and wrote a few apps including a game. Hundrets of peek and poke lines saved on a datasette. What an invention that time...
After that i had to learn the serious things on an Apple II with Pascal in school... times are changing

[trogluddite]

Hundrets of peek and poke lines saved on a datasette

Oh, that really takes me back. Whenever I get p***ed off trying to de-bug some assembly, I always try to remind myself of those days - hours spent with the calculator working out addresses, and typing in page after page of hex, followed by the inevitable crash because of one mis-typed digit, that then took days to find (if you ever did!).
Truly, the 'new generations' of programmers don't know how lucky they are to have amazing tools like SM.

[McBarGig]

Hi Guys, sorry it took me so long to get back to you all. I have been buried in work.
In terms of the preset loading and the triggers, IMO there is only one resolve to this... Code in C++ and control your own loading times. I cannot think of any reason this has to be like this, but it is and I cannot find a way around it. It should take no more than a quarter of a second to load 1500 parameters. Of course that depends on other factors, but in our case its a one way street, one parameter does not rely on the next, although SM thinks they do and goes all crazy into a trigger flurry...haha

My thoughts for improvement in this area for whatever its worth...
-Do not send a trigger on each and every parameter load, Send one final trigger when its done, thats all and leave it up to the user to do what they will with that trigger.

-Define a simple and easily understandable means of shutting the damn things off!

-Define the lifespan of the trigger and clearly identify its consumer(s)
It would be nice to see where exactly a trigger originates and where it ends..

In the grand scheme of things, 1500 lines in a text file is nothing, perhaps in 1982 reading from a floppy it would have taken a half a second, but not now.

What my research has yielded..
It is not worth circumventing the built in preset mechnism without first controlling the triggers around the rest of the schematic. If you write a routine to load a text file, the text file will load blazing fast, but as soon as you start sending that data to the controls, you are in the same boat, if not worse than if you just let SM handle it. So, until we can completely shut off these schematic wide triggers, and I mean all of them, we won't resolve this issue.

Parsing, I do not do any parsing in SM anymore at all, it is all done externally by scripts, or executables so that I can avoid the triggers. Parsing 1500 lines is quite trivial, yet in SM you will wait quite a while. Understandably so given that each control gets a trigger, adds something to it, then sends it on to the next control. All that adds up to processing.

So for me, and for the type of stuff that I've been working on, I try to do the trivial programming tasks outside of SM. It seems that the really easy stuff to do, is the hardest and slowest to do in SM. Yet the harder stuff to do in normal languages, is the easiest to do in SM. Which is probably good, and by design?

An example of this is the code used for menus. Say for example you want to have a menu of the C drive. In SM I think that would be quite difficult if not impossible to do because you don't know how many levels of sub menus there would be. I have seen some of the example code here, and although very well done, there is a limit to the number of subfolders you can add. Instead I wrote a small application that simply scans the drive or folder of your choice and creates a menu of what it finds. It creates two files one that has a path to each file found, and one that is the actual menu. Someone else here I think Acrobat came up with the idea for having a listing pointed to by the menu.


Anyways Trog you wanted to see what a 1500 parameter VST looks like...haha
I have been using this thread at the Cakewalk forum to sort of get a start on the manual, but what is written there does not even count for 10% of the full manual size. We have been working on this for quite some time..
http://forum.cakewalk.com/tm.aspx?high=&m=2413293&mpage=1

[Jay]

Nothing to say but,

Well done Ken! for getting of your ass and doing what a lot of ppl claim to do or aspire to do here! glad to see you are not stuck in the world of SM moaners and have moved on! I remember helping you with a basic graphics thing about 2/3 years ago and look at where you are now! bloody great stuff i reckon! keep on doing and bugger everyone else! love the gui's and having tried some of your demo's they sound superb! (not a guitarist,Keyboard player!) they sound great on keys also! how about a dedicated Keys rack?? pleeaase! all the very best m8

regards Jay

[McBarGig]

Thanks Jay...
KeyBoards..
I need to learn a lot about midi, as you may tell I have been concentrating on audio haha. In terms of keys though, I would really like to do sort of the same thing with keys (synths) as we did with head case, but as I say I have a long way to go yet... For learning, I think its just a case of finding "that" project and then seeing where it takes you. I have learned that if you find something that you can be passionate about its easy to get into "feature creep" mode then your own ambitions are forcing you to learn. So "feature creep" is not always a bad thing..
You know how it goes...We are all eternal students I think..

I am really looking forward to being able to use C++ DLL's in SM, Hopefully thats not too far off. Infuzion emailed me today with a link to the FS future updates, and FS is going to be supporting RUBY, from there you can call your C++ DLL's. Thngs could get really cool!

[infuzion]

Infuzion emailed me today with a link to the FS future updates, and FS is going to be supporting RUBY, from there you can call your C++ DLL's. Things could get really cool!

You missed the part that you can use Ruby for green maths, creating graphics, etc. So that will help reduce "trigger flurries", but I don't know how Ruby will affect lag, perhaps just on the VST opening will be slower...

[McBarGig]

I not concerned about lag with Ruby. Even if there is some the improvements on being able to circumvent a lot of other things to improve speed will far make up for it..

[trogluddite]

Hi MBG, it's good to see you back.
And that looks like one hell of an impressive piece of software - I can see why you haven't had much time for the forum lately!
Totally concur with your "create your own dream app" philosophy - once you have a target in mind, you leave yourself little choice than to train yourself to 'jump higher' to clear the hurdles that you find along the way - and those 'OMG I could make it do THAT" moments are priceless.

You missed the part that you can use Ruby for green maths, creating graphics, etc. So that will help reduce "trigger flurries"

Ah well, no need for me to finish the tutorial then!
Seriously though, I am excited about the possibilities if we get the ruby module. I use Google Sketchup for designing at work, which uses Ruby for its plugins and addons - and I am very impressed with what the Sketchup forum guys have been doing with it. Considering the complexity of the 3D maths involved, it seems surprisingly responsive for an interpreted language. Certainly has the porential to really fix up the GUI, user interface parts of SM (hopefully they will tackle the stream parts limitations next!!).

[infuzion]

You missed the part that you can use Ruby for green maths, creating graphics, etc. So that will help reduce "trigger flurries"

Ah well, no need for me to finish the tutorial then!
Seriously though, I am excited about the possibilities if we get the ruby module. I use Google Sketchup for designing at work, which uses Ruby for its plugins and addons - and I am very impressed with what the Sketchup forum guys have been doing with it. Considering the complexity of the 3D maths involved, it seems surprisingly responsive for an interpreted language.

Oh, we still need the trigger tips please. Right now I'm trying to reduce the SM's toolbox's Bitmap Knob, so it is smaller, uses less CPU, less trigger proliferation (esp when automating/changing presets), while still being easily readable & editable. There are a few places where I'm not sure if I am taking the best approach; the trigger tips will help me still.

So, if Ruby is so efficient (I thought it was inefficient, vs C++ & even optimized PHP, it was just fast to develop with), why is Google developing GO language then?

[trogluddite]

inefficient, vs C++

surprisingly responsive for an interpreted language

Note disclaimer and context!

For my money, I think Ruby suits the SM way of doing things.
For the stream stuff that we want to go real fast, we can progress to Code and eventually ASM. But the 'Building in Blocks' idea of the basic primitives/modules building is there to make things easy and more intuitive. Surely that's why people use SM - otherwise why not just go and download the VST SKD and a C++ compiler?
To me, in that context, a language that is, as you say' 'fast to develop with' is a good fit - in keeping with SM's 'intuitive' programming style. Considering that I've only spent a few hours looking at some basic tutorials, I get that feeling about Ruby already - that I will enjoy programming with it; something I never felt with C++ etc.

[attic]

Parsing, I do not do any parsing in SM anymore at all, it is all done externally by scripts, or executables so that I can avoid the triggers.

Instead I wrote a small application that simply scans the drive or folder of your choice and creates a menu of what it finds. It creates two files one that has a path to each file found, and one that is the actual menu.

So how are you activating the external exe or script and what determines when these are activated?

[McBarGig]

Nothing mysterious or advanced..
Onload (or whatever its called in SM) is connected to a shell. The shell runs the executable, or script if you want, I would suggest sticking to executables though to prevent malicious code from being ran from your VST.

Because Head Case has the ability to run scripts, and in fact relies on them. I wrote a simple executable that opens the script file, performs whatever it needs to perform on it, then sends that out to the scripting host. If you wanted to go in depth, you could have the Executable analyze the script for malicious code, but frankly thats way too much work so we're handling malicious code in a different way.

I should also point out that these are "on demand" services, meaning the scripts only run when they need to, like at startup, or when something has changed. A good example of that is our cabinet sims. Each one of them has the ability to create a new IR based on your settings. So, in practice, you have selected a cabinet to use, adjusted the EQ, set the pans, etc...Now you click save and it generates a new IR for you. In this scenario, there is now an additional cabinet that should be in the menu, you just created one, but its not there. So, at this point we would trigger the menu creation executable to run and refesh the listing. The trigger is sent after a certain amount of time, We know how long it takes to create the IR. So Initial save click + predetermined time interval, then run menu creator and reload on the return event(trigger) from the shell execute.

This is old school DOS type stuff and it reminds me of the old days where sometimes depending on what language you had to write in, you would have a million specific executables. It sucked then, and it still sucks now, but at least we get return notifications. In the above scenario sometimes you would have to rely on whether specific files were created in order to tell if an external executable had finished running. I did that with SM too for a while! So any sort of IPC is a welcome advance..

[McBarGig]

Thanks Trog, its nice to see you too, and yeah its been a long year working on that!
haha

[MDMA]

Thanks a lot trogluddite!
This is great stuff, I wish more of these would be made.