Re: [PD] How does vline~ work under the hood?

2015-10-17 Thread Alexandre Torres Porres
i was wondering if it worked well with block sizes less than 64, I find sometimes some object don't act well for such block sizes but I tested it and vline is fine ;) 2015-10-16 19:51 GMT-03:00 Jonathan Wilkes : > Hi Alexandre, > The [vline~] object can compute ramps with

Re: [PD] How does vline~ work under the hood?

2015-10-16 Thread Alexandre Torres Porres
> Does vline also have to wait for a block boundary when first triggered? this is probably cleared out and not sure if this is the question, but vline~ will respect the schedule timing of events with a delay of one block, meaning that it'll convert the events to audio rate but only for the next

Re: [PD] How does vline~ work under the hood?

2015-10-16 Thread Jonathan Wilkes via Pd-list
Hi Alexandre, The [vline~] object can compute ramps with subsample accuracy, regardless of the block size. Though I might not understand the question. -Jonathan On Friday, October 16, 2015 4:42 PM, Alexandre Torres Porres wrote: > Does vline also

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Joe White
Hey i go bananas, I can't say I'm totally familiar with Pd's specific implementation but I did this recently and a simple implementation is to store the target value and calculate how many samples it takes to reach it based on the delay time. In your loop decrement the number of samples to target

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Matt Barber
Post some code. :) In both [line~] and [vline~] I believe the increment is calculated, set, and unset set once per event, since all the info you need for the ramp is given by the event definition. Unsetting it is the fun part -- it doesn't unset once it's reached its target, but rather once the

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread i go bananas
Hi, me again. Thanks for the discussion. It has really opened my eyes. So, i got my naive c++ implementation of line~ basically working. And of course, just running a for loop incrementing by ticks, i run into the exact precision error that this block quantizing seems to avoid. My line from 0

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread i go bananas
yeah, am considering the option of just manually setting once the ramp finishes. But considering that i'm off by about 0.1% every 44100 samples, it's a bit worrying. Would be ok for synth envelopes, etc...but i'll probably want to use this to lookup audio file tables, etc too, in the future, so

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Matt Barber
Pd does the increment and time stuff in double precision. You're likely losing precision by going with float for everything; if you divide 100/44100 and get a float, and then increment 0 with it 44100 times, you're not necessarily going to end up with exactly 100 at the end. See attached. M On

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Jonathan Wilkes via Pd-list
There are probably a lot more ways to implement ramps.  For example, youcould increment only at block boundaries and just repeat that value for therest of the block.  That would looks a lot like Supercollider's "kr" ugens.  (Iactually thought that's how [line~] worked until I looked at the

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Matt Barber
You'll get zipper noise with the samphold per block approach. Cost to dereference a struct member is probably a little more than just using or getting a value. It's possible it'll be cached, though. On Oct 2, 2015 5:26 PM, "Jonathan Wilkes via Pd-list" wrote: > There are

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Jonathan Wilkes via Pd-list
Doesn't the audibility of zipper noise depend on the duration of the ramp? I seem to remember some Supercollider tutorials that used Line.kr witha duration of a second or so, and I don't remember hearing zipper noise.  (Alsomade a little Pd demo using [bang~] and a counter, but I don't know what

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Matt Barber
It'll have more to do with how large the increment is, and what an increment means psychoacoustically. If you ramp over the range of a piano in pitch over a second, incrementing every 64 samples, each increment will be about 12.5¢, which is likely to be audible. Or if you ramped from 20hz to 20khz

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread Jonathan Wilkes via Pd-list
I think I saw it used just to fade in and out on a sine tone. On Friday, October 2, 2015 9:52 PM, Matt Barber wrote: It'll have more to do with how large the increment is, and what an increment means psychoacoustically. If you ramp over the range of a piano

Re: [PD] How does vline~ work under the hood?

2015-10-02 Thread i go bananas
Audibility of zipper noise would depend on the ramp length (shorter ramp would have bigger zip jumps) , but would also depend heavily on what is being done with the ramp. Ramping the volume of a long bass tone would be much more audible than ramping the volume of a noisy wind sample. Matt, yep,

Re: [PD] How does vline~ work under the hood?

2015-09-28 Thread Jonathan Wilkes via Pd-list
Ok, looked again at the code: If you try to do a ramp in less time than it takes to compute a block, [line~] will stretch the ramp to fill one block. If the ramp takes longer than a block, the ramp will only extend to the last full block.  So if you specify a ramp timethat would normally take up

Re: [PD] How does vline~ work under the hood?

2015-09-27 Thread Frank Barknecht
Hi, On Sat, Sep 26, 2015 at 10:08:16PM +, Jonathan Wilkes wrote: > Hi Frank,The [1, 0 50( message will almost always trigger different output > when fed to [line~] and [vline~].  The only exceptionis when the ramp ends > exactly on a block boundary--otherwise [line~] will stretch ... or

Re: [PD] How does vline~ work under the hood?

2015-09-27 Thread Jonathan Wilkes via Pd-list
No problem.  This is a difficult part of the software to understand. -Jonathan On Sunday, September 27, 2015 9:16 PM, i go bananas wrote: My apologies for doubting you Jonathan.  The line object does indeed stretch to fill the whole block.

Re: [PD] How does vline~ work under the hood?

2015-09-27 Thread i go bananas
My apologies for doubting you Jonathan. The line object does indeed stretch to fill the whole block. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Re: [PD] How does vline~ work under the hood?

2015-09-27 Thread Matt Barber
The ramp segments themselves are pretty simple once they get going -- the entire thing is calculated at once, and then it's just a matter of adding the resulting constant increment until the target time has elapsed, or a new event supersedes the current ramp. This is less than the interpolation

[PD] How does vline~ work under the hood?

2015-09-26 Thread i go bananas
Thanks, I guess here is my question put better: If i make a line and a vline object, and feed them both a [1, 0 50( message, they perform differently. The line object jumps around, presumably cos it is tied to block boundaries. But the vline always triggers exactly the same. It's as if

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread i go bananas
In that case, maybe an even simpler question: What is the difference between sending a [1, 0 50( message to vline as opposed to line ? Why does line exhibit jitter, if both only trigger on block boundaries? ___ Pd-list@lists.iem.at mailing list

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Jonathan Wilkes via Pd-list
What I mean is that both [line~] and [vline~] receive their messages on block boundaries.But unlike [line~], [vline~] can start/end ramps and jump to the values you give it without beinglimited by block boundaries. Another example with my day-long block sizes: At noon on Monday you send a bang

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Jonathan Wilkes via Pd-list
Hi Matt,In my day-long block example, the [metro 150] is "triggering" the [tgl] to [vline~].  I am just usingday-long blocks to show that once a block has been computed you can't use [vline~] to travel back in time and change it.  You have to wait till Tuesday-- the next block. Of course you

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Matt Barber
It depends on what you mean by "trigger". Triggered by the mouse, I think you're right. But see the attached patch. Since [del] (among other objects, but I used [del] here for clarity) can schedule bangs between boundaries, you can trigger [vline~] in the middle of blocks. Not so with [line~]: if

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Matt Barber
It's because of the linear interpolation, which always sounds warmer. :) On Sat, Sep 26, 2015 at 8:23 PM, Jonathan Wilkes wrote: > I tend to use [vline~] in those cases because-- to my ears-- it sounds > warmer. > > (I so wanted to click send, but I have to come clean and

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Jonathan Wilkes via Pd-list
Hi Frank,The [1, 0 50( message will almost always trigger differentoutput when fed to [line~] and [vline~].  The only exceptionis when the ramp ends exactly on a block boundary--otherwise [line~] will stretch the final part of the ramp tothe block boundary. In fact, I'm willing to bet that if

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Jonathan Wilkes via Pd-list
I tend to use [vline~] in those cases because-- to my ears-- it sounds warmer. (I so wanted to click send, but I have to come clean and say I'm just kidding.) -Jonathan On Saturday, September 26, 2015 7:46 PM, Matt Barber wrote: Well, obviously it depends on

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Matt Barber
Well, obviously it depends on what you want to use the lines for. If it's just to fade something in or out over 10-50 ms to avoid a discontinuity, it's not that big a deal. Moreover sometimes it's great to have the ends and beginnings of ramps happen at block boundaries; e.g. when [switch~]ing off

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Jonathan Wilkes via Pd-list
One helpful reminder is that you're still triggering control events on blockboundaries. For example: imagine you set the block size to such a large value that eachblock lasts one day long.  In that case if you sent a message to vline~ at noonon Monday to jump to zero then ramp up to one in

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Frank Barknecht
Hi, On Sat, Sep 26, 2015 at 11:24:40PM +0900, i go bananas wrote: > In that case, maybe an even simpler question: > > What is the difference between sending a [1, 0 50( message to vline as > opposed to line ? There will only be a difference in how line~ and vline~ react to this message when

Re: [PD] How does vline~ work under the hood?

2015-09-26 Thread Matt Barber
As always, it's good to include a demo patch when you have a question like this. I wasn't sure what you meant by "jitter" initially, but now I understand it because [line~] isn't translating your [metro] faithfully. You can see that jitter in the patch I attached above. It's important to see how

[PD] How does vline~ work under the hood?

2015-09-26 Thread i go bananas
I actually think Frank might have the my answer here. What i'm noticing, is not an inconsistency in the length of the ramps. It's an inconsisency in when they are first triggered. This is for stuff like the initial click of a bassdrum, so you can even hear the difference quite clearly. The line

Re: [PD] How does vline~ work under the hood?

2015-09-25 Thread Matt Barber
Very quickly: 1) vline~ stores a linked list of events with start times and target times (the end point of the linear movement) using the t_vseg struct; events are scheduled in the vline_tilde_float routine. 2) vline_tilde_new sets all of the relevant struct members. You'll want to see how the

[PD] How does vline~ work under the hood?

2015-09-25 Thread i go bananas
I want to recreate the timing accuracy of vline~ in a c++ project, and there's something that i can't figure out exactly - how does it act, seemingly outside of the block construct, to get its accuracy? in the source code, there is a calculation for elapsed logical time, and i assume that has