Tutorial: Triggers (Part 3)

tor · 28 Aug 2011

Great start 🙂

I admire your dedication to help other people. Looking forward to the following lessons.

infuzion · 29 Aug 2011

Nice Toggie! Too bad you did not post directly to the WiKi... BTW, SM forum has a limit of 3 attachments per post. That is why I pre-reserved many successive posts when I made my module organization tutorial.

stw · 29 Aug 2011

tor wrote: Great start 🙂

I admire your dedication to help other people. Looking forward to the following lessons.

+1

Nothing more to say!! I appreciate that explanation for dummys approach very much. Helped me most 😉

sunsynth · 29 Aug 2011

Much appreciated - and hoping 4 the next ONE!

Well done...

cheers, Walter

trogluddite · 29 Aug 2011

infuzion wrote: Too bad you did not post directly to the WiKi...

Oops, yes - should have linked it from there! Much quicker for me to make a .pdf, I can work on OpenOffice even on my little netbook - lots of easy templates for making bookmarked section headings etc. Rather than use more posts, I will just update the .pdf with the new bits all in one file - if the attachment get too big, I can always host the .pdf elsewhere and link to it (maybe even Malc would be interested to host some of these 'officially' on the SM server?)

billv · 29 Aug 2011

Great stuff. Rather see a whole book though. Why not dump your whole brain into a "couple of hundred pages", print a nice glossy book, get it published and charge us each $50 or so. I'd pay straight up. How many books are there on SM??....Nothing?????.. If you went to the publisher's with the idea they'd probably even finance it as you went along.

trogluddite · 29 Aug 2011

Thanks for the vote of confidence, billy! 🙂 It's a lovely idea, but the trouble is, I already have a full time job (that I really like), about half a dozen SM projects on the go, take dozens of photos every week, twang my bass, whack some drums... - somehow or other, I even manage to have a vestigial family and social life! So for now, I'll just keep plugging away at the .pdf as and when inspiration strikes - when I've got this one somewhere near finished, I will forward a copy to Malc to see what he thinks - maybe they could become part of the official doc's and he'll give me some nice FlowStone freebies!

stw · 29 Aug 2011

trogluddite wrote: Thanks for the vote of confidence, billy! 🙂 It's a lovely idea, but the trouble is, I already have a full time job (that I really like), about half a dozen SM projects on the go, take dozens of photos every week, twang my bass, whack some drums... - somehow or other, I even manage to have a vestigial family and social life!

Oh... so you're the 48 hours a day guy... 😉

If you really want to make some money out of it write a book about social time mangement! I promise you'll get rich in near future... 😈

trogluddite · 29 Aug 2011

He he, I just have to be careful I don't trip over the bags under my eyes!

attic · 29 Aug 2011

I can work on OpenOffice even on my little netbook - lots of easy templates for making bookmarked section headings etc.

OpenOffice works really well for that.

Why not dump your whole brain into a "couple of hundred pages", print a nice glossy book, get it published and charge us each $50 or so. I'd pay straight up.

Id buy it.

If you really want to make some money out of it write a book about social time management! I promise you'll get rich in near future

Id buy this one also. Lol sleeps over rated anyhow.

attic · 30 Aug 2011

I just finished reading the pdf and for someone who has been trying to learn SM, I have to say this was concise and just the type of description I have been needing. I hope to see more and really appreciate it.

Thanks Trog. 🙂

adamszabo · 30 Aug 2011

Great stuff, please dont let this project die! I would buy a full book too, so you already got yerself 150$ 😉

infuzion · 15 Sept 2011

Watch out for Area & Array-building maths; they can exponentially increase triggers. For example, if you want to move a graphic, you will normally use an Area To Float, do some math on the outputs, then merge them back into a Float to Area. Well, every float connection causes a new trigger, so you will have 4+ times the triggers coming out of the Float to Area! Do this a few times & you will get "trigger flurries".

Pro Tip: Keep track of the triggers leaving primitives & modules, & put a few Sample & Holds in the proper points. Sample file: Finishing the multi stage modulation envelope

trogluddite · 17 Sept 2011

