Of course it is a C major chord, but the Scriptlet doesn’t make sure it is a chord, it only notifies that you played n-notes. But if you play n notes “together” (with n>=3) it will only display once that you are playing an n-notes “chord”. e.g. If you play a 4-notes chord, it won’t first display that you are playing a 3-notes chord and then that you are playing a 4-notes chord.
This Scriptlet is not genius, as it’s name suggests, it is only for NoteTracker testing purpose. And it does exactly and only what I wanted it to do.
This could also be done, but I was not what I wanted to do here.
The scriptlet as @dhj says needs to distinguish between single notes (even 32 second notes) and chords. Most likely playing with the threshold will yield more accurate results.
When I said intrinsic-function, I was relating to a variation of your scriptlet whereby you would return an Array with the notes of a chord or a single note. Then using Size(Array) would tell if it is a chord or single notes. The interesting thing about a chord for the most part would be all the notes in the chord would most likely have the same velocity and the time interval between notes would be the same.
My original intent for doing this scriptlet was to facilitate midi accordionists with the ability to play open jazz chords. In their case they can only play chords on their chosen midi channel, so your scriptlet works as required. But now, you have opened the gates for keyboard players that can play both chords and single notes. This is a good thing😎
Try to use NoteTrackers and keep your code as light as possible because music is in real time. If you want to convert played notes depending on an analysis of what has been played, you will delay everything and possibly break the temporal coherence of what was initially played e.g. because of the timer “temporal sampling” in my Scriptlet. Nothing is won until you come to the end of what you want to do.
Now that the time element was factored in, I was afraid that would become the case.
I will test the limits and take it as far as I can go until degradation. I also realize that there are other factors involved, not just the code.
@dhj Is GPScript an interpreter or compiler? We both know compilers most of the time yield faster execution, but in some cases, it is the other way around. If you could give me a heads up on limitations before I get too deep, I would appreciate it?
In fact using a timer was an easy quick and dirty hack. Taking the time into account is mandatory, but I would prefer to implement a state machine taking the time and the number of notes into account. The idea would be to put it in the On NoteEvent callback, perhaps (probably) forcing it to be triggered using a time callback. This is very dependent from what exactly you want to do and is not trivial.
Indeed, GP has to survive to your potentially demanding Scriptlets
GPScript is indeed compiled. But it is better to used GPScript functions (which are fully optimized) rather than reimplementing it differently. This explain may recurrent advice to use NoteTrackers and related functions. This is an advice I have from @dhj. And Inoticed that implementing something using the NoteTrackers is pretty efficient.
Did you compile this code?
I copy pasted it on a rackspace script, compile and get:
Rackspace (Rackspace) - - Syntax Error in “Main”: Line 15, Col 3: Unexpected or unrecognized token: ‘SendNow’
Mismatched input ‘SendNow’ expecting {End, Else, Elsif}
//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
MIN : MidiInBlock
//$</AutoDeclare>
//Called when a NoteOn or NoteOff message is received at some MidiIn block
//Note: this will NOT be called for NoteOn/NoteOff messages if you have explicit
//NoteOnEvent/NoteOffEvent respectively callbacks defined
On NoteEvent(m : NoteMessage) from MIN
if GetNoteNumber(m) == F3 then
SendNow(MIN, m)
SendNow(MIN, WithTranspose(m, -2)) //Eb3
SendNow(MIN, WithTranspose(m, 4)) // A3
end
End
