good philosophical response that also works for the general life ..Once again Usine shows me that it already knows the answer, I just hadn't figured out the right way to ask the question
Also I wanted to show senso that I recognize I may have been somewhat annoying with 'not a bug' reports and feature requests like this. So far its all been a function of not fully 'getting it', whatever 'it' was at the time. Thanks for the help man!
I think I have the logic finally baked to perfection.
And regarding this feature request, I only today found the synchro setting that detaches it from the sound engine 'on/off'. and it is 'on/off' that triggers the 'init', so you can easily have a longer period of "loading" with scripts and modules triggered by 'init' and only turn the synchro on when you want to.
So, feature request: already there!
Statistics: Posted by ceasless — 08 Oct 2013, 22:27
]]>
Once again Usine shows me that it already knows the answer, I just hadn't figured out the right way to ask the question
good philosophical response that also works for the general life ..Statistics: Posted by nay-seven — 07 Oct 2013, 22:58
]]>
Either way it's working!
Once again Usine shows me that it already knows the answer, I just hadn't figured out the right way to ask the question
Statistics: Posted by ceasless — 07 Oct 2013, 22:46
]]>
I attempted your solution with using an 'init' input and writing a callback. (I also had already moved it down to the 'process' procedure before posting originally, I believe I mentioned it). It still does not solve the issue.
It seems to me that having a difference between the 'init' procedure (which cannot access the data in the flux that are already attached) and something like 'post-init' (which can access and change the flux before the user starts the sound engine) would be useful in more cases than just this example. If it's not too complicated to add, would you consider it?
Statistics: Posted by ceasless — 07 Oct 2013, 11:29
]]>
]]>
What I need is to get the parameter value (and set the array outs to the right values) before the play button is pressed.
Statistics: Posted by ceasless — 30 Sep 2013, 10:42
]]>
also you can add an inlet "start init" which can be connected to an "on activation" module?
Statistics: Posted by senso — 29 Sep 2013, 19:26
]]>
]]>
CODE:
if firstTime := 0Statistics: Posted by ynohtna — 24 Sep 2013, 18:28
]]>
CODE:
if firstTime := 0 then begin writeln('interesting'); for i:=0 to IOs-1 do begin p := ((prev-1) * IOs) + i; setLength(stepOut[i],STEPs); for s:=0 to STEPs-1 do begin temp[s] := getDataArrayValue(memory[p],s); setDataArrayValue(stepOut[i],s,temp[s]); end; end; firstTime := 1; end;Statistics: Posted by ceasless — 23 Sep 2013, 11:02
]]>
However, in this init procedure you do not have access to things that are already set in the patch. This means that you cannot get the current value of a parameter, even if that parameter has a value that has been saved in the patch/workspace.
My use case is making sure that an array outlet is actually sending the values that have been stored, rather than all '0's which is what happens now. When re-loading the workspace, Tthe array outlets on the 'Pattern Store' script are all set to 32 0s, rather than the value they held when the workspace was saved. In my Init code I removed the bits that I put it in to properly initialize them to 0 when the script is first added to the patch.
So, I propose a new built in procedure that would be called when the workspace is re-loaded.
BTW, I've worked around this by using the Process procedure and having a one-time run of the code that sets the array out using the saved value in the parameter. This is a problem though because the first note in the sequence is never played.
Statistics: Posted by ceasless — 23 Sep 2013, 10:46
]]>