(I've also noted the naming bug, and was really confused the first time that came up). I'm under the impression that since the feedback patch is a kind of external provider, that it needs to be actively sent the input values (whether or not they are stored in the plist as a side effect). If you have your splitter actually connected to the initial output port, and the splitter's input value is 42, only then will the 42 be sent to the initial output port, and then the "actual output".
Maybe the thought is that re-opening and having these values not clear (if not connected to something delivering the value) would be akin to having a qtz that is mouse driven restore with the mouse coordinates that were happening when I closed the composition, so it was designed to clear by default since it's not being driven by any event. When the qtz is opened, this all gets evaluated from the "new" moment. I think this is a part of why it functions like this, though I guess anything is possible. So again, for clarity, one needs to have that initial output port be fed by the value from an insert splitter (or other patches), which does make the qtz restore with the 42 on the "real" output. I hope that's an ok workaround for your scenario! -George Toledo On Wed, Sep 30, 2009 at 12:24 PM, Christopher Wright <[email protected]>wrote: > Procedure: >> - Create a new blank composition. >> - Create an Input Splitter. Set type to Number, and publish the >> output. >> - Create a Feedback patch. Set the "Initial >> [published-output-name]" to 42. >> - Save, close the composition, and reopen it. >> >> At this point, the Feedback patch no longer has an "Initial >> [published-output-name]" input port --- it's instead called just >> "[published-output-name]", and its value is zero (not 42). I've confirmed >> similar behavior when the published output is of type String, Boolean, or >> Index. >> > > The name change is probably a typo (UI bug, but not of any interesting > consequence). The key name stays unchanged ("initial_[port name]"). > However, it doesn't seem to save/restore these ports' states, they're > always 0/false/"", etc when reloaded (even with inputInitialize set to > True). > > I can get around this by placing another Input Splitter connected into the >> Initial Value, but this seems somewhat baroque. >> > > This fixes the issue because the splitter does save/restore input port > states correctly, thus working around the Feedback patch's apparent > inability to save/restore state correctly. > > > Is it correct to expect the Initial Value to be preserved? >> > > > I would expect it to, personally, otherwise it serves no purpose. > > Strolling through the plist, it appears as though the patch actually _does_ > save state correctly, so perhaps it's a state restoration problem? > > -- > [ christopher wright ] > [email protected] > http://kineme.net/ > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Quartzcomposer-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/quartzcomposer-dev/gtoledo3%40gmail.com > > This email sent to [email protected] >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
