SineRPhaseInput.axp (3.1 KB)
Can anyone try it too? In version 1.0.8 on Win10 it doesn't seem to work.
Lfo/sine r. Does phase inlet work?
yes it works BUT phase is only set on reset.
(I dont think this has changed in 1.0.8)
there is perhaps an argument, that says phase should be used on initialisation....
(though you would have to be very careful with execution order to ensure this acted as expected!)
though you can achieve this simply by attaching a inv object to the reset trigger. (inv acts like a loadbang in max 
)
EDIT:
actually there is a bug/issue in sine/r which stops the 'loadbang' working, I think R should be initialised to 1.
this allows the reset to be triggered at startup, and so use the phase.
alternatively, we could make it such that phase is automatically used on first exec of k-rate
@johannes thoughts?
... and will it be the same in other similar objects?
kausto
#3
Ah ok, got it! Thanks. Was expecting different behaviour. Some 1px bracket, linking this arguments could be useful — note for the future module layout improvements i guess.
yeah, I think theres two things here:
perhaps the description needs to be clearer... emphasising its only done on reset.
we perhaps need some clarity, the startup value of an inlet when its got a trigger inlet, should it be used as a default, without a trigger event.
I think the expectation that it takes the phase inlet as a startup value is probably what many would expect. and at the very least, it should be possible to easily make this happen. (like with a loadbang))
But Id like to get @johannes opinion before changing anything...
I think what Id propose, as its most 'backwardly compatible' is:
I create an onload object, which fires on startup (I think we need an explicit one, as many ask for this), I make it just that this firing at startup will immediately set the phase to inlet_phase for the first execution.
the other option, but Im not so keen... is we do what other objects do , which is add a phase parameter, this would be used as the starting value/offset... this has been the norm so far.
johannes
#5
Checking every exec at k-rate if it's the first one is something I prefer to avoid as much as possible.
Pre-setting the phase to the parameter at start would be nicer to do in the initialization function of the object. But currently the initialization code of an object does not get access to parameters. Long, long time ago, parameters were accessible in initialization code, but I removed that, though I cannot recall the exact reason why.
Could this issue wait a bit till the development of inlet-parameter unification?
[SOLVED]Can you call param_x dinamically inside a for function?
What do you think of setting R = 1 in init(), this will mean as soon as you raise trig to 1 it will set phase.
this can be done at startup of a patch by connecting an inv to trig.
ok, done... @kausto if you do a 'sync libraries' it will now magically work 
adapt you patch, as follows:
(note.. the careful placement of inv and value, to ensure correct execution order.)
btw: @johannes do you think we should create a onload object... (I guess patch/onload ? )
using inv, is perhaps not obvious to everyone.
(this fast fix and deliver is fun )
johannes
#9
mixed feelings: this strategy adds cpu load, and should only be used as a last resort. It 'd be a useful object when there is no other way. I'm also thinking more generally, at the same "cost" it could be a generic k-rate cycle counter compare, perhaps the should be a global k-rate cycle counter, rather than multiple duplicate k-rate counters... So I suggest, as a temporary solution, put it in contrib/tb/... rather than in factory...