[comparison] transratio vs. expr / speed test

    Nov 30 2012 | 5:10 pm
    ive heard somewhere that [expr] might be expensive for some sort of operations . well seems like its still the best solution to convert "midinotes" to "ratio" required by audio objects . if someone know the solution that will win over the [expr] , please post it here !

    • Dec 01 2012 | 1:27 am
      LUT? just shot in the dark, though
    • Dec 01 2012 | 11:06 am
      yes Andrzej ,good suggetsion , but what about interpolation then
    • Dec 01 2012 | 11:45 pm
      to be honest – i don't know. The easiest would be if [peek~] had an interpolation implemented (*** @cycling74: FR!!!! ***). But for now you have to do it yourself. I lastly learned about FTM – I don't know if there is any ready solution, but it seems it's worth checking. Or if you don't need very smooth transitions (for which you would have to do all calculations in signal domain anyway) just make the table large enough.
    • Dec 02 2012 | 10:57 am
      :) ... thank you Andrzej , i wanted to know about the other solutions anyway . its not bad that something has some difficulties , its all about to know what others may see as a substitution ,there might be some gems hidden or evils . brainstorming . in my case [expr] has very good results and does the natural interpolation . but i wouldnt mind to experiment with look ups ,there might be reasons for it ,so thanks again for pointing that out . need to check how much costs are required by doing interpolation yourself only .
    • Dec 02 2012 | 1:22 pm
      IMHO, comparing efficiency on something like that is not worth the trouble. The difference of a few micro seconds won't matter until you're doing that at very fast rate (which you're not since you're doing this operation on messages). I always advice my student to focus on readability vs efficiency.
      Also if you want to compare the efficiency, you might want to do the operation more than once, otherwise you measure mainly the rest of the patcher than the specific object. Using uzi 10000 gives a better idea. Notes: #1 the loop is done in JavaScript for the example (the more you stay in JS, the better). #2 js is faster, but runs in low priority that's why you need to wait for the process to be done, in order to trigger the next thing (see the extra outlet)
    • Dec 02 2012 | 4:02 pm
      hi Emmanuel ! . thank you for the clarification , ive learned two new things here . Also , considering that JS result , the number is higher because of the "crossing" time that is required for the outlets , right ? Does it also means that i do not need to be afraid of doing maths and checking conditions inside JS ?
    • Dec 02 2012 | 5:02 pm
      Yes, going in/out of js is slightly slower than with normal objects. You shouldn't be afraid with js at all ;-) It's pretty fast, runs with high precision (64 bits numbers, instead of 32 bits for Max). Don't forget though that it runs at low priority.
      well in short, for doing transratio operation… I would just use the abstraction, it comes with Max and it's really fast.
    • Dec 02 2012 | 6:10 pm
      :) great to know ! as for the abstraction . well, my engine needs to use that exponential result not just for the pitch . At first it provides the pitch but later on it is used for some loop calculations (for the groove~) to mimic "looping regions" . as from this and other lessons i would love to stay in JS for the pitch and other calculations thats need to be computed for the [groove~] , to minimize inlet/outlet crossing as much as possible .
      as for tests . Ive been doing comparisons basing on decimal points to see if im crossing the threshold of 1ms per operation , i believe that the whole thing (from pressing the KEY and hearing the result) should happen under this threshold . now i know how the get the correct order with advantage of low priority thread .
      thanks again