Mega Conditional/Rules Patch

This could be done with scripting or by stringing patches together in certain instances, but my want is for conditional/logic patch or patches that have addable inputs. This seems like it would have been obvious for those patches, and it's something that I've thought of for a long time, without ever thinking to mention.

Now, the crazy take on this would be to have something where you could write in conditional and boolean logic statements in plain logic statements, kind of like Hypercard/Hypertalk.

Just some thoughts...'s picture
Re: Mega Conditional/Rules Patch

I've thought about that too.

Generally, I recommend using Math Expression patch. You can make all the logic gates you can think of OR, AND, NOR, NAND etc etc with ||, &&, !

eg: (a <= b+1)? true: false

Tolerances require extra logic branching low case and high case testing which can get over the top in terms of expression length but it works.
eg  ( (a - tolerance <= b+1) || (a + tolerance <= b+1) ) ? true: false

Any expression longer than about 30 characters I tend to put in a JS patch over multiple expressions for clarity when I return to an old comp. I guess that takes a speed hit if it's always evaluating changing values but it's a case of horses for courses.

You probably know all this anyhow just thought I'd mention Math Exp patch, my fav. I often use it where others would favour an interpolation with ext timebase to return a range of values because you can set up the variables just how you want them as opposed to start value, end value and curve shape.

franz's picture
Re: Mega Conditional/Rules Patch

wow !

" ( (a - tolerance <= b+1) || (a + tolerance <= b+1) ) ? true: false " this is REALLY useful. thxx's picture
Re: Mega Conditional/Rules Patch

Thx Franz — a wow from Franz is a big wow indeed!

psonice's picture
Re: Mega Conditional/Rules Patch wrote:
 ( (a - tolerance <= b+1) || (a + tolerance <= b+1) ) ? true: false .

The ? true: false part is unnecessary btw. If you just write: (a - tolerance <= b+1) || (a + tolerance <= b+1) it does the same thing (if it's true, the output is true).

Also, you can nest these conditionals, although it can get confusing.. a > 1 ? true : (a < -1 ? true : false) (outputs true if it's >1 or <-1) (of course there's easier ways to do that ;)

I often use big messy nested conditionals like that for routing, switching a multiplexer depending on input values or adjusting effects in more complex ways.'s picture
Re: Mega Conditional/Rules Patch

Yeah using true and false was to make it clear to somebody who doesn't know the correct syntax for conditionals in ME patch that you can assign a value for True that is != 1 and false that is != 0. I forgot the patch wouldn't publish true and false as inputs — should read:

( (a - tolerance <= b+1) || (a + tolerance <= b+1) )? my_true : my_false
( give a dissertation expect academic rivalry ) ;)

I needed a reaaally long expression once. Dreaming of how I could find it (amongst hundreds of comps) gave me this neat idea for a QC utility or KinemeCore extra whereby you could view and search files as multi-lined text based documents where each patch is indicated with a line (patch constructor and patch title) with a flip triangle where you can drill down into the patch input values and published port names.

So I could search my QC Comps folder for Math Expression patches and get a list of every instance I've ever used. And since the equation gets repoduced in the patch Title I'd see the actual equation on each line of a long list. Hey I could even sort by length!

I guess the idea is a bit like the Hierarchical Viewer idea that gtoledo and smokris have talked about, but I can see it almost as a separate app or window with toolbar and appropriate menu commands that works with .qtz plists like Text Wrangler does with .txt, it could look for differences in files search for patches and notes etc. (My experience with the Spotlight plugin for QC comps is it doesn't seem to find what I'm looking for :/ )

gtoledo3's picture
Re: Mega Conditional/Rules Patch

In general, the main reason for bringing this up isn't for lack of understanding conditional logic - that's an elementary thing; I bring this up because being able to configure both Logic and Conditional patches to have extra inputs would be a time saver, because it requires less keystrokes.

The other thing, and I realize I need to file a bug on this now, is that math expression patch goes awry in SL for me after it's been initially edited, and the inspector is closed, and then reopened. Sometimes, if I enter something like:


After I have closed the inspector and reopen, it looks like this:




At that point, the inspector of the patch becomes finicky. Sometimes I can't edit it, or sometimes it lets me delete all of the expression, but the first value pops back as soon as I start editing again. The only workaround is to place an entirely new math patch on the editor. This happens more often than not.

I was putting together a patch earlier in the week to do something like an atom, and it was really irritating to have that keep popping up. This is something that I think has happened to me as long as I've been using SL actually - I've only recently said "screw it" and converted over to using SL more than Leopard, so I haven't cared as much until now.

Not to side track, because a bug in one patch isn't a great reason to request another.

gtoledo3's picture
Re: Mega Conditional/Rules Patch

Argh. Yeppers, that's what I do now, I just think both patches should be configurable to have more inputs. I knew someone would feel compelled to give a discourse ;-)