-
FFW
The messages come one by one (or two by two) so the
unpack
never get a 4 items list.You can accumulate the messages to 4 this way:
-
FFW
This is your triggerized patch:
You can see the right branch is triggered before the top-most
[t f f]
feeds the[pack]
so the numbers are all generated by the loop before they was printed.
EDIT: you stack computation branch and they are released deepest to shallowest so numbers are reverted. -
FFW
- Do not split the control flow without
[trigger]
- Why don't you use
[until]
?
- Do not split the control flow without
-
FFW
I think it's easier to dynamically upgrade the variable name with the [list prepend] right inlet.
-
FFW
[netsend]
help for the[send(
message says "same as list" so you can also do[hslider] | [list prepend z] | [netsend]
-
-
FFW
@fishcrystals said:
//these magic functions let us send human readable info to pure data void fudiStart(){ Serial.write(108); //Fudi Serial.write(105); //Fudi Serial.write(115); //Fudi Serial.write(116); //Fudi Serial.write(32); //Fudi } void fudiEnd(){ Serial.write(59); //Fudi Serial.write(10); //Fudi }
Could be:
//these magic functions let us send human readable info to pure data void fudiStart(){ Serial.print("list "); } void fudiEnd(){ Serial.print(" ;"); }
and become not-so-magic…
-
FFW
@jameslo If you have to restart the phasor at the state it stops you can follow your first idea and stop it at a specified moment, save the state and later restore and relaunch. What I propose is to only allow the phasor to stop at specific states (e.g. every 0.0001) so it's easier to save. When the stop is required the phasor will wait to reach an allowed state and then stop. So the stop time is fuzzy but the state is clear and clean.
I've no idea if and how it can be implemented or if it follow your requirement.
-
FFW
If you can't know the state of the phasor at a given stop time maybe you can stop it at a specified state and so transfer the incertitude to the stop time. It can be a solution, depending on what you need.
-
-
FFW
Hi,
my exploration of the iemguts library bring me this idea:
tooltip.zipEnjoy!
-
FFW
OK got it: setting the "gop mode" to zero is not enough, it has to be set with the large dimensions and then it can be shrink without ghosts.
And then it works with [coords( too.
EDIT: I've fixed it with a list:
-
-
-
FFW
@oid this simple test doesn't work so it's certainly a bug with my system.
I have another issue with comments:
And
[donecanvasdialog(
is worse: all the guis remain visible as ghosts. -
FFW
@oid A
realtime
onexpr
indicates a 8ms compute time. I'll try with your version.I've added a
change
and apipe
to delay the switch.
It doesn't fix the comments problem, they only disappear when I save their containing abstraction (or when I reload the main patch).
Now I'm looking for a dynamically added and resized background canvas to get rid of the transparency.
-
FFW
@oid my bad, I wasn't clear enough.
I've done what I mind:
I've an issue with comments which remain visible when the gop is shrunk.
-
FFW
I'd like to put this whole logic in an abstraction so I'll can reuse it but I don't find how to
sendcanvas
to the parent patch -