Boolean operators (NOT, AND, OR) for Playback Technique Combinations?

[RRComposer]

When selecting a Playback Technique Combination for a Base Switch or Technique Add-on Switch when building an Expression Map, is it possible to create more complicated expressions using boolean operators?

I’m currently building a (complicated) Expression Map with 8 custom Playback Techniques; A0, A1, A2, A3, B0, B1, B2, B3; exactly one of the A’s will always be on and exactly one of the B’s will always be on.

Ideally, I want to set up four switches triggered by these specific combinations of my custom Playback Techniques:

A0 AND B0
A0 AND (B1 OR B2 OR B3)
(A1 OR A2 OR A3) AND B0
(A1 OR A2 OR A3) AND (B1 OR B2 OR B3)

Or, equivalently:

A0 AND B0
A0 AND NOT B0
NOT A0 AND B0
NOT A0 AND NOT B0

If the answer to my question is no, then I suppose I’ll need to set up a switch for each disjoint combination:

A0 + B0
A0 + B1
A0 + B2
A0 + B3
A1 + B0
A1 + B1
A1 + B2
A1 + B3
A2 + B0
A2 + B1
A2 + B2
A2 + B3
A3 + B0
A3 + B1
A3 + B2
A3 + B3

This is a little inefficient, so I’m reaching out to see if there’s a better solution. Thank you.

[benwiggy]

Do the Mutual Exclusion groups in the Expressions map help you at all?

[RRComposer]

Hi @benwiggy, thank you for the suggestion.

I was actually already using Mutual Exclusion Groups, one each for {A0,A1,A2,A3} and {B0,B1,B2,B3}, so that only one Playback Technique from each group would be active at any time. I’m sorry for not mentioning that initially.

If anyone would like to help me try and find a solution, I’ve set up a sample Dorico file (Boolean operators (NOT, AND, OR) for Playback Technique Combinations.dorico) with the eight above-mentioned custom Playback Techniques.

The Expression Map (named EM) has eight Technique Add-on Switches,

with Mutual Exclusion Groups for {A0,A1,A2,A3} and {B0,B1,B2,B3}.

This currently sets CC2 to {25,50,75,100} and CC3 to {25,50,75,100} for the A’s and B’s respectively (just to make it easy to see that they’re being activated correctly).

To achieve the objective stated in my first post, I can set up 16 new switches

and setting the CC4 values to {25,50,75,100} appropriately, I can get my desired results.

The question is whether this can be achieved more efficiently, by creating four new switches rather than 16.

As I type this, it feels like the answer to my question will be “no”. This attempt,

doesn’t work (well, A0 + B0 works but the others don’t). This seems to be because, for example, A1 + A2 + A3 + B1 + B2 + B3 is interpreted as

A1 AND A2 AND A3 AND B1 AND B2 AND B3

and with the Mutual Exclusion Groups for {A0,A1,A2,A3} and {B0,B1,B2,B3}, this is impossible. If I could have this interpreted as

(A1 OR A2 OR A3) AND (B1 OR B2 OR B3)

then I think I could get what I need.

Anyway, unless anyone has a further suggestion, I can live with implementing the 16 switches as a workaround. Thank you for reading.

[RRComposer]

For anyone reading this in the future, I eventually gave up on getting this to work.

