@hardoff said:

theoretically, this approach should also work well with changing the
pitch while playing, if i am not totally mistaken. i never tried to
implement it myself yet, but since you send a message to [vline~] you
also know at any time, where [vline~] actually is. the idea is to
measure the time between the inital message to [vline~] and the moment,
where you want to change the pitch. with the timevalue and the values
from the initial message you could calculate [vline~] actual position.
with taking into account [vline~]'s actual position and the new pitch,
you could generate a new message for [vline~]. like that, it should be
possible to change the pitch at any time with (sub-?)sample accuracy and
without having jumps in the playback

Would anyone care to elaborate on how this might work. I can get my walnut of a brain round how it wouldn't just restart everytime.....

well, i the thinking was, that you'd restart from the position where you left off.

but the logic there is really convoluted, and now i think i'd probably just do all that in a way like this:

[0, 4410000 100000(
|
[t b b]
| |
[vline~]
|\ |
| \ |
| \ |
| [snapshot~]
| /
[+~ ]
|
[tabread4~ $0-sample]

edit, no, that's not exactly right, the snapshot~ needs to be triggered after the [+~]

i've attached a patch which shows the basics.

http://www.pdpatchrepo.info/hurleur/snapshotvline.pd

That's great, thx Hardoff for the example. Still when it comes to reversing theres going to be some more head scratching should n't be too hard

I was trying a replacement solution using [rpole~] as an integrator/accumulator, and it looks very interesting. Does anyone know whether this is sample accurate?

For the life of me i don't know why phasor~ has not been made sample accurate yet.... [vphasor~] anyone?

thanks

that won't work any better than phasor~, as snapshot~ is stuck on block boundaries just like phasor~ phase bashing...

attached is something that might be useful in this context...

http://www.pdpatchrepo.info/hurleur/rewrap~.pd

and a help patch...

http://www.pdpatchrepo.info/hurleur/rewrap~-help.pd

Hi ClaudiusMaximus,

I presume this is phase bashing at sample level?..i'm not entirely sure. Is that to do with [fexpr~] ?

For the benefit of myself and others, would you mind explaining what is happening in this patch?

many thanks

Ok: what it does is derive a second phasor from its input phasor.

If you want to go from [phasor~ 2] to [phasor~ 4], you can just use [*~ 2] and [wrap~]. If you want to go from [phasor~ 2] to [phasor~ 1] or [phasor~ 3], just using [*~] and [wrap~] won't do the job.

The patch I posted does some differentiation and integration, taking into account the jump in phasor~ and wrapping the output while integrating (to avoid float precision problems)

And now I realize that this is the solution to a different problem - will see what I can come up with for the real problem...

ok, here's an attempt at solving the correct problem

left inlet (float messages only) sets frequency in hz
right inlet (float messages only) sets phase
left outlet is a phasor~-like signal

note: doesn't support negative frequencies yet, shouldn't be too hard to add though

http://www.pdpatchrepo.info/hurleur/vphasor~.pd

and an example patch (open the http://www.pdpatchrepo.info/hurleur/vphasor~-help.pd