Same pitchshift algorithm sound different in GEN and MSP !?!
In this little attached patch i have the exact same pitchshift algorithm in gen and in msp… but it sound different! (Better, more fluid in gen)
Can you tell me why or point my mistake?
(I’m benchmarking different monophonic pitchshift algorithms in this topic: http://cycling74.com/forums/topic/monophonic-pitchshift-engines-benchmark-psola-in-gen/ )
…And I would love to add some kind of formant control in this gen algorithm… if, by chance, anyone have some directions to do that… :-)
Apparently it’s a behaviour of tapout that cannot delay less than the vector size… man… hmm, It would be nice if there would be a warning in the max window when one try to do so…
So when i replace tapin/tapout by delay~, now the sound is the same! (apparently)
Also, then i don’t understand why people are using tapin/tapout instead of delay~ to make some overlap-add pitch shift algorithms, which make the delay go down to 0 all the time, and thus sound bad…
( here was a topic about this strange tap out thing: http://cycling74.com/forums/topic/tapintapout-vs-delay-am-i-imagining-this/ )
tapin~/tapout~ introduce one vector size of delay to permit feedback: you can loop back tapout~ to tapin~, assuming you put some gain control in order to destroy your ears ;-) so the minimum of delay that you can have is one vector.
delay~ on the other hand let you have any delay you want, allowing the feedback to be within the object (so you can’t add other effects before in the feedback loop, it’s just gain control).
Gen works at the sample level and let you have 1 sample delay, which explain the sound difference that you may have with small delays.
I have a similar type of question. I was trying to implement a feedback-rich patch I have from back in the day in gen~. I couldn’t get it to behave similarly. Replaced filters with gen~-filters, boiled it down to tapin~/tapout~ behaviour. I am aware of the signal vector size issue and all that, so I decided to compare the delay lines. Turns out that, as shown in the attached patch, tapin~/tapout~ behaves differently if the delay time is controlled with a signal rather than with an int/float (!). So apparently, some internal algorithm (interpolation?) turns on when a signal is connected. Does this make sense? Am I missing something? I can’t find it in the docs, either.
----------begin_max5_patcher---------- 1738.3oc4ZkziaaCE9rmeED5RSAlwPTTxVt4TQAJ5wh1dKMX.sDsMyHQZHRM KIHyu8xEIaIaKINIiE7jdwFlOt79d6OR+kql3sj+HQ3A9EvG.Sl7kqlLwLjd fIU+dhWN9wjLrvLMOVY9RRwydWaossfHHLIVR4raKHIR6dEsvep+0f.zB8W9 Ue.9X8pvxjMT15lqHzthvH8WygleDzXMzTy4yW9oaBqO8UbljgyIFJ+ZAEmU SQwlTVFQZX5fpAExmxrysdZ47TRyYnVFuTdz5nq0+Tyf6O2U3DyRaNlf9YyX vfcS0tcxm1Rr3TuYLMeB7VkwwJz+Q8D+5UWo+3ZG0BI77bkXuFFRxiFwn2ug YLtDrj.RvkBRJX4SfRlRIkPEDf.muMSQhWxj.dA3gMXI4dRA3cepTHAIaHI2 ozJSm9ySq24LJiXlud6Qcq9lEpgL.Z0hvnX8WgyOs9aV3IUSvNUSsUK9eCBL qYqWO1eVK1J.D42m82Lz9MpPY9IIE2RX3kYsLH9lvVPWlMZClkX15uM6kC8Z 6D+AP+g8+lA+euCHi7fRRbj+m1CSH44hdE09ASi1KpWzmnNJ16rXNcNEB27L veX3CmahziB5E9yeg1SsgOb.3+Zh5bkd2n9cP0WEkY.U+rKXUeWIf9cUZkTR NmIjElhBtF72+EXCV.jbcZovvov69iOOE7mYDrJkTRFM4NvFRA4zobB5QVZr bPFqH3bi.Eg5PTN9Ib5R.slv5w9HHJpQnAjIKZfeGUAs3hATR71fdPUXbrAU 1Z6F.UwWRnB1CpfAKbWWM+hAU+yFUgfkK09mIZGT.eEPq+9IAPchaKk.Agja 7WU01WlIATFPvyI.Usgo5Ymwe.jnl2JZlpxGkP48pRJYxBdlx0cMPpNfTRF9 IfjpV0CT4F.FXi5.dmpdSFftxLqpwnBMccODIf6wYkje1bdazGyFUIODAfJE pnGav2S4kEmNRQXOdUPnIpKbtQGMGo+ZVWppnKoXEfa.C3bghMYQBsFfvpJW 6BbgWTdWCitJUminCcogt9i1GgdAZtfQGahsJNsfKR3aIO6fNxOz3WEWWV2o fAJ97TP2qbArCiVzLaKR1b.ccQE9Wdku5pVsNthSZ0n25Z0Jz5jVE81ooDUX H0w7L.562WKYnEKZTfVbuM+i99BxNxnmxbF7UsiG1K3COOfWwopRnXFd5b5T WkwwIe5fKIe5bhPfWSNRE+9+sHUrEHJTcVB2qleY8PZadL1utexSJN7eCDhS 4CMn4d8UP3OyXCf5ybOX1aFecUkVNj0tcyZcf53yLnaxkjhJnVg0Idptpz2I uP0ZVisahGd61FCOowRzBnOwMaz7q2MDkYGxe2PEj6o0qGsaTbgRVIUBpxBK rdLtVqWc+rErRpgUrCpTUWUug0h2XS.EcGw5uhMoQBhB2Kem3QRoRsNY45Dd lk09.ve5hqa7Ar4BVtNimbGIsIH7Tw2XTVyWcpE4TxJrpk0aO8cA2l9A2eba hm7Rsm3stflxYZlnktQOb8w8AUk7154aBFyLXprwGuXkImRN1AQcawkhk3Bs pq5AFBpIJ47r1j1stLxJYEYUNP1ARQIea2DKnq2zyZWxUDy6auMTD2VxrTuU 45JuUfuuszVhyxp7kau8OhYzbrjnu8.Cb82Qz9HKaDI56ZnEdsTt+DTRUV8I jGnoxMsdCAME0zoaqMh71okSoqIBY6wj30h1ibTf.0PkKq7puURx2loPQ6Iz 54Va5B2LpWqw6K5W6HfTF.1jvIi8aeiKSLvidhqCiC1Z2ZEKzuAgiECcFSr2 LfSpSETEi40W.YuTpl0ILfbx2jbb9rgDTnNETAuIETpS1USop1llOjHJrSQD 7EJh7OgLXebVcgec3fY.gl9oENBdYQRsntx7GzFOp.FpTX6x57gcZ+Cl2FZZ JgcniRJUniQk1EHt96liQNxwguRbbk8ncjWmx3ToLta3FXf1FUC68U5idyT6 5MCiX2tXheztWBK1c5ZIB9A6VIpftKWJAbbuSBCKzNPqUZbX3pJYxQgoz+mF 1G+wkXTGGe53XSGobbkclgbfcz+QD.vQgezu6ua7SexmbZ5VNkIqzQQP6+OK 6erml+Z+A85gf4tff3QSC6D+LCNZ7iK1+nwydyAtI9kYsMydESKr2CPfwly7 qygwlCr+3oZCbT0NNbCzAtIXz3FWhyhFQ1wknBnnKqnByGM1Q+1kCyOwWTdV GvymUqGjq7C7xgePiWULnPW3mwKTnKoIPgeGo4B8WbNSyE3TUgyFO4Y74T+Z 6w3fm7PyJG7TGG7LGG+DGc+7FG9zFpS9qW8e.akjktA -----------end_max5_patcher-----------
(unless i have missed that tapout~ really has that interpolation you are talking about built-in for some weird reason…) there is indeed a difference between sending signals and messages to signal objects, which can result in a different sound:
sending a number to tapout~ will cause a internal chance at the beginning of the next vector, sending a signal will … well, do the same, but is not bound to the scheduler. so under circumstances it can end up changing things one vector later.
(i once noticed this behavior with some other signal object, dont remember now what it was)
from the max 7 reference:
If a signal is connected to an inlet of tapout~, the signal coming out of the outlet below it will use a continuous delay algorithm. Incoming signal values represent the delay time in milliseconds. If the signal increases slowly enough, the pitch of the output will decrease, while, if the signal decreases slowly, the pitch of the output will increase. The continuous delay algorithm is more computationally expensive than the fixed delay algorithm that is used when a signal is not connected to a tapout~ inlet.
so it is intended. iow: for glide-free jumps in the position of tapout~, use messages exclusively.
That’s clear. However, in the given patch, I don’t change the values! Plus, I don’t necessarily want glide-free transitions, I want to understand what happens.
The patch I posted shows that the difference between two signals identically delayed by tapin~/tapout~ controlled with a message on one hand and a tapin~/tapout~ controlled by a signal on the other is not zero, i.e. there is some remaining signal, i.e. the signal is somehow changed by tapin~/tapout~ when controlled by a signal! I don’t see how this relates to the quote from the reference (I found that one before), since the delay times are nog changed in this example, thus whatever kind of interpolation or whatever takes place should not change the signal in this case, I would say. But clearly I am missing something here.
In any case, I would like to rebuild tapin~/tapout~ behaviour in gen~, for which I need to understand how tapin~/tapout~ functions internally. In any case, it’s beyond the signal vector size issue, as far as I can see.
I hope someone from Cycling ’74 can enlighten us on this one.
OK, figured it out after some browsing through the forums. Not that I found the exact answer, but some comment about subsample precision led me towards the answer. See attached patch!
It turns out that if you want a delay time with tapin~/tapout~ that’s exactly the same compared to delay~, you need to add half a sample delay. Funny and weird, as long as I can’t look inside the thing.
----------begin_max5_patcher---------- 1595.3oc6ZsraiaCEcsxWAg1zVTGCQ8vVoyptonKKZ6tzAAzRz1bhDofHURl YPy2d4CIaIaKIlFGUmAciMLuTT2y4duG9xe8JG2UrmvbWvOAtE3370qbbzMo Zvo92Nt4nmRxPbc2boU4qvkO6NyXq.IR1RnatqDmHLiSTTzbuY.+EdpuVB0+ vetG3i0OCIUORrUe55vlwYMiJnnbr1xOWRPYMVxYo5V8q+MW74LS2Z5gzkHz Lrf2tapAbMJQ2SuVswIeQ2FT5Q6edVk3vAfS1ne1ccyzGwmKvFbp5AU4m.20 YLjD8eT0w+9pqTeL6rwmK7L7oez374B3+Sn3GkLQCTD3mzznKGkWvErb9fot vkyi1S02LDUGE6ZGABGjUlTR3GeVR+QiS.vaz0tgQCR.KceYYPcI.3HDv4D2 4xHuNAvhfOLxlf+hK3feBKOGSEGwB+BqDjhyYTtnDIHL5Lve76fsHNPv.qvf vv4v6+0uLG7aYXDGCRxHI2C1hKwyaFqLBEmvpnh1n3TZVKUrWjNKBtT+UPPO TY3qhJ8NiDzFLcf7CeIN1KNDDqyO75YdsatX.k.U3OTVuWfFUlYqGAUwWRnB N.pfxbYqiUKuXP0etEC3UqT0mIpBT.aMPE+9NNP9FKpD.NFmqqWKw7pLAfPA bVNFbOglp5cF6QPhreqIYBbojT9.HQNIcIKSV5tAHjufTbF5y.AQ9TORDaAH fQ0A783GvT.YstW0sQ3J6BobQB3ATVE9GzuuspWyVDcClCHBtT8XK5ABqp7z JEgCTU4uPq5F3qiQKCTesnuPUzkjVA3ZvHEWgdgl4Q0nBZzC6MOL7hp5ZbzU G5rDcAWZnaX09EwufHm+jiMdgzSKY7DVA9YKhQP8xYLfJnmE0DD+1rfty5R4 t1BzFrbgNbciYNfdBZdWdKe01nZithUQ0n26Q0ZzZUTM38ylRjxPxWyy.nmm 2PnGF1ZAZwCt8+fWmH6DidB0ZvWug7vAAe3aC3kdpbITTsO8VVTWOiiU0z9W R0z4XNGsAeTH9C+UYJu.vKk6rDtOL+x1CYrNxGa1cRTOzg26.INYMzno6MGA gutJeQvPo69Kd2TqKWokEyZ2cyZ8f532XP21Kwk0PsFqNtxcUI2iTIWt0rVC miKpnnUyNsdDEA8IldfVNaWSDpoIucMUhefz77A6ZEUJ4JgjnpJMX8o3lnd8 A4VRqHZWwznLTcUy.1PuwZUSnuVWAZpm7iB2yuNt3ThPESVsIgkYbsaAdyuY VqOfsefUaxXI2iSaCBWo9FkPKj6LUtpa8AL0wbJdMRtk06N8gF209AGzbWim 7Xscb2TRRYTkSzI1nZt40cqbk7l0y2FL5dPkyFe7CKS4j7XOFUaKthuBUpBc qxZen5xjeFKqqocOWFdsn1rbNP5ArnfUzuwRxlsC7rqXRi4CM1ZK76pnFq2I KcE2wQOzksEnrr5Z4tC+SHJIGIvpSOPCWucFwTjDna4IpyZnCdMVd3DVRkY8 I3GIohsctZ.kEY2IEMIQt6hxojMXtnaaBzFd2VNRcP1T0p5p56D37hLIJ51g NWEV6R31pdcZeH0utJfDJ.11vIOHNcloYotdGpAdnNXmQ6XzdjdnWWCGqIN3 LfNMSETqwb9IHygR0dcBivSd5IGq2Rv.DUvKjn7uvIJ4a11To3aLaaZLJJ7E RQvdoHuSvA60YUK7qmBLMHT1OM4vYUkIMTccTEzEORAC4TX6l041cP6f9skj lhoGVRjR3JMpz9.wrWsGCsziCNSdbc9nokyyx3jSYb+3afAZ1nZn2f2e16l0 td83H1tCl3asykvfcqNVB+uwNUhZnaygR.m1yjP6BcEZMrwgxU0bxQxTpK0e u9SOZTK5Hlcr.0whSGEcNq9i5uhwT4OKrweVNh+jSRKXDpnNHE4uzLgsVGo8 u1+hNaHH1B.DrbxHTqbGYefSS30F2Ib5x1rhcBlN+wB2I9kk6uz7OtBZVtPf YlTn2aRpuMteP3qv+C8C+u1+mNoY0EnMNcNcRyA1LUQPzz4OgWVEuG7p5Qay axzZsxezA0Ixerwc7mrvkuUqzXwz4O1l8b43NSWsEzBu4eapiYM8GbECJG4f qV3fqU33qTn+qS3vqRP9l+6q9GzikgaN -----------end_max5_patcher-----------
That’s to say: when the delay time is controlled with a signal of course!
Forums > Gen