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
for
how, both [cyclone/sampstoms~] and [cyclone/mstosamps~] will convert number
input only to number outlet. I thought this didn't make sense, and in fact
in Max it also converts to signal output. It makes sense though that audio
input only converts to signal output.
cheers
2015-09-19 19:55 GMT-03:00
> And what vline does, is it reads that list, and then schedules itself to be
> hit after the correct amount of logical time has elapsed.
I'm not exactly sure what "schedules itself" means here. So I'll juststart
explaining how it works until I understand it myself... :)
The [vline~]object pro
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 [l
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
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 say I'm just
> kidding.
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 what you want to use t
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
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 v
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 co
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 the
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 a
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 to
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
UNSUBSC
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 three
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 somehow
16 matches
Mail list logo
