Indeed. Let's hope pd/extended adopt these soon.
Best wishes,
Ico On Jul 3, 2013 7:31 AM, "Roman Haefeli" reduzent@gmail.com wrote:
On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote:
On 07/03/2013 04:31 AM, Roman Haefeli wrote:
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote:
I guess we need to clarify what "not usable at all" means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily.
Many of my patches are not usable at all without GOP GUIs visible. And
I
cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this.
This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches.
The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices:
- keep the same inconsistent behaviour for as long as it exists causing
problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me)
- fix this at some later date at which point you will have a larger
library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way
Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable.
tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd.
Thanks for your considerations. I actually agree with you in every respect. I also wouldn't mind having GUI glitches fixed in pd-extended| pd-vanilla, even if it means having to go through all my patches to fix them. However, things haven't changed in pd-vanilla|pd-extended yet and I see myself forced to decide which route to go.
Roman