"Ignore variations", but for song parts

General discussion about Gig Performer
41

The problem with ignore variations is that it is for every song based on that Rackspace. So if I change something in the heat of the moment onstage in response to some unforseen condition, when I go to another song that is also based on that same Rackspace, and it just so happens that THAT song does not need the same modification I just changed on the previous song, I’m still stuck with it. It won’t revert back to that Rackspace’s saved value.

Yes

Yes, this is the problem

Across a few hundred (or even a dozen) songs, that gets ugly real fast. A lot of time gets eaten up and the potential for errors is crazy. Its also not something that could (or at least should) be done onstage when time is critical

This sounds right I think

42

Solomon definitely gets it!

43

So I think what you’re really asking for is not a new “ignore songparts” flag for widgets.

I think you could accomplish what you’re looking for using the “ignore variations” flag if you could set Songs to automatically set those widgets (or any widgets) to some predefined value when entering the song.

I think that could be done through scripting or an extension now. If it were going to be dozens of widgets across hundreds of songs it would be pretty cumbersome though.

44

We all understand the issue - the problem is around how to short-term solve it until a permanent solution can be devised!

45

Maybe little scripting is doing the job using OSC

// Called when you switch to another song
On Song(oldSongIndex : integer, newSongIndex : integer)
 if InSetlistMode() then
  OSC_SendStringSpecific("/Song", GetSongName(newSongIndex), "127.0.0.1", 8001)
 end 
End

This is the GLOBAL RACKSPACE Script
It just gets the current song name and sends it via OSC to Gig Performer itself.
The Gig Performer Listening Port is set to 8001 in this example and OSC is enabled in the options.

//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
   MIXER : AudioMixerBlock
   A : Widget
   B : Widget
//$</AutoDeclare>

on OSCMessageReceived(m : OSCMessage) matching "/Song"
 var v_song : String = OSC_GetArgAsString(m,0)
 
 Print(v_song)
 
 Select
   v_song == "A" do 
    MapWidgetToPlugin(A, MIXER, 0)
    MapWidgetToPlugin(B, MIXER, 110)
   v_song == "B" do 
    MapWidgetToPlugin(A, MIXER, 110)
    MapWidgetToPlugin(B, MIXER, 0)    
 end
 
end

This is the Rackspace Script
In the OSCMessageReceived callback it gets the current Song Name and depending in this name code is executed.
With GP Script you can Map/UnMap a widget to a plugin.
Unmap is done by using a parameter number which does not exist for the plugin.
In this case an internal Mixed is mapped.
As you can see there are 2 widgets in the rackspace A and B.
Widget A does not ignore variations and widget B ignores variations.
This way you can easily determine on what song what widget is mapped to the plugin parameter.

Here the gig file
IgnoreSongParts.gig (42.4 KB)

1 Like
46

Thank you. The knobs seem to be doing exactly what I’d want them to. I’m not really sure how the rest of it works or how I would use this for every song, but I’ll give it a very good try this afternoon.

47

Let’s look big-picture here. Why is “ignore variations” useful for rackspaces? If I understand it correctly, it’s so that you can have some widgets that vary per variation, and other widgets that are shared across all variations within that particular rackspace, so that modifying them in any variation causes their value to be updated simultaneously in all variations.

It is my opinion that that same logic should apply equally to songpart snapshots: an “ignore snapshot” toggle would allow some widgets to have a shared value across all snapshots of that particular rackspace within this particular song, while other widgets vary per snapshot.

This would be useful for some users in some circumstances. I understand that this might not be useful to very many users and may therefore be a very low priority for the devs, but I do not understand why the same argument doesn’t apply to rackspace variations as well.

I do understand that it would be more complicated that the “ignore variations” toggle. In my view, the correct behavior would be as follows: if i change the value of an “ignore songparts” widget, the changed value should persist when i switch to different songparts within the same song, but if i switch to another song and then back to this one then I should see the last-saved snapshot value, not the modified value. If I want to change the value (for all songparts and for the future) then I need to trigger a snapshot (of any songpart).

That’s my opinion and my reasoning. I agree that I can get this working with scripting, so I’ll get off my soapbox.

48

There are a lot of useful ideas raised all the time. I’ve raised some myself. Implementing them is time consuming and difficult. So, the developers have to prioritize.

49

Looking big picture, the issue with just about anything that has been built over time is that it has been built over time. It has an internal structure in place, and a lot of the things that are added over time are layered on top of the infrastructure that currently exists.

The infrastructure, as best I recall it, was that Rackspaces were the original building block. You wired everything up, put together your panels, and that was your Rackspace.

