<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yiv3176907062"><div id="yui_3_16_0_1_1443324411747_12259"><div id="yui_3_16_0_1_1443324411747_12258" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;">> 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.<br clear="none"><div id="yiv3176907062yui_3_16_0_1_1443324411747_10115"><br clear="none"><span></span></div><div id="yiv3176907062yui_3_16_0_1_1443324411747_10116"><div id="yui_3_16_0_1_1443324411747_15322"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10554">I'm not exactly sure what "schedules itself" means here. So I'll just</span></div><div id="yui_3_16_0_1_1443324411747_15458" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10554">start explaining how it works until I understand it myself... :)<br></span></div><div><span id="yiv3176907062yui_3_16_0_1_1443324411747_10554"><br></span></div><div id="yui_3_16_0_1_1443324411747_15321"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10554">The [vline~]</span></div></div><div dir="ltr" id="yiv3176907062yui_3_16_0_1_1443324411747_10465"><div id="yui_3_16_0_1_1443324411747_12751" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">object processes blocks of samples at a time (in vline_tilde_perform)</span><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">. But</span></div><div id="yui_3_16_0_1_1443324411747_12752" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">any of those clock events Frank mentioned that happen to be "ripe" for</span></div><div id="yui_3_16_0_1_1443324411747_12881" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">the upcoming block get sent to the "float" method of line (vline_tilde_float),</span></div><div id="yui_3_16_0_1_1443324411747_13033" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">which adds them to the linked list x_xlist.</span></div><div id="yui_3_16_0_1_1443324411747_13174" dir="ltr"><br><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464"></span></div><div id="yui_3_16_0_1_1443324411747_13175" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">For example,</span></div><div id="yui_3_16_0_1_1443324411747_13195" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">suppose you have the following:</span></div><div id="yui_3_16_0_1_1443324411747_13196" dir="ltr"><br><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464"></span></div><div id="yui_3_16_0_1_1443324411747_13197" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">[0 0.1, 1 0.2(</span></div><div id="yui_3_16_0_1_1443324411747_13280" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">|</span></div><div id="yui_3_16_0_1_1443324411747_13198" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">[pipe]</span></div><div id="yui_3_16_0_1_1443324411747_13445" dir="ltr">|</div><div id="yui_3_16_0_1_1443324411747_13468" dir="ltr">[vline~]<br><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464"></span></div><div id="yui_3_16_0_1_1443324411747_13404" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">|</span></div><div id="yui_3_16_0_1_1443324411747_13405" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">[print~]</span></div><div id="yui_3_16_0_1_1443324411747_13489" dir="ltr"><br><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464"></span></div><div id="yui_3_16_0_1_1443324411747_13691" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">When you click the message box, [pipe] does the proper clock delay for</span></div><div id="yui_3_16_0_1_1443324411747_13692" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">each message: the "0" is scheduled for 0.1ms in the future, and the "1" is</span></div><div id="yui_3_16_0_1_1443324411747_13615" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">scheduled for 0.2ms. But these delay times take less time to fire than it</span></div><div id="yui_3_16_0_1_1443324411747_13632" dir="ltr"><span id="yiv3176907062yui_3_16_0_1_1443324411747_10464">takes to compute a block. So if [vline~] is calculating its output in blocks<br></span></div></div><div id="yui_3_16_0_1_1443324411747_12269" dir="ltr"><div id="yui_3_16_0_1_1443324411747_13803" dir="ltr">of 64 samples, when does it actually receive the output from [pipe~]?</div><div id="yui_3_16_0_1_1443324411747_13823" dir="ltr"><br></div><div id="yui_3_16_0_1_1443324411747_13972" dir="ltr">The answer is that Pd actually sends the "0" and "1" messages to [vline~]</div><div id="yui_3_16_0_1_1443324411747_16068" dir="ltr">one after the other, before it calculates the next block. By "send" I mean it</div><div id="yui_3_16_0_1_1443324411747_14320" dir="ltr">calls the function vline_tilde_float with the float argument "0", and then it calls</div><div id="yui_3_16_0_1_1443324411747_14894" dir="ltr">vline_tilde_float with the float argument "1". But before each of those calls, it updates the "sys_time" to be the time when that clock was set to go off. So if the "0" was set to go off at "now + 0.1", Pd sets "now+0.1" to be the new system time, then it sends the "0" message to vline_tilde_float. And before it sends "1", <br></div><div id="yui_3_16_0_1_1443324411747_16107" dir="ltr">it sets the sys_time to "now + 0.2".<br></div><div id="yui_3_16_0_1_1443324411747_14437" dir="ltr"><br></div><div id="yui_3_16_0_1_1443324411747_14522" dir="ltr">Let's go back to vline_tilde_float-- notice in the first line we're fetching the</div><div id="yui_3_16_0_1_1443324411747_14690" dir="ltr">sys_time. And what is it going to be for our "0" message? As stated above, we</div><div id="yui_3_16_0_1_1443324411747_14734" dir="ltr">set it to "now + 0.1". Great! And when we process "1" message, we get "now + 0.2". Thus, [vline~] adds those messages and their associated timings to the linked list.</div><div id="yui_3_16_0_1_1443324411747_14735" dir="ltr"><br></div><div id="yui_3_16_0_1_1443324411747_14971" dir="ltr">Finally, we do [vline~] perform routine. It starts with the time equal to what it</div><div id="yui_3_16_0_1_1443324411747_16108" dir="ltr">was at the beginning of the block. Then it loops through our block's samples</div><div id="yui_3_16_0_1_1443324411747_15296" dir="ltr">until it reaches a sample that corresponds to the time that an event in our</div><div id="yui_3_16_0_1_1443324411747_16147" dir="ltr">linked list needs to be triggered. When we reach that sample, we jump to</div><div id="yui_3_16_0_1_1443324411747_15446" dir="ltr">the new value.<br></div><div id="yui_3_16_0_1_1443324411747_15297" dir="ltr"><br></div><div id="yui_3_16_0_1_1443324411747_16197" dir="ltr">It's the same process for ramps, except that vline~ calculates an increment</div><div id="yui_3_16_0_1_1443324411747_15447" dir="ltr">value for the ramp.<br></div><span></span></div><div dir="ltr"><span></span></div><div id="yui_3_16_0_1_1443324411747_16198"><br> </div><div id="yui_3_16_0_1_1443324411747_16199">After looking, I'm kind of curious what is most responsible for [vline~]</div><div id="yui_3_16_0_1_1443324411747_16200" dir="ltr">overhead. I'd guess it's the math needed to set each ramp segment, but I'm not</div><div id="yui_3_16_0_1_1443324411747_16213" dir="ltr">certain.<br></div><div id="yui_3_16_0_1_1443324411747_16035" dir="ltr"><br></div><div id="yui_3_16_0_1_1443324411747_16036" dir="ltr">-Jonathan<br></div><div id="yui_3_16_0_1_1443324411747_14487" class="yiv3176907062qtdSeparateBR"><br clear="none"><br clear="none"></div><div class="yiv3176907062yqt7004704919" id="yiv3176907062yqt78664"></div></div></div></div><div class=".yiv3176907062yahoo_quoted"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Saturday, September 26, 2015 10:55 PM, i go bananas <hard.off@gmail.com> wrote:<br clear="none"> </font> </div> <br clear="none"><br clear="none"> <div class="yiv3176907062y_msg_container"><div id="yiv3176907062"><div>I actually think Frank might have the my answer here. <div><br clear="none"></div><div>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 object jumps around, as it is being triggered on block boundaries, but the vline object is faithfully consistent in starting at the exact TIME i ask it to - regardless of blocksize, etc. </div><div><br clear="none"></div><div>The only logical answer i can see here, is the one Frank has given. I'm scheduling drums using a clock controlled by metro. </div><div><br clear="none"></div><div>So what i'm guessing that Frank is suggesting here, is that the scheduler is keeping a list of all the metro and delay bangs that should arrive in the upcoming block, and sceduling them to be hit while the block plays. 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. </div><div><br clear="none"></div><div>And i would guess that the normal line object is not capable of that. It just waits until block boundaries and starts its simple incrementation. </div><div><br clear="none"></div><div>So, going back to Jonathan's day-long block example, i can see now how that works. the line can only be triggered once, at the start of the block (i still have doubts that it would actually stretch to the length of the block though. I reckon a 50ms line is still gonna take 50ms. ) </div><div>But the vline has that linked list inbuilt, and it reads from the scheduler to see when it should be triggered. So if you had the day-long block, then vline's linked list is gonna end up with a full day's worth of messages in it! </div><div><br clear="none"></div><div>Anyway, i'll go back to the source code tomorrow and have another look. But pretty sure that i now see how it is the ability to look ahead at metro scheduled events that gives vline the accuracy i need. </div><div><br clear="none"></div><div>Thanks Matt for suggesting i look at the clock, and scheduler code, thanks Jonothan for the great example of the day long block - taking things to extremes like that is a good way to see how they work. And thanks Frank for finally turning on that lightbulb and suggesting the role that metro was playing here. </div><div class="yiv3176907062yqt4042857451" id="yiv3176907062yqtfd20277"><div><br clear="none"></div></div></div></div><br clear="none"><br clear="none"></div> </div> </div> </div></div></body></html>