Roland Sound Canvas VA freezes / Lost Program Changes


Ok, this works a little bit better. Some channels get the right PC (and some not). But is there a way to say GP on this MIDI-In and that Target Device all PC envents must pass to the target device and all PC envents coming from GP are ignored? The option “Pass unused PC messages” is a little bit inaccurate / confusing.

When understanding correctly, GP uses PC events for the internal switching between different variations. But there must be a way to define clear exceptions, or?

You can define which midi device is accepting pc messages
2nd screenshot there is a poplist

Ok, I (think I) understand the idea of mapping the PC events which are coming from the master keyboard.
The Keyboards sends PC 1 0 0 and
to PlugIn 1 “PC 1 0 12” is sending and
to PlugIn 2 “PC 2 0 7” is sending to get the correct sounds for the different PlugIns.
Is this correct so far?

What are the plugins?
But why not use different rackspaces and get rid is pc changes in the Plugins?

It is correct but the thing is, that way is really only for “legacy” approaches to GP and you lose functionality such as Patch Persist. Our experience is that users coming from older systems such as Forte or directly from just using hardware try to replicate that model with GP, which is really not a good idea.

The right way to do this is to duplicate the rackspaces and in each rackspace, configure the plugins to the sound you want. Then when you want a different sound, you simply switch rackspaces – no program changes are involved other than the single program change you use to switch rackspaces in the first place.

1 Like

Accept PC from … means only for the GP variations management? If yes, I had to remove the midi port where the PC events from the arranger comes is. So these events can not activate another variation of the rack. Correct?

As Arthur Hailey once wrote, “Mistrust the obvious”. If we were back in GP1 days (5 years ago), I might have agreed with you as at that time our code was still evolving to properly implement the plugin APIs (and also including hacks to work around bugs in actual plugins).

The thing is, Gig Performer uses much more of the plugin API than do many other hosts. Many plugin developers only test their code against a few hosts and if those work, they think they’re done!

As of GP 3.8 (which has been out for several years), I don’t think we have seen a single crash/freeze with a plugin that was not due to a problem with the plugin itself. You’d be surprised at some of the things plugin developers “forget” to address because of assumptions about how the hosts work.

I would encourage you to report the Sound Canvas issue to Roland. We have a good relationship with them and they have access to Gig Performer so they can look into the issue.

Most of the other plugin hosts are different. The way one “talks” to the plugin is standardized but many other plugin hosts don’t always use everything that’s available in that “language”. Our users have found plugin bugs when used within GP and most of the plugin makers were quick to fix their bugs. Roland Sound Canvas has issues in how it deals with its presentation as it assumes certain things which make it somewhat hard to use with GP. Please contact Roland for these issues - these problems are not GP related.

Right. Your Gig Performer is going to be the center of your “universe” and it will, by default, react to Program Change messages switching from one rackspace (sound) to the other. As you get to know GP and start organizign your sounds into rackspaces rather than trying to cram everytrhing into one rackspace and use PC messages to switch sounds within a plugin - you’ll appreciate this.

Having said that - feel free to set the rackspace program change message to number you’ll never use and enable the option to “Pass unused PC messages” which will then simply pass all PC messages to your plugins (you have to. obviously connect a MIDI In block to your plugin for anything to work).


I have here some screenshots, showing the problem (the red one is from GP, the green one from Cantabile):

In GP the buttons didn’t work anymore … in general the PlugIn works, but the UI works not correctly.

As I already mentioned - we already know about this. I was trying to say that the issue is within the plugin even though it works differently with other hosts which may be doing things differently as well. No other plugin has this issue with GP btw…

Sorry for the long delay, but for newbies, there is a message limitation per day.
By the way everywhere I can read something with 14 days trial period. On starting
the program today it shows only 6 days, where is the rest of the 14 days (have
istalled the program on the 03.07.21)?