Variations were a layer on top of that, where different settings of the widgets could be stored. There are aspects of that which a lot of people have questioned over time. A common one is, “Why can’t variations remember different plugin states?” Because that’s not what they are.

Songs and songparts came later. Songparts are little more than a reference to a Variation within a Rackspace.

Snapshots came after that. Snapshots are more or less a “hidden” variation that is unique to that Songpart.

I don’t think the developers have any particular hostility to what you want to achieve with an “ignore songparts” ability.

I think the primary issue is that given many long-time users’ understanding of what songparts, variations, and snapshots are, an “ignore songparts” feature is not an intuitive concept because a songpart is basically a variation, and there’s already an “ignore variations” option. If that’s how one conceptualizes a songpart - just a reference to a variation - then “ignore songparts” seems identical to “ignore variations.”

After spending the time to understand what you’re really looking for I suggested the option of scripting.

I don’t really agree with much of your soapbox speech, but really no reason to get into it. I think you have your short-term solution, and dhj already said “the problem is around how to short-term solve it until a permanent solution can be devised!” I might have considered expressing at some modicum of appreciation while on the soapbox.

1 Like
50

Huh? Nobody is arguing that the concept is not useful — the problem is, as mentioned several times is that it’s not a trivial effort to implement the feature for songs because there is no infrastructure nor GUI support to support the equivalent of the Widget Inspector in the context of songs rather than in the context of rackspaces. So that would all have to be designed.

We get the concept - ignore for song parts can be useful! The devil is in the details.

I know, it sounds so easy – “uh, they have ignore variations for rackspaces so why can’t they just magically make that apply to songs?”

Where would you put it and control it? If there was JUST going to be this feature, then maybe one might have a right-click menu item through which you could turn it on or off. But then you might need a way to quickly see that a widget has that “Ignore” property enabled. But there is no concept of a songpart widget inspector so now you have to have a way to perhaps mark the widget (like we do to indicate that widgets are linked). What should that look like? And we have to make sure it doesn’t interfere with the other indicators (links, radio groups, etc)

Snapshots are literally just arrays of widget values, so that values can be copied really fast. Once we start addin semantics such as “Ignore”, you can’t just copy the array, you have to add new properties and every time you switch to a song part you have to check whether you’re supposed to reset a widget value or leave it alone.

Then someone will argue that widgets in song parts should have separate widget scaling or the ability to define default values independent of the default values configured for underlying variations.

The big picture is that this kind of thing cannot just be ad-hoc thrown into the system without serious consideration for design, implementation, generalization, testing and who knows what other unintended consequences will arise. So it’s a significant time commitment — and then we have to decide what should we NOT implement so that we can do this and what things will a larger number of users care about more?

1 Like
51

The way I see it, snapshots are already the exception to song parts. What’s being requested here is a feature for an exception to the exception, and that’s more granular than is useful in the long run. Either via scripting or reorganizing plugins and rackspaces to more accurately represent the desired changes in parameters–this is the way.

52

snapshots were designed to be just a very light way to reuse the same variation in multiple song parts rather than having to duplicate variations for each possible song part.
So even if you a rackspace with just a single default variation, if it has widgets to turn on or off different plugins, or widgets to control splits or adjust values of various effects, then you can easily create numerous song parts all just using a single underlying variation but each one with different widget values and be extremely efficient.

Once we want to impose other properties, significant new design and implementation is required to make both usable and efficient.

2 Likes
53

@pianopaul I’m trying to test this with my current gig file. Would I need to list all songs in my setlist inside the global script? Or could there be a function that automatically scans and adds all songs?

It seems like I would need to list any widget I’d want to follow these new rules right?

Lets say in the case of a harmonizer key. Right now, if I want to set a new key, I go to each part, change the key, and then capture variation. With your script, I could definitely change the key in realtime and have it persist thru the song, and then upon changing songs, it goes to the other song’s saved value. This is great.

If I did want to save it with the new key, that seems like maybe I need some sort of action that would be “capture variation to all song parts”? Which wouldn;t be part of this script action, or maybe there is a way to actually do this already?

54

Yes, you need to list all songs where you need a special handling.

55

Yes this is necessary

56

Given that a large chunk of existing multi-fx modeler units would want this in every song by default, do you think there’s a smart way to automatically add every song?

57

I think you should think about designing your gig with multiple rackspaces and use Gig Performer as it is designed.
Sure all can be done this or the other way.
You can write complex scripts to use only 1 rackspace with only 1 variation and many songs and song parts.
But in my experience it is more safe to use multiple rackspaces because a little change in a script which deals with all songs can break everything.
And you know nothing is more expensive than regression tests.

1 Like