Firstly, I was having trouble getting my “Combined Playing Technique” Add-on Switches to correctly activate in my Expression Map. Even though this worked in my dummy example posted above, it wouldn’t in my larger, more-complicated, Expression Map (with lots of other Add-on Switches). I found a post from Daniel (Add-on Switch Weirdness - #2 by dspreadbury) suggesting that “Add-on Switches that define a combination of two or more playback techniques are not evaluated”, at least in Dorico 4.2, so that may have been causing problems.

Secondly, I realised that it was somewhat cleaner to simply only set up 16 custom Playback Techniques to activate the 16 switches mentioned above (A0+B0, A0+B1, etc), and for each of these switches send 3 CC messages (one for the A value, one for the B value, and one for the combined value). This did mean a lot of switches, and some redundancy of information, but it worked reasonably well.

Thirdly, I found another post from Daniel (Expression Maps: How are switches selected? - #4 by dspreadbury) containing a useful description of how Expression Maps decide which switches to use. This made it clear to me that my request wouldn’t work with the current algorithm, which looks for the “best” Add-on Switches rather than necessarily activating all valid Add-on Switches. The corollary of this is that Add-on Switches need to be distinct to guarantee selection.

Finally, I discovered that I didn’t actually need these “combined switches” anyway, so swiftly moved on.

[Brian_Roland]

Have a look at bidule? I’ve been using the registered plugin versions (VST2/VST3/AAX/AU/CLAP) to solve these sorts of situations (and more) in many hosts. Bolt on never had it (and maybe never will) features at will.

It’d have all the tools you need to accept something like a program change or key switch, and do all sorts of round robin ‘conditional rerouting’ of the MIDI flow to plugins/MIDI ports/channels of your choice. You can easily build and trigger custom MIDI events. Has arp and looping tools (both MIDI and audio). Even has OCS server/client abilities (communicate among different devices and/or bidule instances over the network).

Not only will it allow you to monitor and transform MIDI/VST/Audio events in real time…it’ll also allow you to mix and match all of your plugins into one ‘super plugin’. I.E. Mix and match sounds from HALion, Kontakt, Opus, and more at the same stave endpoint, as if it were a single unified plugin. It’s also great for importing/exporting a uniform instrument template among all your hosts.

The list of things bidule can do is way too long to summarize here. Been using it for years now, and it’s easily the most used plugin in my toolbox.

At the top of my list, specifically for Dorico…

1. Mixing and matching different instrument plugins from a single stave.

2. Correcting various issues or shortcomings with Dorico and Cubase expression maps. One of the first was way back with Dorico 1. I could get better control of phrasing translation (legato and portamento implementations).

3. Syncing audio files with the Dorico transport. A sync bidule can post a realtime ASIO sample count. This can be used to trigger wav/aiff files at precise times (use simple math bidules to create the desired sample number offset) and keep them in perfect sync with Dorico’s transport (even if you start/stop the transport somewhere in the middle, or jump around and start/stop playback from different points in the score…bidule keeps the audio file in perfect sample-to-sample sync). In some hosts (All the pins aren’t active in Dorico yet) the sync bidule also keeps up with the tempo, time signature, pulses with each new beat, each new bar, etc. So the potential is there to put together some pretty smart instruments of your own design.

4. Easy porting of entire instrument templates among different hosts.

5. Sometimes my templates get a bit too big for my main machine. I’ll host a bunch of stuff in bidule on another machine and treat it kind of like an instrument server. (A disadvantage here, as compared to a true networked instrument server like Vienna Ensemble Pro, is that rendering a single audio file of a project has to be done in real time).

6. Seeing/monitoring all communications between the host, bidule, and whatever is hosted therin. Amazing diagnostics and trouble shooting tool.

Another very common use is bridging different plugin types together. Use VST3 plugins in a VST2 only host, or vice verse.

You can get really creative…
Imagine being able to not only bunce channels, but to bounce to a whole new plugin instance from a single stave! You could have a violin setup for slow tempos, another for medium, and yet another for fast. Just send a CC or something to swap the entire instrument pallet for the stave, just like that! You could even mix and match the templates from several different plugins/instances. Someday Dorico might hook up those tempo and time signature pins (Cubase already sends that info), and then you could build instruments that’d get some really cool ‘tempo/dynamic influenced’ score translations on ‘autopilot’.

[RRComposer]

Thank you for the suggestion, @Brian_Roland. I know almost nothing about Bidule, but it seems very interesting to me. Do you mind if I challenge you to solve the specific problem of this thread?

Take the example from my second post above (Boolean operators (NOT, AND, OR) for Playback Technique Combinations? - #3 by RRComposer), with Dorico sending CC2 ∈ {25,50,75,100} and CC3 ∈ {25,50,75,100} through the Expression Map.

Could Bidule use these incoming CC2 and CC3 values to calculate the following?

CC4 =
25 if CC2==25 and CC3==25
50 if CC2==25 and CC3!=25
75 if CC2!=25 and CC3==25
100 if CC2!=25 and CC3!=25

If so, could you briefly show me how this would be achieved?

[Brian_Roland]

Yes, it can do that. I’ll post screen shots and project files when I am back at my desk.

[Brian_Roland]

@RRComposer

If so, could you briefly show me how this would be achieved?

There are many ways to approach this. Since your example doesn’t require keeping up with ranges, or sending a steady stream of CCs from something like a live controller I’m taking a very simple and direct approach. Here’s what I came up with in my near brain-dead state this morning.

Booleen CC Challenge 3.zip (4.9 KB)

In this state the group bidule starts out with CC2=0, CC3=0 events in the cue, so it spits out CC4=100 on launch (or when it’s first terminated with a connection (I.E. to your instrument plugin instance). If you decide you don’t want it to send that first CC4 event, or if you’d rather it be something different at first, just let me know. It shouldn’t hurt anything as is. Whatever you establish in your Dorico Expression Map as the init base key should over-ride/change it without issue.

Any time a CC2 or CC3 event is sent by your host it should send the proper CC4 event. If something is repeated, it should send it again. Note, in this form the bidule remembers the last event for each CC, so you don’t have to send it in pairs every time to change things. If you need for it to wait until it has received CC2 and CC3 in pairs (Don’t send anything until a CC2 event followed by a CC3 event passes through), let me know. I’ll have to rethink it a bit. I’d probably recommend treating it like a general MIDI NRPN, which involves a 3rd CC. It’d be simple to implement…not requiring much more than another MIDI gate, and a Booleen Logic Gate (I think).

When the bidule project opens, you should find that it opens a simple MIDI CC controller that I’ve built, and two MIDI Monitors.

You can test how it behaves by clicking the four CC buttons.
I.E. Click CC=25 to send a CC25 event.
You can also change the MIDI channel in the mini controller via pop up selector.

You can save the RR Composer’s Booleen CC Challenge as a bidule ‘group’. This way it’s easy to pull that into any project you happen to be working with. Just plug it in line between your host MIDI output, and your plugin/instrument.

To see inside the bidule group, hold ctrl and double click it. You might like to open the Challenge bidule group to see the ‘red’ monitors in action as you send CCs.

[RRComposer]

Thank you so much, @Brian_Roland. You have gone above and beyond the call of duty!

This proves that Bidule can indeed reproduce the effect I was looking for; the ability to effectively construct base switches from boolean expressions of playback techniques. Very impressive!

I am probably unlikely to start using Bidule, because (a) as stated above it turned out that I didn’t really need to do this anyway and (b) I’ve spent many months working on my massive Expression Map, and I’d want to start over to utilize Bidule properly. Maybe in a few years when I inevitably re-think my set-up, I can look into this more carefully and decide if it’s the way I want to go.

But thank you again, @Brian_Roland. I’m sure that a lot of people will appreciate your response.

Interestingly, I already own a Bidule-like application known as Gig Performer. I notice that @gigperformer is a member of these forums, so would like to ask if something like the above could be achieved. I’m not too familiar with the capabilities of the MIDI Processing and Monitoring plugins, but maybe Scriplet could do the job?

However, I don’t suppose I can use Gig Performer as a VSTi anyway, unless I’m missing something.

[gigperformer]

@RRComposer

I’m not too familiar with the capabilities of the MIDI Processing and Monitoring plugins, but maybe Scriplet could do the job?

I haven’t looked closely at what you want to do but GP Script is a Turing-complete language so it can in principle do any kind of MIDI processing you want.
That said, there are several other ways to perform arbitrary MIDI manipulation depending on your needs.

1. I saw you mentioned Bidule which I don’t know too much about. But you can use MaxMSP with Gig Performer to do arbitrary processing. In fact, when GP was first developed, before we designed GP Script, that’s exactly what I used to do and the original reason that we implemented OSC in GP was so that MaxMSP and GP could easily communicate with each other and I used that approach on tours for several years during the early days of GP
2. There is a free VST called PlugData that is based on PD (open source version of Max) but with nicer graphics and you can use that inside Gig Performer to manipulate MIDI (and audio for that matter)
3. GP has an SDK that allows you to write extensions in any language that supports C headers (most use C++) and you can receive incoming MIDI, modify it and return it, etc.

@RRComposer

However, I don’t suppose I can use Gig Performer as a VSTi anyway

We made a serious philosophical decision a long time ago that the needs of the musician should remain separate from the recording process.

@RRComposer

unless I’m missing something.

Yes, you are - we have a plugin called GP Relayer and you can insert that into a track of any DAW (except ProTools) and route audio/MIDI bidirectionally between GP and your DAW

[Brian_Roland]

@RRComposer

This proves that Bidule can indeed reproduce the effect I was looking for; the ability to effectively construct base switches from boolean expressions of playback techniques. Very impressive!

Don’t forget that you can grab the stand alone version for free. You’d need to register to get the plugin versions, but the stand alone is quite sufficient for having a look around. It also supports REWIRE, and you can also use virtual MIDI ports to make some magic happen among many different apps. In fact I start up a stand alone instance every time I boot…grab all my MIDI Contollers, and make them a lot smarter. They get directed to virtual ports for my hosts to pick up and use from there. In Windows world, this solves a bunch of ‘Windows’ issues with USB<>MIDI drivers that don’t play nice with multiple clients (the virtual ports don’t have a problem with multiple clients).

This challenge, not even scratching the surface on bidule possibilities. You can manipulate the audio stream too. You can build synths and samplers, and audio effects. You can work with higher resolution VST style ‘parameters’ along-side, or in lieu of MIDI (and easily convert back and forth), and link it up with VST parameter lanes in your DAW.

At first it’s kind of slow to use as you learn your way around the object oriented UI. A coder will notice right away that they can type quite a few lines of code faster/easier than messing with the bidules and virtal cables…but there’s nothing quite like the object approach to inspire and try out ideas; plus it makes it accessible to those who don’t code much (or at all). Over time you start to pack more of your general math/logic bidules into groups that you can reuse and it saves a ton of time. You can also get the sdk to compile bidules using a more traditional ‘code and compile’ method.

For years I didn’t use it for much more than a simple plugin chainer, and as a bridge to greater plugin support (I.E. Getting VST3/AU/AAX/CLAP only plugins into VST2 only hosts like Sibelius/Finale/Band In a Box). And to monitor MIDI/Audio streams for simple fixes like you Challenge. It paid for itself many times over…even if just for those basics. It can do so much more though.

I call it my ‘Swiss Army Knife’ plugin.