BrainModular

Script that checks whether Notes and Sustain have been turned off. If not,
then send NoteOffs and Sustain=0 when a trigger is received. A "mild" form of
a panic button functionality when the receiving instrument doesn't recognize
the AllNotesOff message.

The script should be connected in parallell to the existing MIDI stream.
For instance:
MidiIn -> SomeVSTi (as per normal)
MidiIn -> ClearMidiNotes -> SomeVSTi

--

Sorry I couldn't think of a better name... I haven't tested it much, so I might have overlooked something.


PS. What about adding a Pitch Wheel reset as well?

Very useful script ! Thanks you again !

Thank u Bsork !!!! very useful!!

(It's a shame it can't work on my girlfriend too )

one suggestion for a name : Midi Broom ?

Thanks so much!

I'll see if I can add the pitch reset....

-e

I think the pitch wheel reset should be implemented like the sustain pedal reset. Add another field to the status record and use the same logic.

...and how did you think of using it on your girlfriend..?

I don't know, it's just a dream !

Bsork:

I've been studying your code, and it all is making good sense. But I have one question:

I notice that you send the integer'len' into your PROCEDURE CreateOut as the VAR 'cnt'. Is this a matter of programming ettiquette, or is there an actual scope issue with variables in these scripts?? Could you just use len globally? I'm trying to figure out in which instances I need to send a value into a procedure, and when I should just use a global variable.... specifically, If I want to strip out the "setStatus" code into a PROCEDURE, should I send it the 'status' and 'notes' variables, or can I just refer to the global versions?? The global versions are so clearly global, it doesn't seem like bad ettiquette to refer to them. But it may be bad grammer!

I'm going to end up with a pretty big script, so I'd like to put as much code in procedure calls as possible. But I want to do all my MIDI mapping and managing work in one big iteration loop, so as to save processor overhead--and minimize cabling! As a Java programmer, I'm used to encapsulation and restricting scope, but I particularly don't want to pass everything around in function calls if there is a performance hit associated with it.

Thanks!
-eric

Oh--I knew there was one more question:

I'm not quite clear how I would check if the value of an input has changed. I want to have a 'dirty' flag, a boolean that gets turned to TRUE whenever certain inputs change state, and set back to FALSE when clearMidi is called.

You do a test for pSendNoteOff = 1, but I'm not sure how that would work if that input was a toggle and you needed to check whether it had changed. Where would you put that logic? In every iteration of the main loop? I assume 'init' only gets called when you create the object, right?

well, maybe this will be clearer in the morning. I have to get some sleep!

cheers,
-eric

Hi Eric, the CreateOut procedure is a copy from another script (the MidiMapper that's included with Usine, IIRC), where that construction made more sense than within the relatively small script we're dealing with here. If I hadn't copied, I would have just used the global 'len' variable, I guess. If you want to create separate procedures, you can use input parameters or globals as you see fit. I don't think you'd notice much difference CPU-wise. However, I'm not sure whether parameters are called by reference or value - that could make a difference at least when dealing with arrays. Maybe Olivier can enlighten us?

Personally, I mostly use globals, only creating input parameters when something should be done repeatedly with different data, but then again most of my scripts are limited in size. In larger programs like those I do for a living, I certainly use more procedure and function calls than in a typical Usine script.

That's helpful, thanks Bsork! And yes, the pass by reference vs. value is what I was alluding to in the issue of a performance hit--not that I have any clue whether that is significant. I guess a pass by value on a large array would be a hit though, right?

I'll have to look at the midi mapper script. I missed that one!

-e

woodslanding wrote:I guess a pass by value on a large array would be a hit though, right?

Seems reasonable to think so. Maybe one day when I feel so inclined, I'll do some tests on how different ways of programming the script affects efficiency. I must admit I'm not among the most "technical" type of programmer around - if things get to low-level I'm more or less lost...

Olivier, do you have anything to add to this topic?

bsork wrote:I must admit I'm not among the most "technical" type of programmer around - if things get to low-level I'm more or less lost...

Me too! That's why I chose to learn Java instead of C++

-e

In v5 this script stopped working for me, but all it needed was commenting out the info at the start like this:

//******************************************************************************
// Script that checks whether Notes and Sustain have been turned off. If not,
// then send NoteOffs and Sustain=0 when a trigger is received. A "mild" form of
// a panic button functionality when the receiving instrument doesn't recognize
// the AllNotesOff message.
//
// The script should be connected in parallell to the existing MIDI stream.
// For instance: MidiIn -> SomeVSTi (as per normal)
// MidiIn -> ClearMidiNotes -> SomeVSTi
// bSork, October 2008
//****************************************************************************** $}

Still a script I find handy Bsork! Thanks for doing it in the first place!!

Well, just saw the new MEP pack, and it does this but anyway...

Maybe I should incorporate an updated version in the utility pack?