<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Especially considering LFOs etc where a discontinuity could be a really big and noticeable problem.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 25, 2018 at 6:10 PM Matt Barber <<a href="mailto:brbrofsvl@gmail.com">brbrofsvl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">A virtue of keeping the phase is that it remains relatively continuous even with wacko dynamic patching</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 25, 2018 at 5:31 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah yeah, nevermind.  I forgot about the phase. So:<br>
<br>
1. frequency is 440<br>
2. a connection is made to [sig~ 0]<br>
3. whatever the phase happened to be at the time of the connection is<br>
applied to frequency 0<br>
<br>
I guess the phase could be reset to zero at graph-building time. On<br>
the other hand, people<br>
do such odd things with dynamic patching-- who knows if this would<br>
break some of that<br>
insanity.<br>
<br>
-Jonathan<br>
<br>
On Mon, Jun 25, 2018 at 3:55 PM, Matt Barber <<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>> wrote:<br>
> There are also ways of noticing when a connection is attached to the inlet<br>
> and that the connection is a signal, and you can reset phase at those times<br>
> instead.<br>
><br>
> On Mon, Jun 25, 2018 at 3:52 PM Matt Barber <<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>> wrote:<br>
>><br>
>> Only good way to do this is to reset phase when the dsp graph changes.<br>
>> [cyclone/cycle~] does this, in fact:<br>
>><br>
>> static void cycle_dsp(t_cycle *x, t_signal **sp)<br>
>>   cycle_gettable(x);<br>
>>     x->x_conv = 1.0 / sp[0]->s_sr;<br>
>>     cycle_phase_reset(x); // <------------------------------RESET PHASE<br>
>>     dsp_add(cycle_perform, 5, x, sp[0]->s_n,<br>
>>     sp[0]->s_vec, sp[1]->s_vec, sp[2]->s_vec);<br>
>> }<br>
>><br>
>> On Mon, Jun 25, 2018 at 3:40 PM Jonathan Wilkes <<a href="mailto:jon.w.wilkes@gmail.com" target="_blank">jon.w.wilkes@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi list,<br>
>>><br>
>>> Check out the following patch (attached):<br>
>>><br>
>>> 1. Click [bang(. You'll get a block of ones.<br>
>>><br>
>>> 2. Disconnect the output of [sig~ 0] from the input of [osc~ 440].<br>
>>><br>
>>> 3. Click the [bang( again. You'll get output based on the floatarg 440.<br>
>>><br>
>>> 4. Now re-connect [sig~ 0] to [osc~ 440]. You'll get indeterministic<br>
>>> output.<br>
>>><br>
>>> Is there any workaround to make the output deterministic in this case?<br>
>>><br>
>>> -Jonathan<br>
>>> _______________________________________________<br>
>>> L2Ork-dev mailing list<br>
>>> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
>>> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> L2Ork-dev mailing list<br>
> <a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
> <a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
_______________________________________________<br>
L2Ork-dev mailing list<br>
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div>
</blockquote></div>