New and Improved uQuant V6 (Same Notes - Less Fat!)
  • While I was working on the Sandcastle demo I discovered it wouldn't run on my iPad. I was a bit surprised to find that the uQuant note quantizer was big part of the problem. I've spent the last couple of days fooling around to see if I could simplify things. This is the result. I've managed to reduce the CPU load by about %30. I think it's debugged :) I pulled the Encoder out since it adds to the load. Delete it if you don't need it.
    uQuant V6.audulus
    251K
    Screen Shot 2018-02-09 at 12.05.26 PM.png
    2480 x 1814 - 565K
  • New colors as well I see! Ty for the upgrade, I only use the uQuant in every patch!
  • The spiffy new colors are the result of simplifying the logic for the lights. Instead switching blue off and green on for the active note. I turn blue on low so you can see the keyboard, green on about halfway for the notes that are in key and red on full for the active note. I also use the uQuant almost every patch so it was worth the work. The new binary to decimal and decimal to binary converters are are definitely more efficient. The revised quantizer logic was difficult to get right. I didn’t want to give up the feature where it outputs the closest note to the input rather than the lower or higher one. Hopefully Taylor will do some further optimization on the expression node and I won’t need to do the same to too many other modules. I really prefer using the expression node rather than the add and multiply where it makes sense.
  • The expression node is the best, agreed. Well thanks for the upgrade nonetheless. If you wanted to, you could even remove transpose function. I can't think of a time where I have used it in ages since it doesn't update the display.

    And I'm not joking when I way I use it in every patch. Being able to generate random and exact scales with one value is just too handy.
  • I toyed with removing the transpose, but the CPU savings would be minimal. As an experiment I made a version without the key select and transpose, thinking it would be even more efficient, but the actual savings were not significant. BTW expressions that result in a constant value like "1/12" don't seem to be any more CPU intensive than the constant node. Also the value node does not display all the significant digits of the actual value stored. I don't know if the numbers used in Audulus are 32 or 64 bit, but I suspect 64. 32 bit floating point values have about 7 significant decimal digits and 64 have about 15. The display node only displays 6. While testing I noticed that I often had two values that showed the same number in the value node but returned false for "a==b". It's alway a good idea to avoid using an == comparison if you can use <= or >= instead.
  • @biminiroad These CPU tips might be worth including in documentation.