Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #37522 > unrolled thread
| Started by | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| First post | 2019-10-09 08:48 -0700 |
| Last post | 2019-10-17 10:08 -0700 |
| Articles | 13 — 3 participants |
Back to article view | Back to comp.lang.javascript
Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-09 08:48 -0700
Re: Signal boundary problem and how to correct it. Jan Bruns <ebay@abnuto.de> - 2019-10-12 14:14 +0000
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-12 10:19 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-12 10:31 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-12 10:34 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-12 23:26 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-12 23:55 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-13 00:07 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-13 00:31 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-13 00:47 -0700
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-17 00:30 -0700
Re: Signal boundary problem and how to correct it. Arno Welzel <usenet@arnowelzel.de> - 2019-10-17 10:34 +0200
Re: Signal boundary problem and how to correct it. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2019-10-17 10:08 -0700
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-09 08:48 -0700 |
| Subject | Signal boundary problem and how to correct it. |
| Message-ID | <73c2a298-a543-4096-a642-47c5c9a19a84@googlegroups.com> |
This is an on and off problem. The general rule for midi is there should be an on "for the specific note, before there is an off for it". Otherwise weird things happen when you playup. One other thing to know, it is the interval between on and off that is played.
This problem is due to the musician "user", may push midi notes outside the boundaries of the specified recording time/ slot .
Is there a general approach for solving this?
I have written Pascal code for MIDI but it was certainly 30 years ago.
Basicly after the recorded measures "within time frame", well in my case it is bars to start with. I have to handled two unwanted cases.
1. The user push down keys before the recording starts, "thus we have off notes" at start of recording. These must have an on time zero of recording. The user pushed early.
2. The user have not released the note before the recording end, "thus we have ongoing on notes".
This is what i threw together in some hours or so it ain't quite working although, the intention of what to do is there, it seem to miss some cases even create new cases......
You can check how it acts "recorded note events" in track editor.
https://midisequenser.000webhostapp.com/
function lateNotesFix(){
//Check if any messages
if (track[rectrack].midiMess.length>0){
//Fix noneclosed "open notes" after recend
var i=0;var j=0;
i=track[rectrack].midiMess.length-1;
j=track[rectrack].midiMess.length;
while (track[rectrack].midiMess[i].data0 || undefined && (track[rectrack].midiMess[i].data0==144 && track[rectrack].midiMess[i].time>=rs)){
track[rectrack].midiMess.push({
time: re-1,
data0: 128,
data1: track[rectrack].midiMess[i].data1,
data2: 0
});
console.log("Yeah man");
j++;
i--;
if(i==-1) break;
console.log("i="+i);
console.log("J="+j);
}
}
}
function earlyNotesFix() {
console.log("earlyNotesFix");
//Check if any messages
if (track[rectrack].midiMess.length>0){
var i=0;var j=0;earlyfound=false;
//Check how many early startpoints
var savetime=track[rectrack].midiMess[0].time;
while (track[rectrack].midiMess[i].time<track[rectrack].midiMess[i+1].time && i<track[rectrack].midiMess.length-2){
console.log("savetime "+savetime+"> midimess "+track[rectrack].midiMess[i+1].time);
i++;
}
if (savetime>track[rectrack].midiMess[i+1].time) {earlyfound=true;console.log("found early");}
//Fix early startpoints
j=i+1;i=0;
if (earlyfound==true){
console.log("found early note");
while (i<j) {
track[rectrack].midiMess[i].time=rs+1;
i++;
}
}
}
}
[toc] | [next] | [standalone]
| From | Jan Bruns <ebay@abnuto.de> |
|---|---|
| Date | 2019-10-12 14:14 +0000 |
| Message-ID | <qnsn4u$vjo$1@gwaiyur.mb-net.net> |
| In reply to | #37522 |
Jonas Thörnvall:
> This is an on and off problem. The general rule for midi is there should
> be an on "for the specific note, before there is an off for it".
> Otherwise weird things happen when you playup. One other thing to know,
> it is the interval between on and off that is played.
>
> This problem is due to the musician "user", may push midi notes outside
> the boundaries of the specified recording time/ slot .
var t=track[rectrack].midiMess;
while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
// So for any midi event related to controller 0, you append a note-off
event for controller 0, after previous attempts to stop after the first
non-Note-On Message for Controller 0 (found in a backwards search)
revealed that you didn't catch many cases?
var savetime=t[0].time;
var i=0;var j=0;
earlyfound=false;
while (t[i].time<t[i+1].time && i<t.length-2){
console.log("savetime "+savetime+"> midimess "+t[i+1].time);
i++;
}
if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
// earlyfound==(t[0].time>t[t.length-1].time)
j=i+1; // == length-1
i=0;
if (earlyfound==true){
console.log("found early note");
while (i<j) {
t[i].time=rs+1;
i++;
}
}
// So, if the last Message in MidiMess has a timestamp before the first
Message in MidiMess, all Messages except the last get the same timestamp?
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-12 10:19 -0700 |
| Message-ID | <bc3bc393-5417-48b8-b544-1638b9b9b3f8@googlegroups.com> |
| In reply to | #37527 |
Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> Jonas Thörnvall:
>
> > This is an on and off problem. The general rule for midi is there should
> > be an on "for the specific note, before there is an off for it".
> > Otherwise weird things happen when you playup. One other thing to know,
> > it is the interval between on and off that is played.
> >
> > This problem is due to the musician "user", may push midi notes outside
> > the boundaries of the specified recording time/ slot .
>
> var t=track[rectrack].midiMess;
>
> while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
>
>
> // So for any midi event related to controller 0, you append a note-off
> event for controller 0, after previous attempts to stop after the first
> non-Note-On Message for Controller 0 (found in a backwards search)
> revealed that you didn't catch many cases?
>
Yes for any "note off" that do not have a precding "note on" so should be, i fear i just in the haste just did catch the ones that came before any "note on".
So i missed the cases that basicly could have hundreds or thousands of on notes.
At "other keys".
So i think i catched that one. The other case have probably similar problem in the other direction....
You are forced to scroll thru all notes... Well at least until you found all notes on availabe at your keyboard.
Because if all notes on already been played well there could be no "wandering" nonereleased notes off that "have no accompanion.
Well from the other side finding none released notes it could be the same an early note pressed that was never released.
And lets not forget the moron keys, key was pressed before starting recording and never released....
> var savetime=t[0].time;
> var i=0;var j=0;
> earlyfound=false;
>
> while (t[i].time<t[i+1].time && i<t.length-2){
> console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> i++;
> }
>
> if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
>
> // earlyfound==(t[0].time>t[t.length-1].time)
>
> j=i+1; // == length-1
> i=0;
> if (earlyfound==true){
> console.log("found early note");
> while (i<j) {
> t[i].time=rs+1;
> i++;
> }
> }
>
> // So, if the last Message in MidiMess has a timestamp before the first
> Message in MidiMess, all Messages except the last get the same timestamp?
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-12 10:31 -0700 |
| Message-ID | <93e5326f-a355-43c6-aa85-d5d637dfd395@googlegroups.com> |
| In reply to | #37527 |
Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> Jonas Thörnvall:
>
> > This is an on and off problem. The general rule for midi is there should
> > be an on "for the specific note, before there is an off for it".
> > Otherwise weird things happen when you playup. One other thing to know,
> > it is the interval between on and off that is played.
> >
> > This problem is due to the musician "user", may push midi notes outside
> > the boundaries of the specified recording time/ slot .
>
> var t=track[rectrack].midiMess;
>
> while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
>
>
> // So for any midi event related to controller 0, you append a note-off
> event for controller 0, after previous attempts to stop after the first
> non-Note-On Message for Controller 0 (found in a backwards search)
> revealed that you didn't catch many cases?
>
>
>
>
> var savetime=t[0].time;
> var i=0;var j=0;
> earlyfound=false;
>
> while (t[i].time<t[i+1].time && i<t.length-2){
> console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> i++;
> }
>
> if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
>
> // earlyfound==(t[0].time>t[t.length-1].time)
>
> j=i+1; // == length-1
> i=0;
> if (earlyfound==true){
> console.log("found early note");
> while (i<j) {
> t[i].time=rs+1;
> i++;
> }
> }
>
> // So, if the last Message in MidiMess has a timestamp before the first
> Message in MidiMess, all Messages except the last get the same timestamp?
Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
Implementing it well not that fun, because i have to keep track of which one that is cleared....
Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
And it have to be done from both side, Start "offs" and end "ons"
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-12 10:34 -0700 |
| Message-ID | <6ee24bac-6fbf-42be-b934-dc0ab2c7ee03@googlegroups.com> |
| In reply to | #37529 |
Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > Jonas Thörnvall:
> >
> > > This is an on and off problem. The general rule for midi is there should
> > > be an on "for the specific note, before there is an off for it".
> > > Otherwise weird things happen when you playup. One other thing to know,
> > > it is the interval between on and off that is played.
> > >
> > > This problem is due to the musician "user", may push midi notes outside
> > > the boundaries of the specified recording time/ slot .
> >
> > var t=track[rectrack].midiMess;
> >
> > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> >
> >
> > // So for any midi event related to controller 0, you append a note-off
> > event for controller 0, after previous attempts to stop after the first
> > non-Note-On Message for Controller 0 (found in a backwards search)
> > revealed that you didn't catch many cases?
> >
> >
> >
> >
> > var savetime=t[0].time;
> > var i=0;var j=0;
> > earlyfound=false;
> >
> > while (t[i].time<t[i+1].time && i<t.length-2){
> > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > i++;
> > }
> >
> > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> >
> > // earlyfound==(t[0].time>t[t.length-1].time)
> >
> > j=i+1; // == length-1
> > i=0;
> > if (earlyfound==true){
> > console.log("found early note");
> > while (i<j) {
> > t[i].time=rs+1;
> > i++;
> > }
> > }
> >
> > // So, if the last Message in MidiMess has a timestamp before the first
> > Message in MidiMess, all Messages except the last get the same timestamp?
>
> Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
>
> But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
>
> So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
>
> Implementing it well not that fun, because i have to keep track of which one that is cleared....
>
> Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
>
> And it have to be done from both side, Start "offs" and end "ons"
bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-12 23:26 -0700 |
| Message-ID | <3a5bbf85-ee4e-497c-aeb1-973a94931c03@googlegroups.com> |
| In reply to | #37530 |
Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > Jonas Thörnvall:
> > >
> > > > This is an on and off problem. The general rule for midi is there should
> > > > be an on "for the specific note, before there is an off for it".
> > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > it is the interval between on and off that is played.
> > > >
> > > > This problem is due to the musician "user", may push midi notes outside
> > > > the boundaries of the specified recording time/ slot .
> > >
> > > var t=track[rectrack].midiMess;
> > >
> > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > >
> > >
> > > // So for any midi event related to controller 0, you append a note-off
> > > event for controller 0, after previous attempts to stop after the first
> > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > revealed that you didn't catch many cases?
> > >
> > >
> > >
> > >
> > > var savetime=t[0].time;
> > > var i=0;var j=0;
> > > earlyfound=false;
> > >
> > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > i++;
> > > }
> > >
> > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > >
> > > // earlyfound==(t[0].time>t[t.length-1].time)
> > >
> > > j=i+1; // == length-1
> > > i=0;
> > > if (earlyfound==true){
> > > console.log("found early note");
> > > while (i<j) {
> > > t[i].time=rs+1;
> > > i++;
> > > }
> > > }
> > >
> > > // So, if the last Message in MidiMess has a timestamp before the first
> > > Message in MidiMess, all Messages except the last get the same timestamp?
> >
> > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> >
> > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> >
> > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> >
> > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> >
> > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> >
> > And it have to be done from both side, Start "offs" and end "ons"
>
> bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
I remember it was quite tedious, because you first must acknowledge for each note if it already matched in list. If it matched nothing, if not matched.
But i think this could be it?
while (track[rectrack].midiMess[i].data0 || undefined && (track[rectrack].midiMess[i].data0==144 && track[rectrack].midiMess[i].time>=rs)){
matched=false;
var j=0;
while (track[rectrack].midiMess[i].data0!=matchArray[j]){
if( (matchArray[j]==true) {}
else {
matchArray[j]=true;
track[rectrack].midiMess.push({
time: re-1,
data0: 128,
data1: track[rectrack].midiMess[i].data1,
data2: 0
});
console.log("Yeah man");
j++;
i--;
if(i==-1) break;
console.log("i="+i);
console.log("J="+j);
}
}
j++;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-12 23:55 -0700 |
| Message-ID | <a50c6f57-768d-4f2e-ba26-4c7035fd695a@googlegroups.com> |
| In reply to | #37530 |
Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > Jonas Thörnvall:
> > >
> > > > This is an on and off problem. The general rule for midi is there should
> > > > be an on "for the specific note, before there is an off for it".
> > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > it is the interval between on and off that is played.
> > > >
> > > > This problem is due to the musician "user", may push midi notes outside
> > > > the boundaries of the specified recording time/ slot .
> > >
> > > var t=track[rectrack].midiMess;
> > >
> > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > >
> > >
> > > // So for any midi event related to controller 0, you append a note-off
> > > event for controller 0, after previous attempts to stop after the first
> > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > revealed that you didn't catch many cases?
> > >
> > >
> > >
> > >
> > > var savetime=t[0].time;
> > > var i=0;var j=0;
> > > earlyfound=false;
> > >
> > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > i++;
> > > }
> > >
> > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > >
> > > // earlyfound==(t[0].time>t[t.length-1].time)
> > >
> > > j=i+1; // == length-1
> > > i=0;
> > > if (earlyfound==true){
> > > console.log("found early note");
> > > while (i<j) {
> > > t[i].time=rs+1;
> > > i++;
> > > }
> > > }
> > >
> > > // So, if the last Message in MidiMess has a timestamp before the first
> > > Message in MidiMess, all Messages except the last get the same timestamp?
> >
> > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> >
> > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> >
> > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> >
> > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> >
> > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> >
> > And it have to be done from both side, Start "offs" and end "ons"
>
> bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
Well now i see why i thought this indeed will be even more cumbersome then i remembered, had not had my coffee.
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-13 00:07 -0700 |
| Message-ID | <6a95bf34-e9a0-436b-913e-88007f2c7078@googlegroups.com> |
| In reply to | #37538 |
Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall:
> Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> > Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > > Jonas Thörnvall:
> > > >
> > > > > This is an on and off problem. The general rule for midi is there should
> > > > > be an on "for the specific note, before there is an off for it".
> > > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > > it is the interval between on and off that is played.
> > > > >
> > > > > This problem is due to the musician "user", may push midi notes outside
> > > > > the boundaries of the specified recording time/ slot .
> > > >
> > > > var t=track[rectrack].midiMess;
> > > >
> > > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > > >
> > > >
> > > > // So for any midi event related to controller 0, you append a note-off
> > > > event for controller 0, after previous attempts to stop after the first
> > > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > > revealed that you didn't catch many cases?
> > > >
> > > >
> > > >
> > > >
> > > > var savetime=t[0].time;
> > > > var i=0;var j=0;
> > > > earlyfound=false;
> > > >
> > > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > > i++;
> > > > }
> > > >
> > > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > > >
> > > > // earlyfound==(t[0].time>t[t.length-1].time)
> > > >
> > > > j=i+1; // == length-1
> > > > i=0;
> > > > if (earlyfound==true){
> > > > console.log("found early note");
> > > > while (i<j) {
> > > > t[i].time=rs+1;
> > > > i++;
> > > > }
> > > > }
> > > >
> > > > // So, if the last Message in MidiMess has a timestamp before the first
> > > > Message in MidiMess, all Messages except the last get the same timestamp?
> > >
> > > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> > >
> > > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> > >
> > > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> > >
> > > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> > >
> > > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> > >
> > > And it have to be done from both side, Start "offs" and end "ons"
> >
> > bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
>
> Well now i see why i thought this indeed will be even more cumbersome then i remembered, had not had my coffee.
Ok i had my coffee, i think this is it "for the early notes case", a bit weird but is seems like the order of the conditions do matter??????
function earlyNotesFix() {
//Note on = 144 Note off = 128
var i=0;
while (track[rectrack].midiMess[i].data0 != undefined && track[rectrack].midiMess[i].time<=re-1)){
var j=0;
while (track[rectrack].midiMess[i].data0!=matchArray[j] && (track[rectrack].midiMess[i].data0==144 || track[rectrack].midiMess[i].data0==128){
if (matchArray[j]==false && track[rectrack].midiMess[i].data0==128){
matchArray[j]=true;
track[rectrack].midiMess.unshift({
time: 0,
data0: 144,
data1: track[rectrack].midiMess[i].data1,
data2: 0
});
console.log("Yeah man");
}
else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==128) {}
else if (matchArray[j]==false && track[rectrack].midiMess[i].data0==144) {matchArray[j]=true;}
else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==144) {}
j++;
}
i++;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-13 00:31 -0700 |
| Message-ID | <25ea52ae-7494-4441-8e5a-981aaed9ab81@googlegroups.com> |
| In reply to | #37539 |
Den söndag 13 oktober 2019 kl. 09:07:30 UTC+2 skrev Jonas Thörnvall:
> Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall:
> > Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> > > Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > > > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > > > Jonas Thörnvall:
> > > > >
> > > > > > This is an on and off problem. The general rule for midi is there should
> > > > > > be an on "for the specific note, before there is an off for it".
> > > > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > > > it is the interval between on and off that is played.
> > > > > >
> > > > > > This problem is due to the musician "user", may push midi notes outside
> > > > > > the boundaries of the specified recording time/ slot .
> > > > >
> > > > > var t=track[rectrack].midiMess;
> > > > >
> > > > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > > > >
> > > > >
> > > > > // So for any midi event related to controller 0, you append a note-off
> > > > > event for controller 0, after previous attempts to stop after the first
> > > > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > > > revealed that you didn't catch many cases?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > var savetime=t[0].time;
> > > > > var i=0;var j=0;
> > > > > earlyfound=false;
> > > > >
> > > > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > > > i++;
> > > > > }
> > > > >
> > > > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > > > >
> > > > > // earlyfound==(t[0].time>t[t.length-1].time)
> > > > >
> > > > > j=i+1; // == length-1
> > > > > i=0;
> > > > > if (earlyfound==true){
> > > > > console.log("found early note");
> > > > > while (i<j) {
> > > > > t[i].time=rs+1;
> > > > > i++;
> > > > > }
> > > > > }
> > > > >
> > > > > // So, if the last Message in MidiMess has a timestamp before the first
> > > > > Message in MidiMess, all Messages except the last get the same timestamp?
> > > >
> > > > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> > > >
> > > > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> > > >
> > > > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> > > >
> > > > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> > > >
> > > > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> > > >
> > > > And it have to be done from both side, Start "offs" and end "ons"
> > >
> > > bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
> >
> > Well now i see why i thought this indeed will be even more cumbersome then i remembered, had not had my coffee.
>
> Ok i had my coffee, i think this is it "for the early notes case", a bit weird but is seems like the order of the conditions do matter??????
>
> function earlyNotesFix() {
> //Note on = 144 Note off = 128
> var i=0;
> while (track[rectrack].midiMess[i].data0 != undefined && track[rectrack].midiMess[i].time<=re-1)){
>
> var j=0;
> while (track[rectrack].midiMess[i].data0!=matchArray[j] && (track[rectrack].midiMess[i].data0==144 || track[rectrack].midiMess[i].data0==128){
> if (matchArray[j]==false && track[rectrack].midiMess[i].data0==128){
> matchArray[j]=true;
> track[rectrack].midiMess.unshift({
> time: 0,
> data0: 144,
> data1: track[rectrack].midiMess[i].data1,
> data2: 0
> });
> console.log("Yeah man");
> }
> else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==128) {}
> else if (matchArray[j]==false && track[rectrack].midiMess[i].data0==144) {matchArray[j]=true;}
> else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==144) {}
> j++;
> }
> i++;
> }
> }
Realise now i solved same problem a different way earlier, either you find the early notes and set them all to time zero. But now i find the noneclosed notes and make a start for them....
But then i would first have to remove the early notes...
Well the first approach i did do seem much simpler.
I guess i step back to the earlier solution.
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-13 00:47 -0700 |
| Message-ID | <176b8a97-f98e-4c48-8a96-4510e9f3e539@googlegroups.com> |
| In reply to | #37540 |
Den söndag 13 oktober 2019 kl. 09:31:27 UTC+2 skrev Jonas Thörnvall:
> Den söndag 13 oktober 2019 kl. 09:07:30 UTC+2 skrev Jonas Thörnvall:
> > Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall:
> > > Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> > > > Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > > > > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > > > > Jonas Thörnvall:
> > > > > >
> > > > > > > This is an on and off problem. The general rule for midi is there should
> > > > > > > be an on "for the specific note, before there is an off for it".
> > > > > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > > > > it is the interval between on and off that is played.
> > > > > > >
> > > > > > > This problem is due to the musician "user", may push midi notes outside
> > > > > > > the boundaries of the specified recording time/ slot .
> > > > > >
> > > > > > var t=track[rectrack].midiMess;
> > > > > >
> > > > > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > > > > >
> > > > > >
> > > > > > // So for any midi event related to controller 0, you append a note-off
> > > > > > event for controller 0, after previous attempts to stop after the first
> > > > > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > > > > revealed that you didn't catch many cases?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > var savetime=t[0].time;
> > > > > > var i=0;var j=0;
> > > > > > earlyfound=false;
> > > > > >
> > > > > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > > > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > > > > i++;
> > > > > > }
> > > > > >
> > > > > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > > > > >
> > > > > > // earlyfound==(t[0].time>t[t.length-1].time)
> > > > > >
> > > > > > j=i+1; // == length-1
> > > > > > i=0;
> > > > > > if (earlyfound==true){
> > > > > > console.log("found early note");
> > > > > > while (i<j) {
> > > > > > t[i].time=rs+1;
> > > > > > i++;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > // So, if the last Message in MidiMess has a timestamp before the first
> > > > > > Message in MidiMess, all Messages except the last get the same timestamp?
> > > > >
> > > > > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> > > > >
> > > > > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> > > > >
> > > > > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> > > > >
> > > > > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> > > > >
> > > > > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> > > > >
> > > > > And it have to be done from both side, Start "offs" and end "ons"
> > > >
> > > > bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
> > >
> > > Well now i see why i thought this indeed will be even more cumbersome then i remembered, had not had my coffee.
> >
> > Ok i had my coffee, i think this is it "for the early notes case", a bit weird but is seems like the order of the conditions do matter??????
> >
> > function earlyNotesFix() {
> > //Note on = 144 Note off = 128
> > var i=0;
> > while (track[rectrack].midiMess[i].data0 != undefined && track[rectrack].midiMess[i].time<=re-1)){
> >
> > var j=0;
> > while (track[rectrack].midiMess[i].data0!=matchArray[j] && (track[rectrack].midiMess[i].data0==144 || track[rectrack].midiMess[i].data0==128){
> > if (matchArray[j]==false && track[rectrack].midiMess[i].data0==128){
> > matchArray[j]=true;
> > track[rectrack].midiMess.unshift({
> > time: 0,
> > data0: 144,
> > data1: track[rectrack].midiMess[i].data1,
> > data2: 0
> > });
> > console.log("Yeah man");
> > }
> > else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==128) {}
> > else if (matchArray[j]==false && track[rectrack].midiMess[i].data0==144) {matchArray[j]=true;}
> > else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==144) {}
> > j++;
> > }
> > i++;
> > }
> > }
>
> Realise now i solved same problem a different way earlier, either you find the early notes and set them all to time zero. But now i find the noneclosed notes and make a start for them....
>
> But then i would first have to remove the early notes...
> Well the first approach i did do seem much simpler.
>
> I guess i step back to the earlier solution.
Just realised it will be even more cumbersome i will have to first find the interval recorded on track and only check with those notes. Probably should have a default empty recording track and then move the notes into the "real track".
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-17 00:30 -0700 |
| Message-ID | <93a233ae-5ee8-40bb-ad7b-bcfe7a7beb93@googlegroups.com> |
| In reply to | #37541 |
Den söndag 13 oktober 2019 kl. 09:47:40 UTC+2 skrev Jonas Thörnvall:
> Den söndag 13 oktober 2019 kl. 09:31:27 UTC+2 skrev Jonas Thörnvall:
> > Den söndag 13 oktober 2019 kl. 09:07:30 UTC+2 skrev Jonas Thörnvall:
> > > Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall:
> > > > Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall:
> > > > > Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall:
> > > > > > Den lördag 12 oktober 2019 kl. 16:15:00 UTC+2 skrev Jan Bruns:
> > > > > > > Jonas Thörnvall:
> > > > > > >
> > > > > > > > This is an on and off problem. The general rule for midi is there should
> > > > > > > > be an on "for the specific note, before there is an off for it".
> > > > > > > > Otherwise weird things happen when you playup. One other thing to know,
> > > > > > > > it is the interval between on and off that is played.
> > > > > > > >
> > > > > > > > This problem is due to the musician "user", may push midi notes outside
> > > > > > > > the boundaries of the specified recording time/ slot .
> > > > > > >
> > > > > > > var t=track[rectrack].midiMess;
> > > > > > >
> > > > > > > while (t[i].data0 || undefined && (t[i].data0==144 && t[i].time>=rs)){
> > > > > > >
> > > > > > >
> > > > > > > // So for any midi event related to controller 0, you append a note-off
> > > > > > > event for controller 0, after previous attempts to stop after the first
> > > > > > > non-Note-On Message for Controller 0 (found in a backwards search)
> > > > > > > revealed that you didn't catch many cases?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > var savetime=t[0].time;
> > > > > > > var i=0;var j=0;
> > > > > > > earlyfound=false;
> > > > > > >
> > > > > > > while (t[i].time<t[i+1].time && i<t.length-2){
> > > > > > > console.log("savetime "+savetime+"> midimess "+t[i+1].time);
> > > > > > > i++;
> > > > > > > }
> > > > > > >
> > > > > > > if (savetime>t[i+1].time) {earlyfound=true;console.log("found early");}
> > > > > > >
> > > > > > > // earlyfound==(t[0].time>t[t.length-1].time)
> > > > > > >
> > > > > > > j=i+1; // == length-1
> > > > > > > i=0;
> > > > > > > if (earlyfound==true){
> > > > > > > console.log("found early note");
> > > > > > > while (i<j) {
> > > > > > > t[i].time=rs+1;
> > > > > > > i++;
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > // So, if the last Message in MidiMess has a timestamp before the first
> > > > > > > Message in MidiMess, all Messages except the last get the same timestamp?
> > > > > >
> > > > > > Oh, sorry right now i crossed out the function calls i think?, and for some reason i can not upload updates to host. Refuse me to login.
> > > > > >
> > > > > > But as i said code to scroll thru all must be written i though i done that, but not sure.I do not think i have because you would have to have an array with all "notes" and cross them of after you matched. I think i just do the early cases the ones before any note on....
> > > > > >
> > > > > > So i think i know what is wrong, it just took a time to realise that "starting" off notes could come anywhere in stream.
> > > > > >
> > > > > > Implementing it well not that fun, because i have to keep track of which one that is cleared....
> > > > > >
> > > > > > Was a long time since i did a matching with a conditional loop looking into extra array "if in cleared notes do nothing" else "early case fix it".
> > > > > >
> > > > > > And it have to be done from both side, Start "offs" and end "ons"
> > > > >
> > > > > bascily i am thinking using an array for both cases at start they are filled with unmatched, and you keep going until "all notes matched". Then there can be no more wandering notes.
> > > >
> > > > Well now i see why i thought this indeed will be even more cumbersome then i remembered, had not had my coffee.
> > >
> > > Ok i had my coffee, i think this is it "for the early notes case", a bit weird but is seems like the order of the conditions do matter??????
> > >
> > > function earlyNotesFix() {
> > > //Note on = 144 Note off = 128
> > > var i=0;
> > > while (track[rectrack].midiMess[i].data0 != undefined && track[rectrack].midiMess[i].time<=re-1)){
> > >
> > > var j=0;
> > > while (track[rectrack].midiMess[i].data0!=matchArray[j] && (track[rectrack].midiMess[i].data0==144 || track[rectrack].midiMess[i].data0==128){
> > > if (matchArray[j]==false && track[rectrack].midiMess[i].data0==128){
> > > matchArray[j]=true;
> > > track[rectrack].midiMess.unshift({
> > > time: 0,
> > > data0: 144,
> > > data1: track[rectrack].midiMess[i].data1,
> > > data2: 0
> > > });
> > > console.log("Yeah man");
> > > }
> > > else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==128) {}
> > > else if (matchArray[j]==false && track[rectrack].midiMess[i].data0==144) {matchArray[j]=true;}
> > > else if (matchArray[j]==true && track[rectrack].midiMess[i].data0==144) {}
> > > j++;
> > > }
> > > i++;
> > > }
> > > }
> >
> > Realise now i solved same problem a different way earlier, either you find the early notes and set them all to time zero. But now i find the noneclosed notes and make a start for them....
> >
> > But then i would first have to remove the early notes...
> > Well the first approach i did do seem much simpler.
> >
> > I guess i step back to the earlier solution.
>
> Just realised it will be even more cumbersome i will have to first find the interval recorded on track and only check with those notes. Probably should have a default empty recording track and then move the notes into the "real track".
Well i fixed so that all recordings go to a separate track, and "after correction applied" move it to "recording" track.
Problem is that i must program the correction...
I think i know in principle howto to it. It is just a bit of a mental excersize to actually do it. So i keep implementing other things, just implemented a quantizer. When you actually understand how they work they are simple just prerender timevalues and move the note to the nearest.
https://midisequenser.000webhostapp.com
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2019-10-17 10:34 +0200 |
| Message-ID | <h0qnclFci44U3@mid.individual.net> |
| In reply to | #37572 |
On 17.10.19 09:30, Jonas Thörnvall wrote: > Den söndag 13 oktober 2019 kl. 09:47:40 UTC+2 skrev Jonas Thörnvall: >> Den söndag 13 oktober 2019 kl. 09:31:27 UTC+2 skrev Jonas Thörnvall: >>> Den söndag 13 oktober 2019 kl. 09:07:30 UTC+2 skrev Jonas Thörnvall: >>>> Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall: >>>>> Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall: >>>>>> Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall: [...] Why do you constantly abuse this newsgroup as your personal notebook? -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2019-10-17 10:08 -0700 |
| Message-ID | <8f215ffb-8e87-46aa-bf45-df5e5120d3e9@googlegroups.com> |
| In reply to | #37573 |
Den torsdag 17 oktober 2019 kl. 10:34:36 UTC+2 skrev Arno Welzel: > On 17.10.19 09:30, Jonas Thörnvall wrote: > > > Den söndag 13 oktober 2019 kl. 09:47:40 UTC+2 skrev Jonas Thörnvall: > >> Den söndag 13 oktober 2019 kl. 09:31:27 UTC+2 skrev Jonas Thörnvall: > >>> Den söndag 13 oktober 2019 kl. 09:07:30 UTC+2 skrev Jonas Thörnvall: > >>>> Den söndag 13 oktober 2019 kl. 08:55:19 UTC+2 skrev Jonas Thörnvall: > >>>>> Den lördag 12 oktober 2019 kl. 19:34:16 UTC+2 skrev Jonas Thörnvall: > >>>>>> Den lördag 12 oktober 2019 kl. 19:31:58 UTC+2 skrev Jonas Thörnvall: > [...] > > Why do you constantly abuse this newsgroup as your personal notebook? > > -- > Arno Welzel > https://arnowelzel.de Oh someone is here to complain LoL, just kidding no problem we are all here to complain LoL
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.javascript
csiph-web