W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: MIDI Tracks and Sequences

From: James Ingram <j.ingram@netcologne.de>
Date: Fri, 14 Sep 2012 17:52:16 +0200
Message-ID: <505352B0.9030505@netcologne.de>
To: Joseph Berkovitz <joe@noteflight.com>
CC: public-audio@w3.org, Chris Wilson <cwilso@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Hi Joe,

thanks for the reply. You said:
> I would much prefer to keep these responsibilities outside the API, in 
> ordinary JavaScript. I see too many opportunities for baking 
> inflexible behavior into the API without realizing it.
Yes, I understand that, but think that the data structures underlying 
Tracks and Sequences are so basic that it would be hard to see them 
becoming restrictive. In my version, for example,
     a Sequence contains an array of Tracks,
     a Track contains an array of MIDIMoments
     a MIDIMoment contains an array of MIDIMessages, all of which have 
the same timestamp.

If the API turned out to be too inflexible, it could be given more 
functions without changing the underlying data structures and without 
changing the existing functions.

Having said that, I'm going to try to do what you said, and write a new 
test implementing
> use setInterval() to periodically fire a single callback rather than 
> making a new setInterval() call each time, inside the callback. Also, 
> if you can avoid referencing variables in the enclosing scope I don't 
> think the stack will grow in the same way; you should be able to keep 
> the full sequencer state in a single object that sticks around, rather 
> than on the stack.
Not sure yet if this is going to work. I'm worried that setInterval is 
going to be too slow/unreliable. Whatever happens, this test is going to 
be a bit bigger than the others because I'm going to have to include the 
above objects. Will get back to the list when I'm done -- or have failed 
for some reason. :-)

best,
James


Am 14.09.2012 16:27, schrieb Joseph Berkovitz:
> James,
>
> I do see that the closure scope of the setInterval() callback will 
> grow over time -- not exactly recursion, but not desirable. However 
> this seems avoidable if you use setInterval() to periodically fire a 
> single callback rather than making a new setInterval() call each time, 
> inside the callback. Also, if you can avoid referencing variables in 
> the enclosing scope I don't think the stack will grow in the same way; 
> you should be able to keep the full sequencer state in a single object 
> that sticks around, rather than on the stack.
>
> I am also working on MIDI-related sequencing but like Chris W, I would 
> much prefer to keep these responsibilities outside the API, in 
> ordinary JavaScript. I see too many opportunities for baking 
> inflexible behavior into the API without realizing it.
>
> …Joe
>
> On Sep 14, 2012, at 5:07 AM, James Ingram <j.ingram@netcologne.de 
> <mailto:j.ingram@netcologne.de>> wrote:
>
>> Hi Chris, Jussi, all,
>>
>> There is, after all,  a problem with my latest test [1]: Its fine for 
>> fairly small sequences, but it does not scale well.
>>
>> The problem is that the sendMIDISequence() function is recursive. And 
>> it has to be that way because of the way setInterval() works. The 
>> stack is growing during the performance, and the likelihood of 
>> garbage collections (or even a crash) is increasing all the time. 
>> What happens if I want to play a 5 hour piece at a conservative 20 
>> recursions per second?
>>
>> My instinct says that the player should really be executing on a 
>> background worker thread, and using an ordinary sleep() function 
>> instead of setInterval().
>>
>> But Javascript hasn't got an ordinary sleep() function, and I don't 
>> think you should give it one. Exposing a sleep() function would 
>> probably cause the whole world to seize up. :-)
>>
>> So I still think the best solution would be to define Track and 
>> Sequence objects, and put the thread handling behind the API.
>> The Track and Sequence objects would be quite independent of any file 
>> format. Populating them would be done by Javascript programmers (or 
>> libraries), using functions in the Track and Sequence interfaces.
>>
>> best,
>> James
>>
>> [1] http://james-ingram.de/tests/JazzMIDIBridge/ji-known-sequence5.html
>>
>> -- 
>> www.james-ingram-act-two.de <http://www.james-ingram-act-two.de>
>>
>>
>>
>
> ... .  .    .   Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> Boston, Mass.
> phone: +1 978 314 6271
> www.noteflight.com <http://www.noteflight.com>
>


-- 
www.james-ingram-act-two.de
Received on Friday, 14 September 2012 15:52:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 September 2012 15:52:57 GMT