Phasors/Tables - how to set playback frequency dynamically?

[Navs]

Hello Axoloti community,

first post here - thanks for this wonderful device and your examples!

I am having difficulty understanding the relationship between phasors and tables and hope you can help.

As I understand it, Axoloti’s table sizes are fixed. So, to play back some recorded audio at the original pitch, I need to set the phasor’s frequency according to the table size, e.g. for a table 65536 samples long, I need a phasor running @ 0.73Hz (48000/65536).

How do I set the phasor’s rate for a dynamic length, e.g. in the case of a live audio recorder/looper?

I have found an example for how to do this in Pure Data and found an equivalent in rbrt’s ’stimer’ and sample2frequency modules but I can’t get the patch to work with live values. On playback, the pitch of the recorded audio does not match the input - the resulting frequency still seems to be tied to the table size.

Am I approaching this incorrectly? I have tried ‘proper’ phasor modules but these run too fast and also looked at rbrt’s looper modules for clues but can only see code when editing/opening them. I'm new to this sort of patching, so go easy on me

Many thanks,
Navs

[axoman]

I could be wrong, and no way to check right now, but, I don't think you have to do anything as specific as that with the phasor. I get the impression the phasor is just used to drive a data pointer through the contents of a table, and the speed at which it reads through the data is determined by the speed of the phasor. So, to change playback frequency I believe you would just connect your desired objects directly to the phasor and control it that way, I doubt it would make any difference whether what you connected was dynamic or not.

The other thing you mention, about length, that has more to do with the tables themselves and that's something I've wanted to do as well but have been unable to get a demonstration of such a technique. For example I wanted to be able to use two knobs; one to set the start position of a sample, the other the set the end, and to be able to discard everything that fell outside of that region, and save the result to an SD card. I think the problem is there is no sure way of addressing or controlling length of the contents of a table. I'm getting quite a bit out of my comfort zone here though, so I'm likely not understanding something.

Anyway, I hope someone helps you cause it might even indirectly help me understand table access and data manipulation better.

[Navs]

Thanks, Axoman. Sometimes one needs to write things down to see the problem properly. Your comments helped: the speed and distance travelled by the phasor are not the same thing.

The phasor travels from zero to 64, so you can use analogue logic - a min/max function - to set or limit the start and end points. I have an Axoloti patch that does this, but saving to SD card is beyond my Axo-skills

Now I need to figure out the maths to apply this to a live variable ...

[jaffasplaffa]

If you want to play files that are different size than table, you can do that. But unfortunately in Axoloti we can not, like PD, change the actual tablesize dynamically, so instead you need to compensate the range of the phasor, so it only plays back a part of the table.

And that's the most obvious thing that springs to my mind is, that you dont have any compensation after the phasor. You need it to only playback the part that you recorded. And it might not be too simple, cause for every table size there is, you need to bit shift the compensation value a certain amount. The bit shifting is what make things tricky in Axoloti world, in Pure data it's much simpler cause you can work with real world value like samples and ms, etc. But in Axoloti you can also use those values you just need to bithift a bit to get the right values. So keep that in mind, that you probably need to add some bitshifters too.

If you for example is playing a file that is 34565 samples and the table size is 65536, using the set up below in your picture, it will only set the phasor to play the sample at right speed...... BUT the phasor ill still play through the whole table, so you need to set some kind of compensation.

Like this for example, using a math/*c for the compensation, you can feed any value that you get automatically from the speed into "b", to set that "file length" compensation automatically.

And also try use the scopes to see what actually is going on, so you understand better what you need to fix. It makes it much easier

If you set the math/* "b" input to full(64) it will playback the whole table, if you set it to 32 it will playback half the table etc. You need to find out how to set this compensation value automatically too. It's possible, you can probably find you own way of doing that with some of rbrts objects. Oh, and its for the "b" input you are going to need the bit shifting.

[Navs]

Thanks for the pointers - below is what I have come up with.

A phasor runs at the correct speed for the table length. If the recording/button-press is longer than the table length, the whole table is played. If the recording is shorter, the length is expressed as a percentage to divide 64 and provide a limter value for the min logic. When the phasor and limiter value are the same, the phasor is reset.

Is there a more efficient way to do this ... or have I just re-invented one of rbrt's wheels?

you are going to need the bit shifting.

What is this and why do I need it?

[kausto]

Hello Navs! Was rocking your nordmod patches for some time)

I dunno maybe this topic could help?

[solved] Pd sampler.rockafella example on axoloti

Hi all, Noob question : I try to reproduce B14.sampler.rockafella.pd on an Axoloti patch. Here Sampler_1_5.axp (6.6 KB) a patch that play sample with time compression/expansion by looped sample. [image] But I can't link "chunk length" with the first phasor frequency in order to change chunk size, without change the global pitch. An idea ? PS : my last patch for playing with samples Sampler_4.axp (21.9 KB)

[jaffasplaffa]

What is this and why do I need it?

Sorry for the late reply. I am actually not sure what the right term for it is, but Axoloti uses different types of math, that uses less memory, dsp, etc.. The ranges of these math types are a lot smaller, than what is used in real world, so to go form real world values, like milliseconds and samples, to values that in Axolotis system correspond to those real world values, you need to bitshift.

Argh, sorry I think someone else need to explain the math stuff. I am not that familiar with how its made I just use it, hehe