Cubase 11 Manual Logical Editor explanations

Sorry, this is unavoidably verbose.
I was discussing a YouTube video by an approved Producer showing incorrect logic in the Logical Editor, and found what appears to be a similar error in the Cubase 11 manual.

The processing is quoted for the Project Logical Editor, but similar Boolean logic applies to the track Logical Editor.

It’s the old problem of mixing ANDs and ORs in the same condition.

The first example on Page 1017 has accompanying text “You can set up the Project Logical Editor to find all audio parts and events whose name contains perc as well as other MIDI parts and events whose name contains drums. ” In fact, the condition as shown in the graphic will find everything containing drums, and will include Audio as well as MIDI parts.

I just tried it on one of my own Projects and that’s what happens.

The second example is correct. If you mix ANDs and ORs you MUST bracket them properly or you get unexpected results.

It is notable that the similar mixed AND and OR examples on Page 1002 are both CORRECT.
The first example makes it clear that the last condition “Channel Equal (to) 1” will select “all events (regardless of their type) set to MIDI Channel 1.”

It’s basic Boolean logic. The difficulties in mixing ORs and ANDs are encountered by new programmers in any programming language.

Both of the Cubase Logical Editors appear to conform to the rules of Boolean logic – that’s why double and triple brackets are available in the “(“ and “)” columns.

Wouldn’t the example on Page 1014 pick up all Parts?
The first line “Container Type Equals Part OR” would select all Parts irrespective of further conditions. I think that the “Length Less than 200 Samples” is disconnected from the first line.
I haven’t tested it, but would if you like.

It would help if the chapter were to mention that texts are available which explain how Boolean logic works.

The 4th example on Page 1011 is correct, but a non-IT-savvy person would likely just zone out at the sight of all the brackets.

I don’t think that the overarching start and end brackets are actually necessary; a structure

((Media type Equals MIDI AND Container Type Equals Part) OR (Media type Equals Audio and Container Type Equals Event)) AND Property … Event is Muted
would have been slightly less opaque. Thanks for your attention. Trevor

Hi,

Could you please send links to the online manual to the chapters, you mentioned, please?

Thanks for replying, Martin Jirsak.

My original communication was with Dom Sigalas , concerning a video of his on the Project Logical Editor. He has very kindly answered and acknowledged the problem.

I took my references from the PDF manual, which is easier to search through. Hence the page numbers. The specific issues I have detailed all revolve around the lack of nesting around multiple Boolean OR operators. Such nesting is functional ; its absence changes the logic and the outcome of a given search.

It would be useful to provide a Boolean logic primer, or at least to point out that there will be third-party pages explaining how Boolean logic works.
Language should be unimportant. Explanations of how IF statements work in VBScript, BASIC, Access etc would all provide the necessary framework.

On the Online Manual, in the original order (I could use 3 monitors here):

Page 1017 maps to: Table of Contents → Project Logical Editor → Filter Conditions → Combining Multiple Condition Lines → Using Brackets

The second Example is correct; the first Example would return Audio Parts as well as the stated MIDI parts.

Page 1002 maps to: Table of Contents → Logical Editor → Filter Conditions → Combining Multiple Condition Lines → Using Brackets

These examples are both correct, although the first one (without the nesting brackets) does not provide a beginner explanation of why it works.
An extra bracket pair [ ‘(’ on first line left and ‘)’ on second line right ] would clarify that the third line is unconstrained by the first two lines.

Page 1014 maps to: Table of Contents → Project Logical Editor → Filter Conditions → Searching for Elements of Specific Lengths

I believe that the first line stands on its own, unconstrained.
So the filter effect would be: Container Type Equal Part OR {a bunch of other conditions}.
The filter shown here would return ALL Parts (irrespective of sample length) plus Events and Audio parts whose length is < 200 Samples.
I’ll try out a similar set-up if you like; I haven’t tested this one but believe that’s how the Boolean logic would work.

The Page 1011 example maps to the 4th example on Table of Contents → Project Logical Editor → Filter Conditions → Combining Media Type and Container Type

This appears correct, but could be simplified by removing the cosmetic outer brackets [ Top left: change ‘(((’ to ‘((’ and bottom right remove the final ‘)’ ].
This would not alter the overall logic, and might make it easier for beginners to understand.

I also noticed Table of Contents → Project Logical Editor → Filter Conditions → Combining Multiple Condition Lines → Bool Column

This has the same problem as Searching for Elements of Specific Lengths . The first line will pick up all Parts, and will NOT be further constrained by the AND filter in lines 2 and 3.
A correct format would be
(Container Type is Equal Part OR Container Type is Equal FolderTrack) AND Position Exactly Matching Cycle PPQ
Again, I’ll try it out if you would like.

Trevor

Hi,

Could you please send the links to the online web-help, like this?

I was unable to find the method of creating the links in the neat form you have shown, due to lack of relevant experience, and and an absence of obvious assistance in the tooltips for the local available actions. I have likely missed something obvious, but can’t see a way of doing it.
The best I could manage was to include the addresses of the pages I am referring to. Nevertheless, I tried all the links and they open the correct pages. Funnily enough, the same links in another post I am contributing to DID revert to the metadata description, but these are not.

I have now supplied three separate methods of getting to the same 5 problematic locations: a) via the PDF, which is much the easiest environment to find required information, b) by descriptions of the index paths to the sections, and c) by clumsy but nevertheless usable hyperlinks to the sections.

Hopefully the locations of the paragraphs may now be determined, and we can move on to the issue of the reliability or otherwise of the relevant help texts and graphics.

See my final post on Logical Editors - Cubase - Steinberg Forums for the detail of one of the Operation Manual entries.
I think I get now how to simplify the Web addresses - you include the bit in [ ] brackets and this gets shown. Unfortunately I now don’t seem to be able to edit earlier posts.

APOLOGIES!

I have to withdraw my issue with Searching for Elements of Specific Lengths (steinberg.help) in which the OR comes first.
The Editor seems to nest the OR automatically, so that the the results are valid.

The same applies to Bool Column (steinberg.help), in which the OR comes first, and which also appears to work correctly.

I’m glad I actually checked these out. I’ll need to find whether this happens in e.g. VBScript; since initial training, I have always nested ORs and assumed that, if they were not nested properly, they would give unexpected and incorrect results.

The absence in the Manual of consistent, explicit nesting of ORs in complex filters, and a User-friendly explanation of how ANDs and ORs work within Boolean logic, are still of concern.

The first example of Using Brackets does not detail why the “(regardless of their type)” qualifier is correct. The effects of the particular combination are described, but not adequately explained. Remember that, when the OR appears first, as in the two examples above which I have withdrawn, the filter works differently. How is a beginner to understand this without a link to the rudiments of Boolean logic, as least as practised in the Cubase Logical Editors?

I do stand by the other example, though. In the case of Using Brackets , the first example returns MIDI and Audio parts whose names contain drums, and not just MIDI parts as quoted.

And the complex fourth example in Combining Media Type and Container Type (steinberg.help) is a missed opportunity to explain about how the brackets work, and not simply presenting the result as a fait accompli. The fact that the very first “(” on the first line, and very last “)” on the last line (which are present by default when the Logical Editors are opened initially) are actually not necessary, and in this case make the appearance of the image of the filter presented in the graphic more complicated than it could be. The page has plenty of unused space which could be filled with useful pointers to why there are multiple brackets at the start of the first line and at the end of the fourth line, why there is an open bracket on the third line, coming immediately after the OR at the end of the second line, why you MUST put your brackets in in matching pairs, etc.
With proper tuition, the Logical Editor could be a powerful tool for many more people.
Thanks, Trevor