Project Logical Editor - I still don't understand brackets (specifically multi-brackets)

I get what they do, what their overall purpose is… to essentially bundle OR conditions together into a single “condition-group”,

but I still don’t understand the, I guess, topology of the brackets - specifically multi-brackets.

I’ve looked at the manual, but it’s fairly short, and I don’t really understand. It would probably be more useful to see a flow chart, than it would an actual PLE preset.

Take for example, this preset example from SoundOnSound article:


(https://www.soundonsound.com/techniques/logical-editor)

I get, that ‘MediaType-Equal-Audio’ needs to be bundled to its own conditions because it has both ‘Events’ and 'Parts. I just don’t understand why the particular multi-brackets were selected where they are in the script…


And I’m unsure, if for instance in this example… if this script needs to be in this exact order? Or could it be arranged in a different order?

I also don’t understand - exactly - what this phrase in the manual means? I understand what it is alluding to, but I’m having trouble visualizing exactly what it means and how it translates to bracket use in the PLE itself.

If you add several layers of brackets, these are evaluated from the inside out, starting with the innermost brackets.

Expressions within brackets are evaluated first.

(https://steinberg.help/cubase_pro/v10.5/en/cubase_nuendo/topics/project_logical_editor/project_logical_editor_brackets_using_r.html)

Thanks

Not that I’m any good with the editor, but this example I understand. The parentheses “bundle” the statements.

The first statement (3 open parentheseis to first closed parenthesis) says “MIDI parts”.
The second (lone open parenthesis to two closed parentheseis) says “Audio Events or Parts”.
The third statement says “Event is muted”.

The first two statements are each enclosed in parentheseis. (1) (2). But, in order to be evaluated against the third one they both have to be in parentheseis as a whole. So a second pair, on top of the first two. ((1) (2)) And then, we have another pair for the whole statement. (((1) (2)) 3)

If for example we changed it to ((1) ((2) (3)) I suspect (if the action below would be select) that it would select ALL midi parts or All Muted Audio Events or Parts.

EDIT: Removed diagram because it had an error - hopefully the one in my post further down is correct.
:nerd_face:

hmmm, all the paths lead to no?

@LoveGames
sorry - mistake in the diagram

hopefully this is right:

Still don’t get it. Sort of get it, but I don’t firmly grasp it…
I understand enough that if a PLE isn’t working I can I would start mucking around with the parenthesis emulating this particular script until it works… But I don’t understand it enough that I could think of a multi-bracketed PLE while driving home in the car.

I’m not sure if the flow chart really helps as much as I thought it would either.

It’s just the parenthesis language/protocol I don’t really get. Maybe I need to visualize them as sort of modules within modules.

So, the PLE is limited to 3 deep? wait, I think I’m starting to get it.

I actually don’t think a flowchart is a better way of understanding this way of representing things, because it’s an entirely different way of thinking about it. I just did it, because your comment made me curious for myself.

A much simpler way to grasp it is relatively straigtht forward algebra.

Are you comfortable with how parenthesis work in regular algebra? e.g.
((7+3)/2)+(6*(3-2+5))

If you’re comfortable with that, then these parenthesis work exactly the same way. You effectively do a temporary calculation for the innermost parenthesis first and then work your way outward.

Except that this is kind of a special algebra (called boolean algebra), which works with true/false (yes/no) only.

With regular algebra you remember that 3+2=5 and 10/5=2. and all of those addition/subtraction/multiplication/division tables. And that’s all you have to know to calculate more complicated expressions with lots of brackets, by working your way from the most inner brackets to the outer one’s .

To do that boolean algebra you have to remember only a few very simple building block calculations:

true AND true = true
true AND false = false
false AND true = false
false AND false = false

true OR true = true
true OR false = true
false or true = true
false or false = false

Each line in the PLE has a true or false answer, when Cubase looks at an individual object to decide if it is to be selected. And then you evaluate all of the true and false combinations with AND or OR going from the innermost brackets working your way out.

So for example when the current event Cubase looks at is a Muted Audio Part, then the 7 lines would evaluate like this

(((False AND
True ) OR
(True AND
False ) OR
True )) AND
True )

or put on a single line:

(((False AND True ) OR ( True AND False ) OR True )) AND True )
and now we work on and remove the innermost brackets first
(((**False AND True** ) OR ( **True AND False** ) OR True )) AND True )
evaluating and removing the now innermost brackets next
(( ...... False ....... OR ( .... .False ........ OR True ) AND True )
keeping going
(( ...... False ....... OR ......................True ... ) AND True )
more parenthesis to go
( ................... True ............................. AND True )
and the last step gets us
True

Yes indeed we have a found a Muted Audio Part (since that’s what we decided to simulate).

While this way of doing things takes a little getting used to, it’s the most common way of telling computers how to select things. So once you get comfortable with that way of thinking, a whole world of scripting software opens up for you. The initial pain can have significant rewards, if you’re intrigued enough. Not every musician is and that’s ok, too.

p.s. I hope I didn’t make a mistake like I did in the first flowchart attempt. But if you find a mistake, it would mean that you totally understood! :smiley:

I think this maybe works

Or it’s this, not 100% sure which makes more sense

1 Like

I think the second one makes sense, because the Audio and MIDI bundle conditions are both part of the inner most parenthesis with the Audio ‘(’ parenthesis signifying an additional condition within the first bracket.

More of a visual learner than mathematical/textual

1 Like

Either way - I think you got it!

Shouldn’t the final blue ) bracket be ))) in this example though?

But maybe it doesn’t matter as the PLE will just stop as soon as there are no more lines of script?

no, since the other 2 brackets were already closed previously.

Ahhhh, makes sense. Now I’m getting it

And I tested, it doesn’t work… actually results in a bug which will break your PLE script.

you’re well on your way to becoming a real bracketologist! :rofl:

Still not %100 sure my diagram is correct

If the MIDI ‘)’ closing bracket closes the first ‘(’ open bracket, then is the Audio ‘(’ re-opening the first ((’(’ bracket allowing an additional condition or, is it opening the second (’(’( bracket and thus, Audio also closes with the second )’)’)

Because this is a major difference in scripting I should probably clarify… the first would allow infinite re-opens on the first bracket, whereas, the later would indeed mean there is 3-deep limit…unless… can you multi-bracket within multi-braket??? hmmmmmmmmmmm

a right bracket always closes the most recent open bracket.
a left bracket always opens a new sub-expression)
there’s no such thing as re-opening an already closed bracket.

Think of bracket pairs as envelopes, much like in your diagram.
You can have one or more envelopes in another envelope. And each of those can have one or more envelopes inside.

Envelopes is a good analogy… Except with PLE things open from the innermost… So you are inside the deepest envelope trying to claw your way out - lol.

Hmmmm okay, then I think this is the proper graph.

Or actually, maybe this is more accurate

you are sooo right - with increasing numbers of envelopes, the thinking becomes disproportionately difficult.