crazy day at the caffee again \
On Sat, Sep 26, 2015 at 5:23 PM, <pd-list-requ...@lists.iem.at> wrote: > Send Pd-list mailing list submissions to > pd-list@lists.iem.at > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.puredata.info/listinfo/pd-list > or, via email, send a message with subject or body 'help' to > pd-list-requ...@lists.iem.at > > You can reach the person managing the list at > pd-list-ow...@lists.iem.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-list digest..." > > > Today's Topics: > > 1. Re: How does vline~ work under the hood? (Jonathan Wilkes) > 2. Re: How does vline~ work under the hood? (Matt Barber) > 3. Re: How does vline~ work under the hood? (Jonathan Wilkes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 26 Sep 2015 22:08:16 +0000 (UTC) > From: Jonathan Wilkes <jancs...@yahoo.com> > To: Frank Barknecht <f...@footils.org>, "pd-list@lists.iem.at" > <pd-list@lists.iem.at> > Subject: Re: [PD] How does vline~ work under the hood? > Message-ID: > <655463103.1338937.1443305296609.javamail.ya...@mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > 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 visualized this [line~]quantization to > new users at the outset they'd almostalways use [vline~]. After all, who > wants imperfect lines? :) > -Jonathan > > > > > > On Saturday, September 26, 2015 12:57 PM, Frank Barknecht < > f...@footils.org> wrote: > > > 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 message was triggered by something with a "clock" inside. These > kinds > of messages are called clock-delayed messages. > > Clock-delayed messages originate in objects like [metro] or [delay] or > [qlist]. > Messages that originate for example in mouse clicks are not clock-delayed > (i.e. > if you click a [bng] or move a slider). > > vline~ evaluates clock delayed message with high, sub-sample timing > accuracy. > line~ quantizes even clock delayed messages to block-boundaries or to 64 > samples, I'm not sure ATM which it is. But line~ quantizes. > > So depending on when the message was issued any by what, the ramp > generators > may act the same or different. > > Try delaying the message: > > [bang( > | > [delay 0.3] > | > [1. 0 50( > | > [line~ or vline~] > | > [print~] > > Ciao > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.puredata.info/pipermail/pd-list/attachments/20150926/74bfc8e2/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sat, 26 Sep 2015 19:45:51 -0400 > From: Matt Barber <brbrof...@gmail.com> > To: Jonathan Wilkes <jancs...@yahoo.com> > Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> > Subject: Re: [PD] How does vline~ work under the hood? > Message-ID: > < > caorke7fa+xhya5jzdg_-bhhqfku-q400w-+n1umfgw4e1mt...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 a subpatch or abstraction in a synth bank at the end of a quick fade, > it's nice to know that you can target things to boundaries without having > to try too hard. > > On Sat, Sep 26, 2015 at 6:08 PM, Jonathan Wilkes via Pd-list < > pd-list@lists.iem.at> wrote: > > > Hi Frank, > > The [1, 0 50( message will almost always trigger different > > output when fed to [line~] and [vline~]. The only exception > > is when the ramp ends exactly on a block boundary-- > > otherwise [line~] will stretch the final part of the ramp to > > the block boundary. > > > > In fact, I'm willing to bet that if visualized this [line~] > > quantization to new users at the outset they'd almost > > always use [vline~]. After all, who wants imperfect lines? :) > > > > -Jonathan > > > > > > > > > > > > On Saturday, September 26, 2015 12:57 PM, Frank Barknecht < > > f...@footils.org> wrote: > > > > > > 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 message was triggered by something with a "clock" inside. These > > kinds > > of messages are called clock-delayed messages. > > > > Clock-delayed messages originate in objects like [metro] or [delay] or > > [qlist]. > > Messages that originate for example in mouse clicks are not clock-delayed > > (i.e. > > if you click a [bng] or move a slider). > > > > vline~ evaluates clock delayed message with high, sub-sample timing > > accuracy. > > line~ quantizes even clock delayed messages to block-boundaries or to 64 > > samples, I'm not sure ATM which it is. But line~ quantizes. > > > > So depending on when the message was issued any by what, the ramp > > generators > > may act the same or different. > > > > Try delaying the message: > > > > [bang( > > | > > [delay 0.3] > > > > | > > [1. 0 50( > > > > | > > [line~ or vline~] > > | > > [print~] > > > > Ciao > > -- > > Frank Barknecht _ ______footils.org__ > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.puredata.info/pipermail/pd-list/attachments/20150926/347bc293/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Sun, 27 Sep 2015 00:23:28 +0000 (UTC) > From: Jonathan Wilkes <jancs...@yahoo.com> > To: Matt Barber <brbrof...@gmail.com> > Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at> > Subject: Re: [PD] How does vline~ work under the hood? > Message-ID: > <626288233.1379665.1443313408523.javamail.ya...@mail.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > 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 < > brbrof...@gmail.com> wrote: > > > 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 a subpatch or abstraction in a synth bank at the end of a quick fade, > it's nice to know that you can target things to boundaries without having > to try too hard. > On Sat, Sep 26, 2015 at 6:08 PM, Jonathan Wilkes via Pd-list < > pd-list@lists.iem.at> wrote: > > 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 visualized this [line~]quantization to > new users at the outset they'd almostalways use [vline~]. After all, who > wants imperfect lines? :) > -Jonathan > > > > > > On Saturday, September 26, 2015 12:57 PM, Frank Barknecht < > f...@footils.org> wrote: > > > 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 message was triggered by something with a "clock" inside. These > kinds > of messages are called clock-delayed messages. > > Clock-delayed messages originate in objects like [metro] or [delay] or > [qlist]. > Messages that originate for example in mouse clicks are not clock-delayed > (i.e. > if you click a [bng] or move a slider). > > vline~ evaluates clock delayed message with high, sub-sample timing > accuracy. > line~ quantizes even clock delayed messages to block-boundaries or to 64 > samples, I'm not sure ATM which it is. But line~ quantizes. > > So depending on when the message was issued any by what, the ramp > generators > may act the same or different. > > Try delaying the message: > > [bang( > | > [delay 0.3] > | > [1. 0 50( > | > [line~ or vline~] > | > [print~] > > Ciao > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.puredata.info/pipermail/pd-list/attachments/20150927/d296db97/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Pd-list mailing list > Pd-list@lists.iem.at > to manage your subscription (including un-subscription) see > http://lists.puredata.info/listinfo/pd-list > > > ------------------------------ > > End of Pd-list Digest, Vol 126, Issue 118 > ***************************************** > -- john benson
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
