• FFW

    @freq63 said:

    What I find confusing is the fact that all 4 values are printed without issue separately before unpack.

    separately is the word. [unpack] get the values one (two) after each other so only its (two) first inlet(s) is (are) triggered.

    posted in technical issues read more
  • 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:
    image.png

    posted in technical issues read more
  • FFW

    This is your triggerized patch:
    image.png

    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.

    posted in technical issues read more
  • FFW

    1. Do not split the control flow without [trigger]
    2. Why don't you use [until] ?

    image.png

    posted in technical issues read more
  • FFW

    I think it's easier to dynamically upgrade the variable name with the [list prepend] right inlet.

    posted in technical issues read more
  • FFW

    [netsend] help for the [send( message says "same as list" so you can also do

    [hslider]
    |
    [list prepend z]
    |
    [netsend]
    

    posted in technical issues read more
  • FFW

    Simply connect the slider to the sender.

    image.png

    posted in technical issues read more
  • 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…

    posted in technical issues read more
  • 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.

    posted in technical issues read more
  • 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.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!