Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34976 > unrolled thread

Loop vs shift() closeby events

Back to article view | Back to comp.lang.javascript

Contents

  Loop vs shift() closeby events Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-05-04 00:46 -0700
    Re: Loop vs shift() closeby events Julio Di Egidio <julio@diegidio.name> - 2018-05-04 01:34 -0700
      Re: Loop vs shift() closeby events Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-05-23 21:23 -0700
        Re: Loop vs shift() closeby events Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-05-24 02:29 -0700
          Re: Loop vs shift() closeby events Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-05-24 23:58 -0700
            Re: Loop vs shift() closeby events Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-05-25 13:50 -0700

#34976 — Loop vs shift() closeby events

function doPlayup() {
    if (copyEv.length) {
       var waittime = copyEv.shift();
       setTimeout(doPlayup, waittime); 
    } 
}

I am thinking that the shift() call maybe slow down the processing of closeby midievents? 
Would i gain tightness in performance by quantize lets say to 64 th notes, and have a buffer of 8 to 16 messages "for each quantised event"?

var len = arr.length;
while (len--) {
    // blah blah
}

[toc] | [next] | [standalone]

#34978

On Friday, 4 May 2018 09:46:46 UTC+2, Jonas Thörnvall  wrote:
> 
> function doPlayup() {
>     if (copyEv.length) {
>        var waittime = copyEv.shift();
>        setTimeout(doPlayup, waittime); 
>     } 
> }
> 
> I am thinking that the shift() call maybe slow down the processing of
> closeby midievents?
> Would i gain tightness in performance by quantize lets say to 64 th notes,

Can't you just have an array and increment an index?

-------------------------------
var copyEv = ...
var copyEvIdx = 0;

function doPlayup() {
  if (copyEvIdx < copyEv.length) {
    var waittime = copyEv[copyEvIdx++];
    setTimeout(doPlayup, waittime);
  }
}
-------------------------------

Julio

[toc] | [prev] | [next] | [standalone]

#35110

Den fredag 4 maj 2018 kl. 10:34:38 UTC+2 skrev Julio Di Egidio:
> On Friday, 4 May 2018 09:46:46 UTC+2, Jonas Thörnvall  wrote:
> > 
> > function doPlayup() {
> >     if (copyEv.length) {
> >        var waittime = copyEv.shift();
> >        setTimeout(doPlayup, waittime); 
> >     } 
> > }
> > 
> > I am thinking that the shift() call maybe slow down the processing of
> > closeby midievents?
> > Would i gain tightness in performance by quantize lets say to 64 th notes,
> 
> Can't you just have an array and increment an index?
> 
> -------------------------------
> var copyEv = ...
> var copyEvIdx = 0;
> 
> function doPlayup() {
>   if (copyEvIdx < copyEv.length) {
>     var waittime = copyEv[copyEvIdx++];
>     setTimeout(doPlayup, waittime);
>   }
> }
> -------------------------------
> 
> Julio

Thanks Julio will fix it today.

[toc] | [prev] | [next] | [standalone]

#35112

Den torsdag 24 maj 2018 kl. 06:23:46 UTC+2 skrev Jonas Thörnvall:
> Den fredag 4 maj 2018 kl. 10:34:38 UTC+2 skrev Julio Di Egidio:
> > On Friday, 4 May 2018 09:46:46 UTC+2, Jonas Thörnvall  wrote:
> > > 
> > > function doPlayup() {
> > >     if (copyEv.length) {
> > >        var waittime = copyEv.shift();
> > >        setTimeout(doPlayup, waittime); 
> > >     } 
> > > }
> > > 
> > > I am thinking that the shift() call maybe slow down the processing of
> > > closeby midievents?
> > > Would i gain tightness in performance by quantize lets say to 64 th notes,
> > 
> > Can't you just have an array and increment an index?
> > 
> > -------------------------------
> > var copyEv = ...
> > var copyEvIdx = 0;
> > 
> > function doPlayup() {
> >   if (copyEvIdx < copyEv.length) {
> >     var waittime = copyEv[copyEvIdx++];
> >     setTimeout(doPlayup, waittime);
> >   }
> > }
> > -------------------------------
> > 
> > Julio
> 
> Thanks Julio will fix it today.

Tried it was alot worse, do not know why.
But on the other hand i decided to remove any message sent to rec, echo and play outport that did not have begin with noteon 128 and noteoff 144.

That really did make a difference, in tightness there is probably things sent do the port that is not picked up but blocks.

There still slips here and there when to many tones at once, so it seem to need buffer notes with same timestamp, will try to fix that.

[toc] | [prev] | [next] | [standalone]

#35117