Ok, it looks like there is no (simple) posibility to exclude some MIDI-IN and
-OUTs from the program change feature used for the Variations. But all things
which are coming in from the vArrangers MIDI-Port has program changes which must
be transfered to the Sound Canvas (or another General-Midi Device). I saw that
it is possible to exclude MIDI-Ports from PC envents, but means this that all
events of this port are ignored or means this that all PC events are normally
send to it’s destination (and GP ignores them for variation switching)? I think
in professional setups nothing is in use like a Sound Canvas.

Another idea is to use another ASIO interface for using the VST-Host from
vArranger for sending MIDI-Data to the Sound Canvas, so all other things
can be managed in GP. My UR44-Interface can be used only by one host app
at once :frowning:

The other solution is using Cantabile or Cubase, but the UIs are much less
flexible and there is no possibilty to create my own Racks with own user
elements :frowning:

Thanks and best Regards

Unless you were changing dates on your computer you should be getting the full 14 days for trialing from the first time you installed GP

As we pointed out earlier - you can exclude devices from being used for PC messages and you can also change your rackspace/variation PC messages to a very high number so they don’t react to PC messages (if that’s what you want).

You then use specific MIDI In blocks for specific devices and those will receive your program changed and you can route them any way you want. Into a plugin, into another hardware device … anywhere reall.

We’re all just thinking that you may be trying to re-created some setups the way you used to do them in a DAW where you don’t really have rackspaces, but rather just a single “space” where you have to put everything and then you use PC messages and other tricks to switch and change things durping your performance.

On my computer ther dates are changing automatically from one day to the next :slight_smile:
I am shure that I don’t have set the date manually back because this causes problems with the
domain controller. The only thing that could be, is that the date was corrected by an NTP Time
Server, but this can only be some seconds.

Sent you a PM with some instructions. Please respond there about the trial. Thanks

Hello again, I’ve played a little bit with GP and it works with program changes and also with Sound Canvas. But at all, the VST-Plugins from Roland have not the quality as I expected (Tested Sound Canvas and XV-5080). Sounds are ok, but the CPU usage is at a (in my opinion) high level. Other PlugIns (Steinberg, Native Instruments, ASS, Waldorf) didn’t create so much CPU load. Is this a problem of my (PC)-configuration or is this a known behaviour of the Roland PlugIns named above?
The emulated hardware is over 20 years old, so that it should be a snap for modern computers …


My own experience is that the Roland plugins are extremely CPU intensive.

OK, so I think that it’s a problem of their implementation, and not a problem of my PC.

Yes - I’m on a Mac and have seen the same thing. Generally, in this situation, if a plugin is making a sound that you love but it’s too “expensive”, I sample it into Kontakt and use it that way.


My experience over the years is Roland has tried to get into and out of the “software” side of the business a number of times, pulled back, gone back in, etc.

Like a lot of software companies, when they pull back they don’t “delete” the software they previously developed. They just leave it out there, closer to “abandoneware” then “supported software.”

Sound Canvas, despite being available today through Roland Cloud, is still abandonware from my point of view. I haven’t touched it in at least five years, but even then it struck me as dated and unsupported.

Roland is now trying to make a software comeback again, this time centralizing on the Zenology/Zen-Core platform. The idea there is to have a common platform where Zenology (the VSTi) patches will sound exactly the same as those on the hardware synths. Kind of like what Line 6 is doing with Helix. Software and hardware all running a common platform so you can move patches seamlessly across hardware and software.

The net result today, from my experience, is that older Roland VSTs that don’t fit neatly into the Zenology/Zen-Core platform may still be available and supported on Roland Cloud, but they results can be mixed.

I like Zenology, and that’s clearly where their development efforts are focused. But that’s still a work in progress. In my experience it’s not any more of a CPU hog than any other analog synth modeler package (e.g. Arturia Analog Lab V) but I say that with the caveat that I’m a “try the presets, find a few I like” kind of user when it comes to analog synths.

1 Like

Thank you @Vindes for this historical analysis, that’s the feeling I had, but I was not sure about it as I missed the early days of Roland plugins. I am still owning a JX-8P :wink: