Can I trigger patch change from Playback?

try using the External instrument plugin to send the midi out. Its possible there is something about the external midi channel is blocking something...

Also note when you select the channel that has the seq script, if you look at the midi output tab you will see some checkboxes that might matter

 

hmm, not sure right now, let me fool around and see if I can figure something out..

oh man you're a genious and im stupid my external instruments with sequencers were all set to recieve midi from the keyboard.

 

by defalut, external instrument hijacked the midi keyboard... so being set level it obviously outranked it. works fine when i set midi in to "none"

i think something is off with the latest sequencer, the old sequencer works fine, the new one (with sequence in the beginning) has issues with invoking playback at the same time as midi clock is reset

 

(i have a footswitch that has two commands setup: play for the playback plugin + global play, so beat clock is reset when sequencer on set level restarts.)

the first one shouldn't have worked for the either, it can only start from beat 1 right now. what do you mean exactly by reset beat clock? The fact that the sequence is at the beginning shouldn't be a factor either way.. but I changed some other things too, so let's get to the bottom of it.

hm, i changed back to previous but the issues remains. so here's how i do tihs (and it generally works)

 

I have sequencer at SET level, and a footswitch (simple CC) configured at SET level to invoke two commands:

- playback/ Play (from start)

- Global Actions/ Play

 

This insures that both mainstage beat clock and playback start from 1.1. everytime i hit play. And for some sets it works perfectly fine - but for some sets, it just doesnt start playback if I have "Global actions/ Play" under commands.

 

edit

