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
> 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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
34 matches
Mail list logo