Part two of the tutorial is now available in the top post - along with a schematic of the examples used. Sorry it took so long - 'll try to get part 3 out a bit quicker!!

trogluddite · 17 Sept 2011

Updated to correct an error in the examples schematic - Example 1 needed an After Load to generate a background bitmap at startup.

tor · 17 Sept 2011

I have some trouble to grasp how the changed modules work. The 'float equals', compare values from the same source: the 'trigger blocker'. As far as I can see the values that is compared will always be the same and the 'trigger switch' will not be opened. So the 'trigger blocker' would not even be asked for its present value...... 😕

I made an example on how I expectedit to be from what I have learned until now. Though both versions seems to work the same. My modified version on top. Stock version below (shaded):

attic · 18 Sept 2011

@Trog. I haven't looked at part two yet but I know its gonna be helpful so thanks for this. 🙂

Edit: Brilliant. I could understand this! It's concise, simply put and terribly helpful. Thanks.

trogluddite · 18 Sept 2011

tor wrote: I have some trouble to grasp how the changed modules work.

It's all in the trigger flow... Because of the trigger blocker, the equals comparison is forced to happen when a trigger arrives at the trigger switch. The equals will then read the value at the trigger blocker (new value), and the value at the sample and hold. The S & H won't have seen the new trigger yet, because it is still being processed by the comparison/trig.switch, so the value there will be the old value. If the comparison is not equal, the trigger is then allowed through, to update the S&H and the final output - only now will the comparison become equal - but that doesn't matter because the trigger has already passed through the switch and done its work. You could even add a second trigger blocker for the other input of the equals to prevent this unnecessary update of the equals/not combination.

If that's still a little confusing, never fear - for the next installment of the tutorial I am planning to cover 'Changed' modules and Trigger rate reduction. They are the key to the biggest reductions in GUI CPU load, so I will be examining how they work in a lot of detail.

trogluddite · 18 Sept 2011

Just updated the examples schematic again - I had accidentally removed some of the bugs from the 'Bad Triggers' example when I was making screenshots. It should now match up better with the tutorial.

trogluddite · 18 Sept 2011

Part 3 now uploaded to the top post. The new parts add tutorials for the 'Changed' modules and limiting the trigger frequency - both how to use them, and how they work.

attic · 18 Sept 2011

I cant thank you enough for these. Seriously if you write a book on SM you have my money.

bootsy · 19 Sept 2011

thanks man!

trogluddite · 19 Sept 2011

No problem, glad you're finding it useful! Should be some more to come next weekend - I've got a few bits on GUI stuff planned, and I realised it needs a a page or two about the dreaded red feedback loops.

pall · 20 Sept 2011

😀 This is a very good thing. Thank you very much! You do such a thing about coding? 😀 😀

infuzion · 20 Sept 2011

Question: Are trigger connectors forward only? Since there is no value associated with them, then they do not need therefore do not cause a backwards value request trigger?

trogluddite · 20 Sept 2011

infuzion wrote: Question: Are trigger connectors forward only?

Oooh, that's a tough one! To be quite honest, I'm still not entirely sure - I have always assumed that's the case (for the same reason as you - no value to pass). I have tried to test this for sure a few times now, including another little attempt tonight - but devising a test is not simple...

When a primitive returns a value in response to a 'backwards' trigger, it only ever sends the reply back along the same route as the request - and in this case, that would be back to a trigger input, which can't show you if anything changed! That's the big problem with reverse triggers, no way to see where they go - so tracking them is nigh on impossible.

The only way I could think of was to connect it up to some very big counters and arrays, and look for the CPU usage - but nearly all the really heavy duty stuff has a 'do it now' trigger input, precisely so that they won't get triggered by accident. It seems intuitive that these wouldn't do anything in response to a 'backwards' trigger - though I will be adding an 'exceptions to the rule' chapter at some point. During the course of this, I did learn something else that needs a mention in that chapter... Even the array primitives without a 'do it now' trigger input do not generally respond to 'backwards' triggers - I haven't tested every single one, but it does seem like common sense that they are not updated every time something downstream is triggered.

