Unfortunately i have no idea. It wasnt the current version, but i have no idea if there were any versions between the one i was using and the one i have now, which is the latest.
I cant seem to replicate it at the moment. I have been tyring.
So the one that crashed was NOT their latest?
No, as I said in my first post (although maybe that sounded confusing).
‘Im on a MacBook Pro M1 and everything is up to date (other than JP-8 V ironically, that was one update behind the current one).’
By one update I was just assuming it was one build, but might have been more.
I have updated since, which was one of the reasons I wasn’t going to bother Artuira, as it could well be because it was an older version.
I forgot….if I had been paying more attention I would have asked you to please update that plugin before going any further.
If the new one works properly, then it sounds like that issue had already been reported and addressed.
Yeah. Once i realised it was an older version i immediately updated.
Obviously once i had updated i didn’t feel the situation needed immediate support.
Hopefully that did fix it but I’ll keep an eye on it.
Yeah but I wish you had told us.
Anyhow, glad it’s fixed now
I did tell you. Remember when this got locked and i had to post on FB? I said i had updated the plugin. I couldn’t post that here for the reason above.
1 Like
Great news! 
Please post what is your current version of that plugin (just for future readers).
Its Version 4.6.0.4395 (arm 64)
Seems stable enough.
A week ago I also had a crash in Jup8v, Windows in my case. I updated to the latest and then the crash happened no more.
1 Like
Yeah, 6 years ago when we had much older versions of GP, I wouldn’t have been as quick to suggest the plugin but these days, GP is solid enough (hank goodness) that such crashes are generally due to the plugin. Based on the report and the stack trace, my bet would be that the plugin tried to directly perform a GUI operation from the MIDI thread. While that will work occasionally, it’s a time bomb waiting to happen, totally depending on what else is going on at the time.
1 Like
Ah yes, i did have the GUI open at the time this was happeing. I didnt mention that before.
On this subject, is it good practice not stop the controller talking to the plugin directly and let GP do it?
I think I read somewhere that it is recommended. I have found very occasionally that when im setting up a sound in one plugin the controller is changing something in another plugin in the rack. or maybe I just imagined it. I dont tend to use the knobs and sliders much for changing sounds, other than the Mod wheel. In fact there are only two rack spaces that I use real time control in so I guess I could shut this off?
You maybe read this article: Avoid controlling plugin parameters directly from your MIDI controller - Gig Performer®
It is “best practice” — in general one should avoid completely using MIDI messages to control plugin parameters but that has nothing to do with the crash that occurred.
The main reason is to make the control of plugins completely independent of explicit MIDI messages.
Minor reason:
- Many plugins store MIDI associations globally which means you can’t have multiple instances with different MIDI associations for the same parameter. So, for example, if you want to control the filter cutoff with a knob in one song but you want to use your expression pedal to control it in another song, you’re out of luck
Major reason:
- You sometimes use a different controller which uses different MIDI messages (e.g, you have different rigs depending on the band or you have to deal with backline gear or your keyboard just breaks and you need to temporarily use another one).
- In any of these situations, you will either have to figure out how to reprogram a different controller to send out the desired messages (good luck doing that at the last minute at a sound check) or you will have to reprogram all your plugins to learn the new messages.
- However, when you use widgets, you can just use Gig Performer’s Rig Manager to quickly reassociate each widget with a new MIDI message - this is designed to be a fast process, totally feasible during sound check.
Ah thanks. Yes. That’s the article i had read a while ago. Wasn’t sure where I’d seen it.
Silly question (I’m at work so not able to look), but how do i stop the plugins from being controlled directly by the controller? Is it in the filter section of each midi in block? I have a few things like sustain filtered of some plugins, but I’ve not tried to disable it all.
Thanks again for the help.
Use widgets!
They act as an intermediate between MIDI coming from your controller and parameters of plugins.
So the parameter value is actually altered by the widget and not by the controller.
As soon as a MIDI message (from your controller) is learned to a widget, this message won’t go anywhere else (say: the widget “eats up” that message).
A big benefit of widgets is also the ability to use value curves or being grouped with other widgets.
1 Like
Sustain is actually the single exception which should be allowed through (because of patch persist)
But most plugins don’t respond to MIDI controller messages unless they have been learned so you generally don’t have to do anything. Also, if you have widgets mapped to those controls, by default those messages won’t be passed to the plugins anyway.
That said, you can always block events through the MIDI In Block plugin and you can even save that configured plugin as a favorite or as a preset to be able to insert it again quickly when you need it.
In fact, I have a MIDI In block that is designed to block all messages except the sustain pedal and I have that saved as a preset so I can basically connect my sustain pedal to any synth, independently of into which keyboard controller the sustain pedal is physically connected.
1 Like
Thanks guys.
I wasn’t aware of how the cc gets transferred to the plugin. I think I’ll leave things as they are for now. Only two songs need real time control and those Rackspaces don’t have anything else that might be affected.
Due to my controller being at a right angle to my desk at home i rarely use the controls on it to do sound design etc, so it’s only a rare case that I’ve felt throngs haven’t been quite set up right.
As far as sustain goes. I had to get a Bluetooth foot controller to do sustain and previous/next song selection. Although my Arturia controller has loads of sockets, the Nektar I’m using for rehearsals doesn’t. I wanted to keep things as simple and as possible so i use the foot controller with either. I do use Rig manager.
As far as blocking sustain, i only use sustain for piano, so having it layered with a pad or strings meant everything got sustained, so it’s blocked for anything other than the piano (or i just don’t use the pedal on that rack space) at the midi in block. It just seemed easier and this was done when i first set up the rack spaces. I did start to go back and set up a midi sustain block but i felt i was just doubling up on what was already working.
I also use the same switch to change Leslie speed on the organs, so again sustain gets blocked and the pedal is routed to the Mod wheel in the Organ wiring.
My needs are very basic, and at the moment everything is working and doing what i need when i need. I’m just now trying to tidy things up a bit as i was learning all this as i was building the rack spaces and i know a few of them are not optimised as well as the latter ones.
Oh, and I’m only using one rackspace per song, so at the moment patch persist isn’t needed.