the command works fine if mainstage is STOPPED before i invoke it. (But then i'd need to program every patch change with a "stop" command, which is doable nonetheless since FCB1010 can be programmed to send two commands on one switch.)

what command is your foot switch sending to MainStage to cause it to play from the start?

Nothing it's a simple CC (14, 0).

Anyway I think I know what I need to do, the sequencer needs to chase to the beat position a little more intelligently then it does now, right now it is assuming you're starting playback at the start and not looping or anything..and if you hit stop and play again, then it will reset and play from the beginning no problem, but if you are just hitting something that somehow resets the beat position, then its not catching the beat position change. Need to know what you're doing there, but anyway I'll have a look to see if I can just make it a little smarter to follow the beat position better.

 

Please help me, what does CC14 do?

It's mapped to two commands:

Playback plugin \ Play (from Start)

Actions \ Play

 

the second command restarts the midi clock without stopping it, generally.

Not entirely sure what those two MainStage commands due, but they must not call the Reset() call back. One quick hack fix might be to add something like this:

function HandleMIDI(event) {
   if(event instanceof ControlChange && event.number == 14) {
       Reset();
   }
}

 

But I'm going to work on a better version that can track beat position better, and would then work in looping modes and stuff too. Try the above for now and lemme know.

i just added a CC26 to every patch change command (that actually changes song) that will stop the midi clock, and its cleaner than letting it play anyway.

if it stops and starts, then the existing script will reset and play from the beginning and you should be good. I'm still going to make a fancier script that tracks beat clock better though, stay tuned.

i also realized that the existing script could leave some noteOn's hanging if you hit stop in the middle of a note. Will add something that will hopefully detect that and send out hanging NoteOff's, but that's going to take some time to do.

button 1 now does 2 things:

program change (invokes first patch in a set)

Global actions / stop (via cc26)

 

button 2 does two on same CC:

playback / play (from start)

global actions / play

 

if you stop it automatically starts from the beginning, so doing it this way i dont need aditional line in the script

i also realized that the existing script could leave some noteOn's hanging if you hit stop in the middle of a note. Will add something that will hopefully detect that and send out hanging NoteOff's, but that's going to take some time to do.

 

have you had any issues with cpu spikes and the scripter?

 

I've had a few dropouts without CPU being actually tasked, and i'm trying to pinpoint where it's coming from.

I've since done a complete reinstall and trying to figure out what's going on.

I forgot where we left off on this script, are you operational now? I haven't noticed any cpu spikes with scripter generally. But it depends a lot on what is happening in the script.

 

Scripter, just like all good plugins, needs to be programmed so that during HandleMIDI() and ProcessMIDI(), no expensive operations happen. So basically you don't want to create new objects inside there, don't Trace anything to console, etc.. But also Javascript has automatic trash collection that can happen whenever javascript feels like it. So if you are creating a lot of objects that go out of scope, then at some point Scripter might try to finally free the memory, which could cause a cpu spike,...but honestly I do not think in most cases Scripter will truly spike the CPU...you would have to be doing extreme things with it.

 

More likely is that some midi notes could drop out if you have too much midi traffic happening in a short period of time, but I have pushed pretty hard on Scripter and so far haven't seen either thing happen.

 

I have noticed that LPX in general, regardless of whether Scripter is uses, can drop midi notes if there is too much midi traffic through a single instrument channel. It takes quite a lot of traffic to cause this, but I've seen it happen. Especially if there is a lot of environment stuff happening. In preferences try setting the process buffer to LARGE, which seems to help avoid that.

Using it in mainstage , doesn't have process buffer range.

 

yeah it's generally operational, but something is causing random spikes in my mainstage project and i cannot figure what for the life of me

which script are you using?

 

Start eliminating stuff one at a time until you eliminate the spike.

that's the problem, the spike is completely random and happens once every X playthroughs, and not even on the same spots, and the patch is so complex I don't even know where to begin

again, the only way to find it is to eliminate things and run it for a while until it shows up, if it never shows up then you found the thing causing it. its a long process to find the problem, but I don't know any other way sorry.

edit: yeah i've tried with a fresh install right now with barebones system, will see how it fares.

 

Oopsy, what's this?

 

that's the "sequence capture" script in logic

 

I deleted that line and it works, i Just don't remember that popping up.. ever

show me the actual script please. You're on LPX 10.4.6?

with regards to the PrimingEvent thing. Apple eliminated the EventTypes.js built in include in LogicPro 10.4.6. Previously this internal javascript file held definitions of various things included Event objects and methods. It also had something inside there defined as "PrimingEvent", which was defined as an empty event object. I have no idea what PrimingEvent actually was, but i noticed that often time when clicking the RunScript button, the HandleMIDI() callback would get called right away with an empty event object and if your code in HandleMIDI didn't look for it and ignore it, then it might do weird things. I myself used something like this to get around it, prior to 10.4.5:

 

function HandleMIDI(event) {
   if(event instanceof PrimingEvent) {
       return;
   }
}

 

With LogicPro 10.4.5, the EventTypes.js has been removed so any references to PrimingEvent no longer will work. That's why the error in your script. It has nothing to do with cpu spikes.

same happens on 10.4.4 tho?

 

it's the // WTF? line

 

i chucked it out and it worked fine.

 

as for the sequencer script, i'm using the one that still has the actual sequence at the bottom.

 

And yeah, this script is only for capturing the MIDI data so it cannot have anything to do with spikes since it's not even running in MainStage.

 

It's probably something (or was, before the wipe i did) on my system, since the fans wouldn't even fire up yet the playback dropped and cpu spiked like hell.

 

var NeedsTimingInfo = true;

var first = true;

function HandleMIDI(event) {
   event.send();
   
[b]    if(event instanceof PrimingEvent) return;  // WTF?
[/b]
   var ctx = GetTimingInfo();
   if(!ctx.playing) {
       return;
   }
   
   var buffer;
   
   if(first) {
       buffer = " ";
       first = false;
    }
    else {
        buffer = ",";
    }
    
   if(event instanceof NoteOn) {
       buffer += "seq(NoteOn, {beatPos:"+event.beatPos+", channel:"+event.channel
                +", pitch:"+event.pitch+", velocity:"+event.velocity+"})";
   }
   else if(event instanceof NoteOff) {
       buffer += "seq(NoteOff, {beatPos:"+event.beatPos+", channel:"+event.channel
                +", pitch:"+event.pitch+", velocity:"+event.velocity+"})";
   }
   else if(event instanceof ControlChange) {
       buffer += "seq(ControlChange, {beatPos:"+event.beatPos+", channel:"+event.channel
                +", number:"+event.number+", value:"+event.value+"})";
   }
   else if(event instanceof PitchBend) {
       buffer += "seq(PitchBend, {beatPos:"+event.beatPos+", channel:"+event.channel
                +", value:"+event.value+"})";
   }
   else if(event instanceof ProgramChange) {
       buffer += "seq(ProgramChange, {beatPos:"+event.beatPos+", channel:"+event.channel
                +", number:"+event.number+"})";
   }

   CONSOLE.log(buffer);
}

function Idle() {
   CONSOLE.flush();
}

function Reset() {
   CONSOLE.log("//==========================================================");
}

function __Console() {
   this.buffer = [];
}

__Console.prototype.log = function(msg) {
   this.buffer.push(msg);
};

__Console.prototype.flush = function() {
   var iter = 20;
   while(this.buffer.length > 0 && iter > 0) {
       Trace(this.buffer.shift());
       iter--;
   }
};

var CONSOLE = new __Console;

Ok, this script is the thing you can run in LogicPro to capture the sequence information to copy and paste into the other sequencer script.

 

I think probably it will need something instead of the PrimingEvent event line, but I will have to test it out later. its fine to remove it and if it works then great. it was a hack before related to what I considered to be a bug in Scripter and maybe they fixed that bug too. If everything works fine when you run the capture script without PrimingEvent line, the no problem.

 

Not sure what to say about MainStage spikes..or dropouts...could be anything....

Ok, this script is the thing you can run in LogicPro to capture the sequence information to copy and paste into the other sequencer script.

 

I think probably it will need something instead of the PrimingEvent event line, but I will have to test it out later. its fine to remove it and if it works then great. it was a hack before related to what I considered to be a bug in Scripter and maybe they fixed that bug too. If everything works fine when you run the capture script without PrimingEvent line, the no problem.

 

Not sure what to say about MainStage spikes..or dropouts...could be anything....

 

everything does seem to work fine without the priming event, just added a new song to the set and it works fine.

 

The dropouts seem to be gone ... for now.

I did a complete wipe and didn't migrate anything, setup everything from scratch, and installed only plugins necessary for this mainstage concert.

CPU usage is down 30% and fans are stable at 3500rpm (before they were maxing out, but CPU still had headroom)

 

Odd thing is, previous installation wasn't "dirty", i did a complete fresh installation on a new Mac Mini (the plugs I regularly use) then migrated from the Mini to the MBP 13", nothing but fresh install with what i use.

Still, it looks like something from that setup didn't sit right with it.

Since all of you clearly know what you're talking about when it comes to midi scripting...

My problem is as follows:

I use mainstage with novation launchkey 25 and 61 (two keyboards)

they have RGB pads which i use for percussions

i cannot get the damn thing to light up from mainstage (novation provides programing guides which i don't understand completely)

What i've managed so far is to run ableton light to loop 1 beat of programed lights in ReWire (and leave it running in background)

I need the lights always on, and i've managed to pick colors of each pad (so i can hit ex: chimes on purple, shaker on blue pad etc)

What i've tried and failed is to eliminate ableton from the setup and have the lights running from mainstage (at concert level all the time fixed colors).

While i don't mind this ableton setup and it has performed reasonably stable, problems arise if i need to restart mainstage. Rewire goes off the rails and i have to reboot the mac (which in live situations is 2-3 minutes more).

this is an example of the programing code from novation's manual

https://customer.novationmusic.com/sites/customer/files/novation/downloads/10535/launchkey-mk2-programmers-reference-guide.pdf

since i could not understand it, i've made new tracks in ableton and edited midi notes instead.

 

i have tried to export that midi file (from ableton) and import in mainstage on EXT midi playback and failed, since that is as far as my understanding goes.

 

so if anyone has an idea if this is even possible, it would be much appreciated.