But I'm no closer to an answer about trigger connectors. I tried testing with big nested modules of regular little maths prim's - but I got bored before I added enough to give a measurable dint in the CPU load (even on an Atom CPU). Which may make some people wonder - "why go to all this effort optimising, if the CPU load is so small?".

A few reasons... 1) Triggering GUI ReDraws is not CPU friendly - I have had schematics where the GUI easily outstrips even the audio processing for CPU load. 2) Arrays and big loops will always be greedy if triggered too often. 3) MIDI events create triggers, and they can potentially happen much faster than mouse moves or the tickers (maybe a way there to answer Infusion's question). 4) Much of the reason I use so many trigger blockers etc. is to make a schematic behave more predictably, easier to understand, simpler to de-bug etc. If something is being triggered when you don't expect it, you don't need to search for the problem along links which have been blocked. Similarly, links which are blocked cannot be 'in the wrong order', which makes re-routing links much more predictable when editing.

PS) Although the tutorial is intended as a practical guide, I am planning to ask Malc if he'll proof read it some time, to check the technical accuracy, and see if I missed any other 'exceptions to the rule'.

attic · 20 Sept 2011

MIDI events create triggers, and they can potentially happen much faster than mouse moves or the tickers (maybe a way there to answer Infusion's question).

I'm very interested in the Midi event trigger part of all this. I would really be appreciative of info on that part of the system. I have noticed if I attach a Poly Readout to the trigger counter on the Voices to Poly, and have an adsr way down stream somewhere, the counted triggers wait for the adsr to run out before letting go. I am interested in how and in what ways triggers move backwards through a schematic as the manual leaves something to be desired in most explanations.

McBarGig · 21 Sept 2011

@Trog.. I don't know if this is helpful to you or not, you probably already know this... I asked Malc a while ago about Trigger Flurries, and for me I understand easier what things are if they are explained to me in terms of actual code..Malc told me that trigger flurries are actually function flurries, meaning they are calls to functions. Where the problem for me comes in is that they become cascaded, so, function1 calls function2, function2 calls function3 and so forth. As anyone who develops knows, cascaded functions can become quite a problem if cascaded too deep, and the way in which SM works, a great deal of these calls need not be made at all, which is why the trigger blockers exist. It ends up being the same function called 1300 times, which in turn calls other functions 1300 times, etc.. At least thats my understanding of what Malc said...

My only concern right now is with the loading of presets, we have close to 1,500 parameters and loading a preset seriously slows things down. So what I have done thus far is block all triggers on a parameter change and when the preset is loaded, send out one trigger to all of them. This worked ok, but I was still not getting the speed thats needed, then I connected a trigger switch to the output of the VST preset prim. That improved things greatly because the actual parameter value sends a trigger as well, not just the after change and before change. Sadly though, we are still not getting anywhere near the performance we need...

What I would like to try next is to take all the parameters and stuff them into a VST parameter array where each index represents a knob, an XY position, etc. Then place a numbered GETAT on each of the controls, the number in the get at represents the index in the VST parm array. So you would be sending out a wireless array connection, to a get at.. I wonder if the presence of only one VST parameter instead of 1,500 would make a difference as we don't know what type of calls get made in the "P" subsystem?

The only place this would be a problem is where the VST string prim is used...There is a work around for that too though..

Anyways Trog great work I learned quite a lot with this, thank you..

Thoughts...?

McBarGig · 21 Sept 2011

attic wrote: as the manual leaves something to be desired in most explanations.

Attic, that is an understatement..haha

infuzion · 21 Sept 2011

McBarGig wrote: I asked Malc a while ago about Trigger Flurries, and for me I understand easier what things are if they are explained to me in terms of actual code..Malc told me that trigger flurries are actually function flurries, meaning they are calls to functions.

Have to watch out for that giant McFlurry!

http://thefabulouslifeoflucymoreno.blogspot.com/2010_04_01_archive.html

stw · 21 Sept 2011

McBarGig wrote: My only concern right now is with the loading of presets, we have close to 1,500 parameters and loading a preset seriously slows things down. So what I have done thus far is block all triggers on a parameter change and when the preset is loaded, send out one trigger to all of them. This worked ok, but I was still not getting the speed thats needed, then I connected a trigger switch to the output of the VST preset prim. That improved things greatly because the actual parameter value sends a trigger as well, not just the after change and before change. Sadly though, we are still not getting anywhere near the performance we need...

What I would like to try next is to take all the parameters and stuff them into a VST parameter array where each index represents a knob, an XY position, etc. Then place a numbered GETAT on each of the controls, the number in the get at represents the index in the VST parm array. So you would be sending out a wireless array connection, to a get at.. I wonder if the presence of only one VST parameter instead of 1,500 would make a difference as we don't know what type of calls get made in the "P" subsystem?

Though i did almost exactly the same experiments on speeding up preset changes (with the same succsess) i'm very interested in any news about your findings. Maybe you can post these HERE too?

trogluddite · 21 Sept 2011

attic wrote: I'm very interested in the Midi event trigger part of all this.

Triggers from MIDI events are used to tell the MIDI-to-Poly when you have pressed and released a key, but beyond that, triggers (in the sense of the tutorial) are not involved at all, as the poly sections are pure stream.

A trigger (in a MIDI/poly sense) is a single sample pulse telling a note to begin playing - and just to be really confusing, the trigger counter output from the MIDI-to_Poly is (IMHO) very badly named. It is not counting triggers at all, it is simply a count of how many voices are currently active ('Voice counter' would be more accurate) - if it counted triggers, then surely the value would only ever go up! It's a real shame that the naming has been made so confusing.

There is a connection between the envelopes and the MIDI-to_Poly that carries messages about the current note status, envelope stages, and when to kill a voice. Until ALL of the envelopes within a voice have finished, the note will remain active (and show at the counter output) - unless you run out of voces, in which case notes that are 'releasing' will be first to be stolen.

There is a primitive called "Envelope Control" that gives you explicit access to these signals 'wirelessly', which is used if you want to build custom poly envelopes - but the stock toobox envelopes all have this hidden away inside, so few people ever become aware of it. There's no connector or links used for this kind of data, it's just always there 'invisibly' whenever you are using a poly design.

Since I am an FX man, and tend not to build synths, that's as much as I know - but I'm sure that some of the guys working on the Multi-stage envelope would be able to give you more details.

McBarGig wrote: function flurries

I had a feeling that it must be something like that; so thanks, it's always good to have a hunch confirmed! The 'bad triggers' example from the tutorial schematic shows the effect of the nesting quite well, I think. Just when you think the screen will stabilise as the array fills, yet another trigger from the knob (from many seconds ago) finally arrives, and the whole process repeats itself. While this is happening, the clearing of the call stack makes it impossible to interact with the GUI. In other (very bad!!) designs, I've also known it to stall the audio streams, or even cause the PC to hang (presumably because the stack got too big).

It also contributes to the poor timing of green signals - all new triggers are essentially joining the back of a queue, and if the queue is very long, then even very precise tickers would not be able to guarantee accurate generation of output events. It's for this reason that I've always felt that requests for 'Accurate Green Timing' are looking for the wrong solution - the Green triggers save CPU precisely because they are asynchronous - and an asynchronous system carrying an arbitrary (and very variable) amount of data can never guarantee latency times. I've long felt that adding a synchronous (i.e. stream) way to deal with MIDI data would be a better solution than 'breaking' the advantages of the green system when used for GUI interaction and generating 'constants'.

This is particularly bad in the case of drawing complex GUI displays, e.g. with lots of Draw Loops - they take an age (relatively speaking), and no other green processing can even begin until the entire Re-Draw has completed. This would badly affect green MIDI timing even if the tickers were more accurate or had a higher frequency.

McBarGig wrote: loading of presets

To be honest, I have never used presets for more than a handful of parameters at a time; and I have no idea of the underlying methods used within the VST standard. But it sounds to me as if you are approaching things in the right way - i.e. separate the 'loading' of presets from the 'processing'' of the values by the rest of the schematic, and display updates.

i have used an 'array distribution' system for getting MIDI CC data to knobs - using the array as a lookup table of what controller to send where, rather than every single knob having to filter every MIDI event looking for its own controller. This led to some good CPU savings in a design with 100s of possible controller destinations, so I would say that it is well worth trying for presets.

A couple of other things spring to mind... 1) Parsing - AFAIK parameters are parsed by name rather than position in the preset file. Using shorter preset names and making them more 'unique' may speed up parsing a little. For example, if every preset name were to begin with 'PresetName' then the parser has to read up to the 10th character of every name before being able to tell the parameters apart. 2) ReDraws - if possible, make it so that preset changes don't redraw GUI controls. Multiple small redraws take a hell of a lot of CPU load - instead, wait for all values to be loaded, then trigger a single redraw area that covers the entire GUI. A module with just an MGUI and ReDraw area (no actual graphics components) will refresh the graphics of all modules contained within the same area of the screen, without them each needing an explicit redraw of their own. It doesn't even have to be the topmost layer for this to work (something I'll be covering in a later tutorial).

Good luck with your design - I can't wait to see what a VST that needs 1500 parameters looks like!

tinkergnome · 2 Oct 2011

hey trogluddite.... thanx for that PDF. i know that it will most certainly come in handy, in respect from a few things i recently asked about. 🙂

trogluddite · 2 Oct 2011

tinkergnome wrote: thanx for that PDF.

No problem, glad that people are finding it useful. 🙂

May be a bit of a wait for the next installment, as I have a few busy weekends coming up - but there is more to come...

philter5 · 3 Oct 2011

thx for the update! i can see this book more and more coming....

pall · 3 Oct 2011

Yeah! And a small contribution from me. 😀

adamszabo · 3 Oct 2011

i think we need a proper book on the whole sm and not just triggers 🙂 50$ is waiting in my wallet.

trogluddite · 3 Oct 2011

Very flattering 😍 I think that will definitely have to be the cover - even if only for the .pdf.

Of course, my lame tales of "work", "too many SM projects", "having friends" etc. are all just a smokescreen. Soon after publishing the first .pdf, I naturally realised that if I give away all of my secret knowledge, I might weaken my position as "Supreme SM'er of the Known Universe (and West Yorkshire)" - and thus I might lose my total and utter power over you all!!!

I thought an attachment of my evil laugh would be good at this point- but sadly, mp3 and other compressed audio formats are unable to encode the full extent of my evil.

So have decided that I will only consider writing the book in return for your SOULS! 😈 (Though, I may make an exception if you bring many bottles of the finest Belgian Trappist beer, get me very very drunk, and then distract me with a box of cute fluffy kittens!).

Please contact me by PM if you would like the book but don't have a soul - my body is getting rather decrepit these days, and maybe you have a few vital organs that you'd be willing to 'part-exchange' for a couple of the very finest paragraphs from the 'Author's Choice' compendium.

pall · 3 Oct 2011

From what I see, -among your ranks- feels some fatigue. We all in the forum we are very pleased for what you do, but you have to take care and health. You spend much time on the computer, "missing time during the rest". But maybe I am wrong. 🙂

tinkergnome · 3 Oct 2011

btw......

philter5 ? thats a sweet user pic you got there. i just thought i would mention that. and also,...... i'd like to learn much more about synthmaker and possibly help this forum build a library of knowledge to help future generations of members get into this quickly.

i was going to also ask trogluddite if there would be any problem in my submitting that augmented sampler with the image load button, .... unless someone else has already done that?

trogluddite · 4 Oct 2011

pall wrote: You spend much time on the computer, "missing time during the rest". But maybe I am wrong

He he, you know me too well! - and thankyou for caring. 🙂

Actually, I was a lot worse when I started out on old Z80 machines in my teenage years. I am more fortunate now to live in a different place,surrounded by countryside, good friends and a lot of good live music (and beer) - .I love those things (almost) as much as I love my PC.

I find that a nice walk in the trees, is not only good for the health - the total 'non-technology' environment is often where I grasp the solution to programming problems,find ideas for art, songs etc - without even making an effort, because my head is lost in looking at the beauty of nature.

(If the weather is too bad to go out, I find that visiting the 'little room' for a nice long poo is often good for fixing programmers 'brain freeze'!) 😉

tektoog · 4 Oct 2011

trogluddite wrote: I find that visiting the 'little room'

I play Tetris there, on my old Nintendo DS... 2 days ago, I just beat the CPU in the VS mode... LEVEL 5 !!! But that was after traning for 3 years !!! I'm fulfilled .....

attic · 6 Oct 2011

A Z80 .... how old are you? I turned 40 this year and started on an C64.. to an Amiga then Atari St from there a mac something and finally PC. I didn't start the DSP thing or any type of programming until recently, but have used cubase since the Atari St.

In the spirit of what Trogs doing here I should point all of you to this Digital sound processing tutorial for the braindead! http://yehar.com/blog/?p=121 It reminded me of Trogs easy to understand explanations. DSP in simple terms is not easy to come by on the Web so thanks for the resource Trog and I have 50 bucks or more waiting on the book.

trogluddite · 6 Oct 2011

41 this year. But I still haven't forgotten how awesome it felt to have a real live working computer at home for the first time. Never had a C64, but I remember wanting one - the games programmers for that machine really pushed those old CPU's to the limits; quite incredible what they managed to do with just 8bits running at a few MHz.

Like the link - never found that one before.

attic · 7 Oct 2011

Like the link - never found that one before

That link is the beginning to your book. 😉

stw · 7 Oct 2011

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 · 7 Oct 2011

stw wrote: 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 · 8 Nov 2011

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 · 8 Nov 2011

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 · 8 Nov 2011

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 · 8 Nov 2011

McBarGig wrote: 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 · 8 Nov 2011

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 · 8 Nov 2011

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.

infuzion wrote: 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 · 8 Nov 2011

trogluddite wrote: infuzion wrote: 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 · 8 Nov 2011

infuzion wrote: inefficient, vs C++

trogluddite wrote: 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 · 9 Nov 2011

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 · 9 Nov 2011

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 · 9 Nov 2011

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

MDMA · 16 Feb 2012

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

adamszabo · 10 Apr 2012

When is the next part coming? I want to know more about reducing the cpu on dawings 🙂

trogluddite · 10 Apr 2012

Hmmm, yes - I have rather run out of steam. Mostly, I just don't have the time that I used to. I do have a few half-done bits of examples, so maybe I will just post them as they are instead of waiting until I have time to create a proper .pdf.

infuzion · 11 Aug 2012

Very useful for even an oldtimer like me 🙂

Sorry but I did find a few minor bugs & suggestions: Page 11: The closeup links did not match the zoomed out links Page 14: Did you know there is a 1/x primitive? I'd also per-calcuate 2Pi. They will save both triggers & filesize.

trogluddite · 11 Aug 2012

infuzion wrote: Sorry but I did find a few minor bugs & suggestions

No need to apologise, any constructive criticism is welcome and appreciated - professional publishers run their author's work via a proofreader and editor for good reason. TBH I am quite surprised that there have been so few "bugs" reported!

infuzion · 12 Aug 2012

trogluddite wrote: infuzion wrote: Sorry but I did find a few minor bugs & suggestions

No need to apologise, any constructive criticism is welcome and appreciated - professional publishers run their author's work via a proofreader and editor for good reason. TBH I am quite surprised that there have been so few "bugs" reported!

Do an user search for "infuzion" in the bugs sub-forum, & count 😉

philter5 · 12 Aug 2012

i bet 50 % of infuzions post have been there 😈 ....while the other 50% are split to "Ideas and Requests" (30%) and other topics 😉 Infuzion : ever thought about a carreer as commercial beta tester LOL?

infuzion · 12 Aug 2012

philter5 wrote: Infuzion : ever thought about a carreer as commercial beta tester LOL?

I had; there is a testing company here in Denver that does alot of high-end testing, like for the XBox360, Sony Online, etc...

geekygenius · 16 Aug 2012

Great tutorial!

trogluddite · 16 Aug 2012

You're welcome - glad you liked it. 🙂