Synth Patch Change via Variation or Rackspace?

[progster]

Hi.

If my goal is to have a different patch (preset) ready-to-go on soft-synth (synth plugin), can I do that with a Variation, or do I need another Rackspace?

In the case where my soft-synth can respond (via it’s own UI) essentially instantly to a change in preset, it seems like it would be desirable to be able to work with it without having to have the plugin loaded into memory multiple times. IOW, with a Variation, rather than a separate Rackspace.

However, whether that is possible is a bit unclear to me, so I would appreciate guidance on this subject. Thanks!

[dhj]

@progster

In the case where my soft-synth can respond (via it’s own UI) essentially instantly to a change in preset

Yeah, be careful about that — clicking a mouse in a UI is far slower than what needs to happen if you send a MIDI message to change something, for example, in the middle of a beat, which is something that can be done by switching rackspaces.

There are various ways to do this, depending on whether your plugin supports program changes or whether one is willing to use GP Script

See this article

Rackspaces vs. Program Changes - Gig Performer®

[progster]

Excellent article. Thank you!

After reading it and experimenting a bit, I’m 98% convinced to just give up on the idea.

I do have a question though.

Suppose I had a source for PCs sending on Ch1, and another source for PCs sending on Ch2.

Could I have the Ch1 PCs control Rackspace selection and have the Ch2 PCs be sent to directly to the synth without having any effect on Rackspace selection?

It seems to me that incoming PCs are either all affecting Rackspace selection, or none of them affecting Rackspace selection (per GP Global MIDI settings) with no ability to distinguish by channel. Am I understanding this correctly?

[progster]

And, same question wrt? different input devices, rather than different channels.

Can PC source A control GP, while PC source B controls a plugin preset?

[pianopaul]

In the global MIDI Options you can set that PC messages are only accepted from specific devices

[progster]

@pianopaul

PC messages are only accepted from specific devices

Yes, but does that mean “accepted for control of GP” or does that mean “accepted at all for passing onward to plugins”?

[pianopaul]

You are right with your question, with this option PC message only coming from the selected device are coming in.

But why do you need PC messages for the plugins?

[progster]

I’m working with the ideas in the article dhj has referenced above.

I’m just ringing out what I might or might not be able to do with that approach, if I were to prioritize saving memory.

At one point, the article states:

There is an option to allow PC events that don’t correspond to rackspaces to be passed through to plugins (via MIDI In blocks) but that requires care to make sure that you don’t use the same PC values for both rackspaces and plugins.

What I’m trying to understand is, does that mean PC 01, regardless of channel, regardless of source device, can only be used for either GP control (i.e. Rackspaces/Variations) or synth preset control?

Or is it the case that by distinguishing either according to channel, or according to source device, I could use PC 01 for both GP control (i.e. Rackspaces/Variations) and synth preset control?

[pianopaul]

I am not aware of deciding what channel is used.

I avoid changing presets in plugins via PC messages, I am using different rackspaces and with use of predictive load you can save memory.

[progster]

@pianopaul

I avoid changing presets in plugins via PC messages, I am using different rackspaces and with use of predictive load you can save memory.

Yes, the article makes clear why that would be generally preferred. I don’t disagree.

I’m just trying to know clearly what’s possible or not, in case memory conservation becomes an overriding priority.

[progster]

Here is a working solution I found, for Arturia synths, using the PIZ midiConverter3 plugin.

Provided you don’t have the originating controller (Linn 128 in this case) active for PC control of GP in GP’s Global MIDI Settings this does effectively decouple the generated PCs from GP itself while sending them directly to the soft-synths.

With Arturia soft-synths, you have to be using the VST (not the VST3) version of the soft-synth, and have a Playlist defined and active. When all configured thusly, the control surface (sending Notes) commands the presets of the soft-synth(s) Playlist. Works very nicely.

Why do it? Well, if you are a choice junky, and want to have up to 128 sound choices instantly available by touching a control surface, without creating 128 Rackspaces for them, this approach will accomodate.

[progster]

Here is how to set the midiConverter3 to map 128 note-on messages to 128 PCs:

Enjoy!

[dhj]

FYI, a simple scriptlet in GP can do this

// Convert incoming Note On message to program change
On NoteOnEvent(m : NoteMessage) 
var
   pcMessage : ProgramChangeMessage = MakeProgramChangeMessageEx(GetNoteNumber(m), GetChannel(m))
   SendNow(pcMessage)
End

Download this and drag it into a rackspace to use.

NoteToPC.gpp_internal (1.0 KB)

[Hermon]

I’m interested in this scriptlet (to replace pizmidi converter too) but I don’t understand how it works. Is there a tutorial or detailed article in the forum or blog?

[dhj]

That scriptlet, which is only 4 lines, is not a replacement for the PIZ Converter, it is solely to convert note on messages to program changes.

You can just use it by dragging into a rackspace.

[Hermon]

So I can use this scriptlet to change a PC from a MIDI note?
I don’t know what to do once the scriptlet is in a rackspace window: do I need to connect it to a MIDI block, an Instrument, do I need to use a widget…
That’s why I was asking if there was a tutorial or an explanatory diagram.

[dhj]

Just think of it as a plugin (which it basically is) — so it has a MIDI Input and a MIDI output — send your notes into it and program changes messages will come out of it.

Use it exactly the same way as you’d use that PIZ plugin

[progster]

Very nice little scriptlet - direct, small, and illustrative of a technique that can be used for many specific purposes. Thank you.

Q: How did this scriptlet wind up with the .gpp_internal file extension?

I thought the normal scriptlet edit/compile/save process resulted in a .gpscript extension.

[dhj]

@progster

How did this scriptlet wind up with the .gpp_internal file extension?

It’s a scriptlet, not a script.

Scriptlets are essentially plugins and you can save them as user presets and so they automatically go into the appropriate sub folder associated with the plugin

[dhj]

@progster

I thought the normal scriptlet edit/compile/save process resulted in a .gpscript extension.

Actually, that is only if you want to save the source code for reuse somewhere else. Normally, when you create a regular script, you don’t need to explicitly save it, it gets stored in the gigfile.