mathseive

I've built a relatively simple step sequencer with js gui, but the basic info is stored in 3 funbuff's and a coll, and triggered with a metro/counter combination. 

The problem is the timing is really poor, even to my unmusical ears. I presume this is some kind of efficiency issue. The timing is even worse when you are altering things in the gui, although i have ensured that a message is only sent out on release of the mouse button etc. 

At the moment it's literally one track, which can store upto 128 note numbers, associated velocities, trigger times and durations. It also uses about 90% of my cpu so something wrong must be going on. I have ensured the notes are triggered at the right point using a delay and the stash object. 

I've built a relatively simple step sequencer with js gui, but the basic info is stored in 3 funbuff's and a coll, and triggered with a metro/counter combination. 
The problem is the timing is really poor, even to my unmusical ears. I presume this is some kind of efficiency issue.  The timing is even worse when you are altering things in the gui, although i have ensured that a message is only sent out on release of the mouse button etc. 
At the moment it's literally one track, which can store upto 128 note numbers, associated velocities, trigger times and durations.  It also uses about 90% of my cpu so something wrong must be going on.  I have ensured the notes are triggered at the right point using a delay and the stash object.  
There are no msp objects, it's all max.

efficiency-in-js-coll-funbuff

without seeing a patch/script, it's hard to know exactly how to help.

but i think it's worth mentioning (as has been mentioned in various places on this list) that js is not the methodology to use for calculating timing-critical events.

coll operates quickly (as does jitter). in terms of changing the data in realtime i would suggest using some sort of updating mechanism whereby you can input the js-info (at low priority) into the patch without disturbing the sync and have it output upon the next servicing...

without seeing a patch/script, it's hard to know exactly how to help.
but i think it's worth mentioning (as has been mentioned in various places on this list) that js is not the methodology to use for calculating timing-critical events.

coll operates quickly (as does jitter).  in terms of changing the data in realtime i would suggest using some sort of updating mechanism whereby you can input the js-info (at low priority) into the patch without disturbing the sync and have it output upon the next servicing...
see example below.

efficiency in js / coll / funbuff