DSP Robotics Support

We all know this option exists. It sits in the context menu, when you right-click a module. I also know what it does.

Or do I?

I know of an explanation, what it should do. That explanation came from a user, though. I went through both manuals from front to back, even scrolling through the pages manually after using the find function to no avail. Fact it, there is no explanation about this functionality in the manuals!

So, if anybody can point me to an official DSPR statement regarding the "purgable" option, please do so. Else it will stay an ominous option for the rest of time...

You are right, its not in the manual. Although it needs to be updated a lot to have every info. For anyone who doesnt know, Purgeable means that it wont be included in the exported file. So a comment box thats purgeable, is only there in your schematic while you work on it, but it will be deleted and wont be included when you export your vst or exe.

That's how I understood it.

And that's my point. As funny as it is, it also is a bit scary that we basically fall for an "urban myth". I know it, because another user told it, who knew it from another user, who heard it from that friendly user back then, etc.

Nobody knows exactly what it does, we all just assume that it's true what we heard!

we all just assume that it's true what we heard!

There is no need to assume everything - we can deduce most of it with a reasonably high degree of confidence...

Test1 - Output file size is smaller.
Test2 - No triggers can pass through a purged section.
Test3 - No triggers can originate from a purged section.
Test4 - Purged section stream outputs are always null.
Test5 - Purged section contributes no stream CPU load.
Test6 - Purged section RubyEdits instantiate no Ruby objects.
..etc..

I haven't performed all of the above tests explicitly; but they're all feasible, and I've never seen any evidence to suggest that any of them would fail.

Of course, I agree that it would be far better if the User Guide made the behaviour explicit - but that's also true of a lot of other things that we've had to discover empirically over the years. How do you know that "Trog's Trigger Tutorial" isn't just a collection of "urban myths"?!

trogluddite wrote:How do you know that "Trog's Trigger Tutorial" isn't just a collection of "urban myths"?!

You have a point here

All in all it might not have been as exciting for the community as it was for me. The sudden realisation that I never doubted the explanation, never did any tests to confirm it or at least asked for confirmation, struck me like lightning. Me, a guy who reads the user guide over and over again, regularly consults the reference manual, hunts year after year for hidden/non-documented Ruby functionality (and found and shared quite a lot, which later was added to the user guide). A guy living on a scientific maxime was just taking over a statement of another user, like so.

With a few day's passing, I realize that it may have been more thrilling for me than anybody else

Considering the ongoing lockdown/isolation ... we'll take all the 'thrills' we can get !

You know I could have sworn I’d read this officially somewhere but I looked through the SynthMaker guides too and nothing.

But I found this which is where I think I got it from 5 years ago:

viewtopic.php?f=3&t=2947&hilit=purge&start=20#p18292

Spogg wrote:You know I could have sworn I’d read this officially somewhere but I looked through the SynthMaker guides too and nothing.

I thought I read it too in an official document somewhere but for the life of me I cannot remember.

trogluddite wrote:Of course, I agree that it would be far better if the User Guide made the behaviour explicit - but that's also true of a lot of other things that we've had to discover empirically over the years. How do you know that "Trog's Trigger Tutorial" isn't just a collection of "urban myths"?!

I prefer the term "ancient lore".