Poke inside Poly? (to allow 2x upsample)
So I had made another thread (https://cycling74.com/forums/interpolation-and-non-contiguous-buffer-writing-ipoke-alternative) about trying to write to a buffer using interpolation (like ipoke) but being able to also write non-contigious samples (which breaks ipoke)by jumping around the buffer.
It then occurred to me that I could perhaps cheat my way around the zipper sound when upsampling poke (by not filling every sample) by sticking poke inside a poly and setting the upsample to 2, so it would be running at 88.2k. Not sure if that will do what I think it will do though.
My thinking is, I want to be able to read/write at a rate between 0. and 2. (it was previous 10, but I could live with it being lower). If I record at a 0 writes non-contigious samples, resulting in that shitty zippery sound. Now if my sample rate is 88.2k, that means I should be able to record at 2x my normal rate, without artifacts.
The thing is I've never used poly to do this kind of thing, so I'm unsure what needs to happen.
Do I stick just the recording object in the upsampled poly? (in this case poke)
Do I stick the buffer in there? Do I need to double the size of the buffer from what I need?
What about the playback object? (groove in this case) Do I send it the messages I normally would, or does it now want x2?
What about the sync signal? I'm using grooves output doing the [*~44100] method. Does that need to become [*~88200]?
Does vector size come into play here?
etc...
Or is there a tutorial on doing upsampled recording that I've missed somewhere.
"Now if my sample rate is 88.2k, that means I should be able to record at 2x my normal rate, without artifacts."
one of the main reasons why and when to use upsammpled DSP - yet you should
not forget that you will be downsampling again when you go out of the poly~ patcher.
"Do I stick the buffer in there? Do I need to double the size of the buffer from what I need?"
yeah as far as i get you, you´d have the buffer upsampled as well, and yes, it needs to be
twice the size. or well, actually, when your buffer has an argument in milliseconds, it
will have twice the size from alone when inside a [poly~ foo up 2].
"What about the playback object? (groove in this case) Do I send it the messages I normally would, or does it now want x2?"
that depends wether it is inside the poly~ patcher or not. :)
"Does that need to become [*~88200]?"
just a thought, dont use "44100" anywhere in your patch. always get the samplerate using
dspstate~ whereever you need the samplerate, and such abstractions will work anywhere.
your friend might use 48000 ...
"Does vector size come into play here?"
nope.
-110
Ok, so if I understand you right, since I downsample when I come out, I want to have my playback object in there too, and just have the audio itself come out? (Otherwise I'd be getting nowhere?)
Wait, I confused myself again.
So if I have poke/buffer inside the poly, (driven by 2x the sample rate from outside), it's writing a buffer with twice the information that it would normally have.
Hence on the 'outside' I can play back the buffer at half the rate I normally would, but still near it at 100%? (0.5)
So then I would have a range from 0. to 1. in terms of playback speed (which is effectively 0. 2. as there's twice as many samples now?)
That's a good call on the 44.1k thing. I've got a bunch of those littered around.
Ok, did a bit of testing and it seems if I have just the poke object in a poly and I drive it with 2x the sample rate it's creating a loop half as short as it seems like it should be.
So a 2000ms buffer is producing a 1000ms audio bit. I'm guessing that's working right?
.....................
Actually I spoke too soon. It's producing the right length file. How can I test that it's working?
Here's a stripped down version of the main patch (and the poly)
when exporting into a file, the length will remain intact when the samplingrates are identically.
you could also export from a up 2 poly patcher into a 44 khz file - an it will play with only half the original speed.
if it is only about playback possibilities one could also just change the header of the soundfile using
soundhack or peak and claim it would be 44 when it is in fact 88.
It's funny, I've started typing a reply to this thread about 3 times now, each one starting with the lines "I think I've finally figured it out", then I quit it, and go test, and the rinse/repeat.
I'm baffled by this upsample thing!
So things inside an upsampled poly. Does the stuff inside the poly run as if my sample rate is double what I've set it to?
I thought if I had my recording object inside the poly, and drove it (from the outside) using the sync signal as if I was driving a poke object twice as big, that it would work. But that isn't the case. I tried different combinations of having the buffer/playback/record objects inside the poly, and couldn't get it anywhere.
I guess it kept breaking down at the driving/sync signal. If it's only the poke inside, running at 88.2k, with a buffer outside of 1000ms, then shouldn't I be able to write a 1sec buffer by sending the poke object (from the outside) a ramp from 0-88200? (not the case).
Documentation on upsampling is also a bit thin (it just mentions that it's up/down sampled, and that's kind of that). It doesn't explain how that works in terms of recording, or buffers, or playback, etc...
up 2 makes it twice as fast as the parental patcher, no matter what that is.
if you encapsulate a [poly~ bubu 16 up 2] inside a [poly~ bubu 16 up 4] the
inner one has a samplingrate of the current msp rate*4*2. (e.g. 44.100*8).
what can be quite confusing is the interface to the world outside the poly, or
attempts to connect to the discrete time layer (i.e. writing a file).
"Does the stuff inside the poly run as if my sample rate is double what I've set it to"
define "stuff".
at first, when a signal goes into an x2 upsampled subcircuit, nothing more happens
than that now every sample will be copied one time.
0 0 0 0
->
00000000
the opposite happens when you leave the poly patcher: every second sample will be
deleted, only every other will make it out.
when you now writes files from an upsampled buffer it is suddenly becoming so
complicated that you loose overview, dont worry, that is normal for the first 2 weeks. :)
Are you limited to what your soundcard can do? In terms of upsampling. Can I upsample*8 like that with no problem?
That's exactly the stuff/part I'm stuck on. Writing to a file inside an upsampled poly. Rather, creating a soundfile with 2 (or 8) more times information than normal, so that I can modulate the playback rate while recording (up to 2 (or 8)) without having gaps in the sample.
So if I want a 1000ms audio file, but with 88200 (or 352,800) samples in it, what goes inside the poly? (poke, poke/buffer, poke/buffer/groove)