]]>
]]>
//******************************************************************************
// 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!! // 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
//****************************************************************************** $}
Statistics: Posted by Clearscreen — 12 Mar 2010, 00:46
]]>
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
Statistics: Posted by woodslanding — 23 Oct 2008, 23:26
]]>
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?
Statistics: Posted by bsork — 23 Oct 2008, 22:57
]]>
I'll have to look at the midi mapper script. I missed that one!
-e
Statistics: Posted by woodslanding — 23 Oct 2008, 17:45
]]>
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.
Statistics: Posted by bsork — 23 Oct 2008, 12:03
]]>
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
Statistics: Posted by woodslanding — 23 Oct 2008, 11:48
]]>
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
Statistics: Posted by woodslanding — 23 Oct 2008, 11:30
]]>
]]>
...and how did you think of using it on your girlfriend..?
Statistics: Posted by bsork — 23 Oct 2008, 08:26
]]>
I'll see if I can add the pitch reset....
-e
Statistics: Posted by woodslanding — 23 Oct 2008, 01:13
]]>
(It's a shame it can't work on my girlfriend too
)one suggestion for a name : Midi Broom ?
Statistics: Posted by noise2sine — 23 Oct 2008, 00:12
]]>
]]>
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?
Statistics: Posted by bsork — 22 Oct 2008, 23:18
]]>