2017-11-24

Last night, in my sleep, I figured out a few more perf tweaks I can make. I made some tweaks to doubleBind (which is used for just about all of the file -> interface links) the other day that means I can get rid of the direct feedback. This should speed things up a bit (no need to diff the changes twice for every change). When I went to implement it and profiled it, I also noticed that I had left the throttle for templateSlot updates off. It was generating updates (that take 5ms each) every 6 ms. WHAT. TOO MANY. Enabled the throttle and param updates are silky smooth again.

Another thing that happened while I was sleeping last night is that naudiodon supposedly got its ‘overflow’ bug fixed. I’m probably gonna ignore this for now as I got recording inputs working well enough for my current pressing needs. But worth revisiting this in the future!

Found an input bug where opening and closing other setups stops the qwerty input from working. But can’t reproduce. May have been caused by switching in and out of profiler (happened twice).

——

JAMMING YO! Discovered that something is horribly wrong with midi sync over time. Should investigate this! Oh wait, it looks like when you remove a midi clock sync, it doesn’t destroy it.

Also the recording editor wouldn’t let me play past the 8 min mark. STRANGE. But once I deleted earlier clip, it worked.

Just remembered something else I was thinking about last night. The recording editor should have busses. Kind of like Final Cut Pro X roles. When recorded, they they are tagged with their input number and a bus is created. You should be able to edit the volume of a bus, or export it individually.

—

Looks like the reason that the midi clock stops working perfectly after a while is because performance.now() (which is used by midi) and audioContext.currentTime drift slowly out of sync. I was measuring the initial offset and then calculating the midi clock based off that, however eventually the offset becomes greater than the cycle time and it starts jittering. Interestingly enough, the two clocks do not drift (at least over the period I observed) when I’m using my Macbook’s internal soundcard, but when I use my K-Mix it drifts about 5ms every minute.

Now I have to figure out a reliable way to generate a clock that matches the audioContext but isn’t bound to it.

I have set up a ScriptProcessorNode that checks the offset between the clocks every so often and calculates the non-jittered offset in ms. This seems to be enough to stop the midi clocks rattling on my devices.

However I have noticed that the midi messages are getting throttled when Loop Drop isn’t visible on the screen (app backgrounding I suspect).

gah, just spent the last hour and a half messing with speaker positions…. whoops.