How to Deal with Algorithmic Generator(s) Downstream

General discussion about Gig Performer
1

Hi.

I’d like to consult with the GP gurus about how I might approach dealing with a situation I’m encountering.

Currently I’m working towards using GP to command my studio, with the studio being thought of as “the stage”. IOW, I want all the smooth switching between variations, rackspaces etc. that GP provides - I’m just not traveling physically with the rig (yet).

Central to my setup is the use of KARMA Motif software (KMo). KMo takes in harmony information (as MIDI chord notes), and other realtime MIDI information (for scene selection, and realtime control of many available parameters, etc.) and generates a sophisticated MIDI performance (like a backing band) which drives a Yamaha MOTIF (multi-timbral) keyboard.

KMo is stand-alone software (not a plugin) and so it resides at the other end of a virtual MIDI port from GP.

Within a single gig/rackspace/variation everything works wonderfully. I can command KMo from widgets and do everything I want to do.

The problem comes when I want to switch variations (or rackspaces).

Simple example: I want to switch to a different variation in order to have a completely different guitar sound while a performance is going on.

What happens is that GP sends a slew of GP-generated MIDI out of all MIDI outs when I switch variations. This MIDI seems designed to deal with plugins and sound-modules, to tie-off their relation with the departing variation, prevent stuck notes, establish relations with the new variation, etc. (I may not have put that technically correctly - but this part of the description is not my central point.)

The issue is that this GP-generated MIDI, when it is sent to KMo, messes up the running KMo performance.

What I need is for KMo to continue running as previously commanded until explicitly re-commanded by me to change or stop.

IOW, it appears, that I need suppression of the on-variation change GP-generated MIDI on the virtual output port which is connected to KMo.

Or I need some different sort of setup in the first place that will avoid this problem.

Thanks to anyone who has read this far. Thanks even more to anyone who understands the issue I’ve described and knows how I can surmount it!

I think we will only see an increase going forward in the use of (commandable) algorithmic generators (like KMo), and so the solution(s) to this specific situation may wind up having uses beyond this specific personal situation. Thanks again.

2

The MIDI Out block shouldn’t just send out messages on a variation change. Variations are mostly to do with recalling different widget values. Do you have widgets connected to midi out block parameters, bypassing them, or widgets controlling other midi plugins on the variation changes?

3

As one example of the outgoing MIDI I speak of, I just opened GP from scratch, did nothing else, and then switched to a different variation. Sent out to the KMo port was a Note Off message for every MIDI note C-2 thru G8 on all 16 MIDI channels.

After I’ve been doing things, there are other messages that go out also.

Do you have widgets connected to midi out block parameters, bypassing them, or widgets controlling other midi plugins on the variation changes?

I will try to answer that when I can get to it.

4

One thing I can add quickly is that I have a full nK2 panel in the Global Rackspace.

Snag_81ba63
Snag_81ba631424×389 55.9 KB

I have it programmed to send desired commands to KMo, and those work great, but if there are specifics about the widgets there that I need to take account of wrt. the issue I’m describing, then so far I have not done so.

5

The widgets on the nK2 panel are connected to the MIDI output block in question.

Snag_9cc378
Snag_9cc3781225×637 112 KB

connected to midi out block parameters, bypassing them

Could you explain what you mean here by “bypassing them”?

Thanks.

6

Yes, there are.

7

Here are some more messages that go out, in the general situation:

Snag_a23544

“All Sound Off”, “All Controllers Off” - I think these may be problematic to be sending to KMo.

8

I note that whenever the blizzard of Note Off messsage occurs it swamps the Global MIDI Monitor display so that most of those messages themselves, as well as all messages that would have been seen before them are no longer seen.

A message type filter and/or a screen-by-screen scroll option would be helpful for troubleshooting here.

9

I meant, are you bypassing a midi out block in any variations?

10

I think I found the culprit!

I fo have a widget to turn KMo on/off.

Snag_b75355
Snag_b753551428×795 203 KB

Accidentally, or by poorly conceived intent (lost in rain, my friends) this switch was Off in some of the saved variations.

Since variations send their widget values upon selection, selection of any of those variations was shutting KMo off.

The blizzard of MIDI output was obscuring the message and keeping this from being more obvious to me.

Snag_b96d1d

I hope that is all there is to it! I’ll report back if it seems not.

11

BTW, if it was desired, is it possible to not send a particular widget’s value upon variation or raskspace selection?

12

When you set the property “Ignore Variation” of the widget.

1 Like
13

That is the main idea of variations: to send widget values

1 Like
14

Gotcha wrt. Variations. Does that apply when changing rackspaces as well?

Also, I appreciate your reply. I shouldn’t have had to ask, having actually read that section of the docs, but not having actually used and relied on the feature, it wasn’t in my “working memory” yet!

15

Switching Rackspaces normally does not force to send widget values.
Widgets are sending value when they are changed, manually or by scripting or by OSC etc.

1 Like
16

The conceptual problem with this concept is that the displayed value of a widget is supposed to reflect the current value of the parameter to which the widget is mapped.

Therein lies confusion if we don’t update the parameter from a widget’s value.

For a simple example of this problem, suppose you have a widget mapped to the volume of some synth and the widget is fully on. But the plugin volume was turned off previously. Now, you switch to a variation, the widget goes full on but the volume doesn’t change so you’re left wondering why your plugin is not working anymore.

1 Like
17

Yeah, and that makes “Ignore Variation” an “at your own risk” sort of thing - only use it if you know why you are doing so (and hopefully have also thought it through in sufficient depth).

I suppose the Widget MIDI tab ‘Follow Hardware’ option is towards the goal of further mitigating the situation, but can only partially do so because the hardware has to have previously transmitted into GP the value to follow and will not in all circumstances have already done so.

We still don’t live in a world where widgets and hardware communicate by ESP :wink:

18

I realized something operational that is going on.

That KMo on/off button is connected to a physical controller.

I touch the physical controller ad hoc to turn KMo on/off as I go about my business.

What I did not realize clearly was that if I turn KMo off this way, that new off state becomes part of the variation, saved in it. Then, if I leave that variation, the next time I return to it, KMo gets turned off. (i.e… right in the middle of a performance - wham!)

Is there a way to have a variation forget about ad hoc changes that take place while it is active so that it will come back online in the “as saved” configuration when I leave it and then later return to it?

19

Use SetList Mode

All very well documented in the user manual.

2 Likes
20

If you are in a song part and move your widgets (knobs, sliders, etc.) changing their values, and then switch away from that song part - all the changes in that song part will be lost and reset to the values of the underlying variation.

That’s the behavior I’m looking for!

I’m still working on my first couple of rackspaces and variations, haven’t even approached songs and setlists yet.

Onward!