Ah great, I'll use that for my experiments! The implicit 16 sample delay won't hurt. At this point in the signal chain, there needs to be an additional delay anyway. And delay times in my reverb experiments were between 30ms and 180ms so +0,33ms doesn't change the picture much.

TSG/patch/numVoices

A simple object that outputs nothing but the number of voices in the subpatch. I was surprised to find that this isn't there yet.

TSG/patch/polySpread

This object outputs a value between -64 and +64, depending on the voice number. The range is evenly spread across the voices.For 3 voices the output would be:

Voice: 1 2 3
Output: -64 0 +64

For 5 voices it would be

Voice: 1 2 3 4 5
Output: -64 -32 0 +32 +64

This is really useful to create a spread for stacking voices in unison or simply for creating some differences between voices in a polysynth. You can use the math/*c object to adjust the amount of spreading.When the random distribution is selected, the possible values will distributed randomly across the voices when the patch loads. This helps a lot when you want to use spreading in different places around a patch (Without it, voice 1 will receive the lowest possible value everywhere, which is stupid).

TSG/ctrl/potDemux 3

Can be used to control three parameters with a single potentiometer. It can easily be modified to have more outputs (layers), if required.The object has some features that the other solutions don't have:

Noise cancellation. Due to noise in the measurement, there can be value changes even if the potentiometer is not physically touched or turned. That's why I wrote the object so that after some time of inactivity, the pot has to be turned by a certain amount before new changes will be registered. This "deadband" is configurable. (This is a very common method used in many devices)

You can load initial values (patch changes for example) with a trigger pulse

The potentiometer response is configurable: After changing the layer, the corresponding output will be updatedA) to the current poti value, immediately when the poti is touched (overwrite mode)B) to the current poti value, after the poti has passed the current value of the output (pickup mode)C) so that the remaining travel of the potentiometer spans all the remaining travel of the value (scale mode). Please note that scale mode assumes your input value will be between 0 and 64.

Is this for your parch only, the 16 samples delay or is this for all Axoloti patches?

Have been trying to mke a Karplus strong, but I am also hitting a limit when I try to make the delay time really short, it seems like it won't go all the way to 1 sample delay.

In Pure Data, you have to set a new block size for 1 sample, instead of the standard 64 samples to be abel to make 1 sample deay. kind of just figured it was about the same issue as in PD but never really got around to try to fix it.

Hi there TSG,love your delay, but i have a problem with external syncing. Below a certain bpm (~180 or so), the output of your timer (timeri_1) goes >1024 (as it should), which after the >>6 shift goes to a negative number, i.e. -16 instead of 16. The result is of course that slow echos become random. I don't know enough about bitshifting to remedy that, but obviously the k-rate for the read time should go to 16 and up, at that point. Any idea how to fix that, by chance?

No, it's much shorter than that, as I said, about .3secs (i can get much longer delays using the manual time ctrl).The problem really is with the conversion from integer to f-rate by bitshift, as described in my first post. The MWE below is a `take-out miniature' from your echo object: the i-value goess from 15.58 to -16 when the input goes from 1023 to 1024. I'm sure there's an easy fix for this, so the i-value continues to go to 16 and up, i am just not the one to find it....

I think the issue might be that the integer value exceed the krate range it is send to and therefor it goes into minus. You cannot send values higher than 1023 from integer to krate, it won't work, so you have to add an extra step of bitshifting.I am kind of assuming the value you are sending is higher than 1023, since you have this issue.

You have to to the shifting in 2 steps. First bitshift the >>6 when the value is still integers. And then second do a <<21 bitshift to get it into krate range. Now I get the right result, at least up to 4096.

Anyway, try it out, let me know if it works.

UPDATE 1: ohh not sure that works, cause it rounds the number to whole numbers...... Illtake a look in the patch where I have it working.

I did some modifications to TSG/delay/read m interp: It now interpolates the input signals, so that removes any stepping from the modulation and drastically reduces noise at the expense of a tad higher CPU load.

I also added a phase output to the TSG/fx/tapedelay. It ramps from 0..64 in sync with the delay and you can use it to blink LEDs. Take a look at the help patch. Basically you only have to compare it to a fixed value (e.g. with math/>c) to get a boolean signal that is in sync with the delay.

Hey, apparently this part of the community library is missing in my folder... Is there a way to download these tools - I am sorry, if the answer is obvious but I haven't seen a download link or something like this - thx