Here’s a more developed proof of concept of the simple coding environment I have been experimenting with.
The basis of it is the gm.csd code that is an adaptation of Istvan Varga’s fluidComplex.csd example in the manual, made to work with sfplay instead.
GMPlay.js is a little library of functions to provide an interface to that code allowing instruments to be played and sequenced. MIDI device input also works directly and alongside it.
What took me a while to crack was to get a solid clock for the sequencer. In the end, I used a combination of Csound scheduling and the AudioContext clock. That allowed me to be independent of the JS timer, but I can still use it to create the time recursion needed for the sequences to be played. Anyway, with what I have now, it is possible to start new sequences on the fly and in sync to the beat.
the system can be extended to have better synths beyond soundfonts, but the idea at the moment is to have a simple coding environment for run-of-the-mill music stuff.
Prof. Victor Lazzarini
Maynooth University
Ireland
all this stuff is awesome --- i am just going through your "vanilla" (actually much more than vanilla) examples and learning so much from it. thanks!!!
j
yes, the AudioContext clock is reliable. The issue becomes firing Csound events at a regular interval, which setTimout() can do.
If we use the audio clock to give us a reliable reference, we can fire events at or near the target time, even if setTimeout() is slightly late. That may give an error that is noticeable or not, but the overall pulse keeps going.
That works for the first minute or so, after that setTimeout() becomes really irregular becoming late at times by over 100ms.
The solution then is not to fire events at the time of the call but schedule them ahead, with the time difference between the audio clock and the target time taken in consideration.
That way, unless the error is absurdly high, events are scheduled correctly and Csound then takes care of delivering them in time. This also takes care of any minor timing errors and so it sounds much more correct.
Prof. Victor Lazzarini
Maynooth University
Ireland
Also, it is important to say that all of this trouble is only required if you are not programing in Csound, but doing everything in JS and only firing off inputMessages().
The simplest way to deal with time is to do all the sequencer programming etc in Csound. Then there is no hassle or need to deal with unreliable clocks.
This particular proof of concept is to see if Csound can be completely wrapped in JS and only used as a sound engine. All programming in this case is done in JS. The Csound code is just a standard CSD with two instruments (one to intercept midi, the other to run sfplay)
and nothing else.
Prof. Victor Lazzarini
Maynooth University
Ireland
Yes, that’s key. If you use Csound as the main clock you can’t go wrong. But this is also an interesting approach. Although I have to admit, I was scratching my head a little once you mentioned JS timers
or lazy-on-a-sunday-afternoon timers.