Den torsdag 24 maj 2018 kl. 11:29:11 UTC+2 skrev Jonas Thörnvall:
> Den torsdag 24 maj 2018 kl. 06:23:46 UTC+2 skrev Jonas Thörnvall:
> > Den fredag 4 maj 2018 kl. 10:34:38 UTC+2 skrev Julio Di Egidio:
> > > On Friday, 4 May 2018 09:46:46 UTC+2, Jonas Thörnvall  wrote:
> > > > 
> > > > function doPlayup() {
> > > >     if (copyEv.length) {
> > > >        var waittime = copyEv.shift();
> > > >        setTimeout(doPlayup, waittime); 
> > > >     } 
> > > > }
> > > > 
> > > > I am thinking that the shift() call maybe slow down the processing of
> > > > closeby midievents?
> > > > Would i gain tightness in performance by quantize lets say to 64 th notes,
> > > 
> > > Can't you just have an array and increment an index?
> > > 
> > > -------------------------------
> > > var copyEv = ...
> > > var copyEvIdx = 0;
> > > 
> > > function doPlayup() {
> > >   if (copyEvIdx < copyEv.length) {
> > >     var waittime = copyEv[copyEvIdx++];
> > >     setTimeout(doPlayup, waittime);
> > >   }
> > > }
> > > -------------------------------
> > > 
> > > Julio
> > 
> > Thanks Julio will fix it today.
> 
> Tried it was alot worse, do not know why.
> But on the other hand i decided to remove any message sent to rec, echo and play outport that did not have begin with noteon 128 and noteoff 144.
> 
> That really did make a difference, in tightness there is probably things sent do the port that is not picked up but blocks.
> 
> There still slips here and there when to many tones at once, so it seem to need buffer notes with same timestamp, will try to fix that.

Well buffering have to wait, i will make script send status messages with midichannel for each note so you can record/play different instruments.

The track solutions rather nifty i can have track zero as downmix/playback track of all messages because it hold all necessary data as intrument and minichannel and outport.

So you may say it is a bit extended midi, because i don't think GM can set different output ports without assigning a a single midi channel for each device to listen to. But modern DAWS have their own formats today, and support multiple outports not just midichannels i guess.

[toc] | [prev] | [next] | [standalone]

#35118

Den fredag 25 maj 2018 kl. 08:58:56 UTC+2 skrev Jonas Thörnvall:
> Den torsdag 24 maj 2018 kl. 11:29:11 UTC+2 skrev Jonas Thörnvall:
> > Den torsdag 24 maj 2018 kl. 06:23:46 UTC+2 skrev Jonas Thörnvall:
> > > Den fredag 4 maj 2018 kl. 10:34:38 UTC+2 skrev Julio Di Egidio:
> > > > On Friday, 4 May 2018 09:46:46 UTC+2, Jonas Thörnvall  wrote:
> > > > > 
> > > > > function doPlayup() {
> > > > >     if (copyEv.length) {
> > > > >        var waittime = copyEv.shift();
> > > > >        setTimeout(doPlayup, waittime); 
> > > > >     } 
> > > > > }
> > > > > 
> > > > > I am thinking that the shift() call maybe slow down the processing of
> > > > > closeby midievents?
> > > > > Would i gain tightness in performance by quantize lets say to 64 th notes,
> > > > 
> > > > Can't you just have an array and increment an index?
> > > > 
> > > > -------------------------------
> > > > var copyEv = ...
> > > > var copyEvIdx = 0;
> > > > 
> > > > function doPlayup() {
> > > >   if (copyEvIdx < copyEv.length) {
> > > >     var waittime = copyEv[copyEvIdx++];
> > > >     setTimeout(doPlayup, waittime);
> > > >   }
> > > > }
> > > > -------------------------------
> > > > 
> > > > Julio
> > > 
> > > Thanks Julio will fix it today.
> > 
> > Tried it was alot worse, do not know why.
> > But on the other hand i decided to remove any message sent to rec, echo and play outport that did not have begin with noteon 128 and noteoff 144.
> > 
> > That really did make a difference, in tightness there is probably things sent do the port that is not picked up but blocks.
> > 
> > There still slips here and there when to many tones at once, so it seem to need buffer notes with same timestamp, will try to fix that.
> 
> Well buffering have to wait, i will make script send status messages with midichannel for each note so you can record/play different instruments.
> 
> The track solutions rather nifty i can have track zero as downmix/playback track of all messages because it hold all necessary data as intrument and minichannel and outport.
> 
> So you may say it is a bit extended midi, because i don't think GM can set different output ports without assigning a a single midi channel for each device to listen to. But modern DAWS have their own formats today, and support multiple outports not just midichannels i guess.

To be honest the slipping that is still there could simply be notes that to tight played together, "having different timestamps" so the problem could actually be of lack of quantization not the lack of buffering. Why do functions calls of notes that differ by milliseconds in different calls, well it does not make sense but does it really need buffering?

In a infinitly fast computer probably no need of quantisation or buffering needed. I just can't decide where to start to try buffer notes or quantise, i know how to quantise them it is easy first you create the quantise events and then you move the notes to nearest quantised event. But to play simultaneous out from a buffer is that even possible to send multiple messages at once? I doubt it, but you probably can replace the sequential function calls "in my case" by read thru an array for each either quantised or nearby event?

If you use nearby events in array you at least have a priority list, once you quantise it is gone....

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web