<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/29/2013 02:49 PM, Andr&aacute;s Mur&aacute;nyi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJtGUK6k4RiZej50tPpeqP-jeusru_aqtYNbCr=juB+xybG+ew@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Mon, Jul 29, 2013 at 7:48 PM,
            Jonathan Wilkes <span dir="ltr">&lt;<a
                moz-do-not-send="true" href="mailto:jancsika@yahoo.com"
                target="_blank">jancsika@yahoo.com</a>&gt;</span> wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>
                  <div class="h5">
                    <div>On 07/29/2013 07:50 AM, Andr&aacute;s Mur&aacute;nyi wrote:<br>
                    </div>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div class="gmail_extra">
                          <div class="gmail_quote">On Thu, Nov 25, 2010
                            at 10:19 AM, Frank Barknecht <span
                              dir="ltr">&lt;<a moz-do-not-send="true"
                                href="mailto:fbar@footils.org"
                                target="_blank">fbar@footils.org</a>&gt;</span>
                            wrote:<br>
                            <blockquote class="gmail_quote"
                              style="margin:0px 0px 0px
                              0.8ex;border-left:1px solid
                              rgb(204,204,204);padding-left:1ex">Hi,<br>
                              <div><br>
                                On Thu, Nov 25, 2010 at 03:28:01AM
                                +0100, Andr&aacute;s Mur&aacute;nyi wrote:<br>
                                &gt; Cool, i was wandering around in the
                                rj lib but i couldn't find how this
                                thing<br>
                                &gt; works. &nbsp;Can you just tell me in a
                                nutshell please?<br>
                                <br>
                              </div>
                              yeah, it's a bit convoluted, to make it
                              play nice in the background without a<br>
                              user ever having to see a single sssad
                              object ...<br>
                              <br>
                              Anyway the real interesting feature you
                              will like is not so much the "saveonly"<br>
                              message but local saving which is enabled
                              by adding something like "$0" as<br>
                              second argument to your [sssad] objects.
                              Such local sssad objects cannot be
                              controlled<br>
                              via sending to "SSSAD_ADMIN" anymore!
                              Instead you have to send to
                              "$0-SSSAD_ADMIN".<br>
                              <br>
                              In rj, the [u_sssad] objects are copies of
                              sssad.pd and they are hidden<br>
                              in [u_dispatch] objects. These objects are
                              in almost every rj abstraction and<br>
                              handle two things: Dispatching of "tagged
                              messages" from an inlet to local<br>
                              receivers and saving the sssad-parameters.<br>
                              <br>
                              For example a [u_dispatch $0 freq] will
                              turn messages like "freq 440" into a<br>
                              "440" sent to [s $0-freq] and it will also
                              save "440" into a local(!)<br>
                              sssad-parameter called "freq" that is
                              local to the value of $0.<br>
                              <br>
                              Now a second utility abstraction,
                              [u_loader] will build a bridge between
                              these<br>
                              local sssads with their $0-SSSAD_ADMIN
                              receivers and two global receivers<br>
                              called RJ_SCENE_LOAD and RJ_SCENE_SAVE.
                              Actually these are seldomly used in<br>
                              rjdj scenes.<br>
                              <br>
                              A typical idiom to get the state of all
                              sssads in one abstraction is to send<br>
                              "save" to the $0-SSSAD_ADMIN in ony
                              abstraction, then collect all the
                              responses<br>
                              into messages and save these into message
                              boxes. &nbsp;This is handled inside of<br>
                              [u_loader] and can be seen all over the rj
                              library, expecially in Andy's synths<br>
                              like s_ejun or s_cwc.<br>
                              <br>
                              If this sounds too complicated and you
                              want to just have a presettable<br>
                              abstraction, you just need to do this:<br>
                              <br>
                              1) add a [u_loader abstractionname-$1 $0]
                              object<br>
                              2) add a [u_dispatch $0 parametername]
                              object for every parameter<br>
                              3) daisychain all [u_dispatch] with
                              connections and connect the first one to
                              an inlet.<br>
                              3.1) Optionally: Connect [u_loader]'s
                              outlet to an outlet and route incoming<br>
                              &nbsp; "save" messages to its inlet to save
                              settings in the parent patch, e.g. with
                              [u_cocollect]<br>
                              4) Call you abstractions with unique tags
                              as first argument<br>
                              <br>
                              Now try sending stuff to RJ_SCENE_SAVE and
                              RJ_SCENE_LOAD and to the inlets of<br>
                              your abstractions.<br>
                              <br>
                              Ciao<br>
                              <span><font color="#888888">--<br>
                                  &nbsp;Frank Barknecht &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Do You
                                  RjDj.me? &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;_
                                  ______footils.org__<br>
                                </font></span>
                              <div>
                                <div><br>
                                </div>
                              </div>
                            </blockquote>
                          </div>
                          <br>
                          <div>Huh, I'm trying to pick this up (after 3
                            years...)<br>
                          </div>
                          Honestly, currently my IQ seems to be less
                          than satisfactory to understand and utilize
                          the advice. (It's also almost 40 degrees C
                          here so I'll have to think out loud...)<br>
                          <br>
                        </div>
                        <div class="gmail_extra">- is the SSSAD in
                          s-abstractions recent enough for these tricks?
                          (<a moz-do-not-send="true"
href="http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad"
                            target="_blank">http://code.google.com/p/s-abstractions/source/browse/#svn%2Ftrunk%2Fsssad</a>)<br>
                        </div>
                        <div class="gmail_extra">- is there an example
                          patch of SSSAD local saving available? i just
                          wish to see/understand how to save and load
                          presets exclusive for an abstraction instance.<br>
                        </div>
                        <div class="gmail_extra"> - or, please, is it
                          possible to list the steps of creating SSSAD
                          local saving for an abstraction? (eventually
                          using [presetstore]... which I have attached
                          because it's not hosted anywhere any more)?<br>
                        </div>
                        <div class="gmail_extra"> - is at viable at all
                          to avoid using rjlib for this (and to use
                          'pure' SSSAD), or I couldn't get away without
                          all that patching that is in u_loader,
                          u_dispatch, u_cocollect etc?<br>
                        </div>
                        <div class="gmail_extra"> <br clear="all">
                        </div>
                        <div class="gmail_extra">...sorry for the
                          dependent mental state in which I am! :-o<br>
                        </div>
                      </div>
                    </blockquote>
                    <br>
                  </div>
                </div>
                I don't think it's your mental state.&nbsp; Those tools are
                clunky.<br>
                <br>
                Have you looked at Ivica's [preset_hub] in Pd-l2ork?&nbsp;
                You simply name the [preset_hub],<br>
                and all the [preset_node] objects with the same name on
                that canvas or a child of it<br>
                (including abstractions) work together.&nbsp; No need to use
                dollarsign arguments at all.<br>
                All state is saved with the patch and adding/removing
                nodes works seamlessly, even with<br>
                infinite undo.<br>
                <br>
                His preset system even makes an automatic, hidden
                connection back into the [preset_node]<br>
                so you don't get crossed wires.<br>
                <br>
                -Jonathan</div>
            </blockquote>
            <div bgcolor="#FFFFFF" text="#000000">&nbsp;<br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">Now that you told it,
              I gave myself a shot of it. Mmmmmm...! Simple and fast and
              feels so good.<br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">However... I'm afraid
              of locking myself in pd-l2ork. That would mean that my
              songs are basically in l2ork.<br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">Where does this thing
              store its data? Is it possible to dump it out in raw form?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    It stores it as hidden args to the relevant [preset_hub].&nbsp; I told
    Ivica I thought there should<br>
    be an option to save the state out to a separate file, but he said
    that would complicate<br>
    things (and he's the one implementing all of it).&nbsp; After all, if
    you're saving state for a patch,<br>
    that state isn't much good outside of the context of the patch.<br>
    <br>
    The one area that this method does not address is abstractions
    managing their own state.<br>
    The obvious benefit of such self-management is with gui
    abstractions, where you want the<br>
    abstraction to retain colors, slider values, or whatever when the
    parent is saved, and without<br>
    manual intervention.<br>
    <br>
    Maybe there's a way to "embed" a preset_hub into a canvas (as an
    option in the gop dialog),<br>
    so that when the patch is created as an abstraction the preset state
    gets saved as args to<br>
    the abstraction.<br>
    <br>
    Also-- I think this probably ties in somehow to the idea of
    simulating named arguments<br>
    by interpreting arguments after a \, as messages to the object.&nbsp; In
    other words,<br>
    [foo, pitch 1, decay 3]<br>
    <br>
    would be equivalent to<br>
    <br>
    [initbang]<br>
    |<br>
    [pitch 1, decay 3(<br>
    |<br>
    [foo]<br>
    <br>
    I can't remember the exact arg syntax of [preset_hub] for saving
    state, but it seems like<br>
    it's essentially the same idea, just with the args hidden from the
    user.<br>
    <br>
    <blockquote
cite="mid:CAJtGUK6k4RiZej50tPpeqP-jeusru_aqtYNbCr=juB+xybG+ew@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div bgcolor="#FFFFFF" text="#000000">
            </div>
            <div bgcolor="#FFFFFF" text="#000000">On the other hand,
              you've been using l2ork for a while, right? Can I ask you
              "how does it feel", do you feel locked in, etc? You no
              miss 0.43 plugins...?!<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    There are only a few things in the hard sense that could lock you
    in:<br>
    * Pd-l2ork uses Max-style [trigger]: e.g., [t b 123] would trigger
    the number "123" then a bang<br>
    (quite useful in my opinion)<br>
    * [preset_hub] isn't part of Pd-extended nor vanilla<br>
    * discrepancy between iemgui placement on gop canvas that evidently
    makes<br>
    some gop abstractions not show up correctly in pd-l2ork<br>
    <br>
    I think everything else would only "lock" in a user in the soft
    sense, e.g., infinite undo<br>
    makes you feel slightly less like you're programming on an Apple II
    from the 80s.<br>
    <br>
    In fact there are so many of the latter type of improvements that
    it's probably<br>
    less work to port Pd-l2ork to Windows and OSX than it is to put
    those features<br>
    back into Pd-Extended and Vanilla.&nbsp; If Pd-l2ork incorporated the
    0.43 gui changes<br>
    then that's probably what I'd spend my time doing. :)<br>
    <br>
    -Jonathan<br>
    <br>
    <blockquote
cite="mid:CAJtGUK6k4RiZej50tPpeqP-jeusru_aqtYNbCr=juB+xybG+ew@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div bgcolor="#FFFFFF" text="#000000"><br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000">Thanks,<br>
            </div>
            <div bgcolor="#FFFFFF" text="#000000"><br>
              Andr&aacute;s
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>