Does anyone have a simple script that would delay the note on information

Dear all,

Does anyone have a simple script that would delay the note on information to rectify the problem with the “modification of a great scriplet created by @David-san that can be used to automatically bypass a plugin after a short (or zero) time delay when no MIDI activity is detected.”?

The issue with this modified script is that it works perfectly BUT the first note does not sound on some plugins. If you press it twice quickly it enables the plugin, but the first attack is missing. Someone suggesting that a delay to the note on information may resolve this issue. Of course this will not work with some sounds, but sounds that have a slow attack would be just fine. I thank you in advance.

I don’t think that it would be the good remedy for this issue. Because of the first missing note, you would delay everything which is not acceptable in my opinion. You could of course only delay or double trigger all first notes, but this mean that you would continuously test in the Scriptlet, if it is the first note or not. I don’t like this idea… :nerd_face:

Thanks David. And as far as you know is there solution to bypass a plugin that does not rely on a button, knob or fader to enable the plugin? In other words, something like this script that can trigger the bypass by a performance action. The strike of a note on the controller in other words.

From having read your previous post with 100 plugins in a single rackspace, it seems to me you’re going about this the wrong way. Basically you’re fighting against the paradigm that GP supports.

I don’t know why you can’t create multiple rackspaces and just put the pieces you need in each one and then let GP handle (most of the) bypass needs.

Switching from one rackspace to another should be instantaneous and without glitching. I’ve created several medleys where I often switch rackspaces in the middle of a bar with no issues.

But there’s no magic here. There are some things for which GP can’t optimize. If you’re having trouble with switching then it may be that:

  1. You still have too many plugins in the rackspaces. Remember that while you’re switching with patch persist enabled, both rackspaces have to be active momentarily and that will certainly impact CPU usage
  2. Your sample rate may be too high or your buffer size may be too low
  3. Your audio interface drivers may not be sufficiently optimized. It’s amazing how much is the impact of high quality drivers.
  4. Your computer just might be too slow or not have enough RAM
  5. You have other stuff running that is impacting performance

(NB, I don’t know which if any of the above are true, but they’re all things to consider)

Just my two cents

1 Like

Thanks so much for the feedback. I was probably exaggerating a little about the 100 plugins. But anyway, the rackspaces are busy no doubt. And yes, in past uses of Gig Performer in a live situation I had no such problems. But as you very well know, we do it to ourselves. Each project get more complicated and I personally wonder why I just don’t do ukelele gigs (not putting down ukelele players, just an example of where we could be kinder to ourselves). But yes, I was rational in the beginning and was planning to have a whole lot of rackspaces. But then I found myself having trouble doing the switches and thought “why don’t I just have a couple of rackspaces” and that’s where I discovered the PCU usage problem. Silly me, yes. I didn’t really know the limits, and being me I went to a place I should not have gone to. But yes, I have 32.0 GB of RAM and 12th Gen Intel(R) Core™ i7-1255U 1.70 GHz processesor. So it should be OK. But when I bought this laptop (my second computer, I have a desktop at home), which was only a year ago I was not thinking of stacking up a series of 50 plugins in Gig Performer. The madness came in stages. It happens to all of us. We start of with some clarity and then get as close to the cliff as we can without falling off. Thanks again for your thoughts.

AND I have an update. The message above was meant to be sent the other day but the system did not allow me to send any more messages.

I have come up with a solution. The AutoBypass scriplet works just great. The problem with it is that it needs to be initiated. And so I trigger this initiation with a note on message (essentially a note from the passage before the one I was to trigger). So for example, if I am playing a C4 as the first note of the previous passage I will use this note to trigger the initiation of the AutoBypass scriplet. So, when I play the next note in the piece, let’s say it’s a D4, the scriplet will allow the D4 to sound perfectly without any delay. And I can set it then bypass the plugin (for note D4 say) after a certain amount of time, let’s say 8 second sustain with an 8 second release. And so effectively what I can achieve in my case is to have every plugin in my Rack 1 say bypassed, and as I use each one, that one opens the next plugin, the nexy plugin open the next one and so on. And so as I open the next, the previous one after being used, closes automatically. So, my PC was running at around 90%, the CPU usage. By having all the plugins closed, it now sits at around 15 or 20%. So problem solved. But that is in my particular case, where I am essentially triggering a lot of things with sigle notes and ocassionally playing lines on one of the controllers. So using 4 controllers (Novation Launchkey 25 MK3 MIDI Keyboard Controller, Akai LPK25 MK2 25-key MIDI Keyboard Controller, Korg nanoKontrol2 MIDI Controller, Korg nanoPAD2 MIDI Controller) with Gig Performer in a piece that is organized, meaning I am not improvising, it is fully notated.